[PATCH 0 of 2 rfc] Sticky subrepos

Martin Geisler mg at lazybytes.net
Tue Feb 8 09:28:10 UTC 2011


Dirkjan Ochtman <dirkjan at ochtman.nl> writes:

> Can you spell out the use case some more?

I've asked our client for some use cases and this is what he wrote back
to me:

  There are two use cases:

  1) A developer is temporarily using a different revision of some
     subrepo (e.g. a tool or library) from the revision in the parent's
     .hgsubstate; he is not modifying it. There is a new revision in the
     parent repo, bringing in new revisions of subrepos. The result he
     wants with update without the clean option is to have the new
     revisions of other subrepos and keep the revision of the subrepo
     that he has manually updated, _without any merge in the parent
     repo_.

  2) A developer is modifying a subrepo; he may or may not have a new
     revision that differs from the revision in the parent's
     .hgsubstate. There is a new revision in the parent repo, bringing
     in new revisions of subrepos (including the one he is modifying).
     The result he wants with update without the clean option is to have
     the new revisions of the other subrepos and keep the revision of
     the subrepo that he is working on, _without any merge in the parent
     repo or in the subrepo_.

  In general, I'm not a fan of "prompt-the-user" solutions, but if this
  is what is required to get an agreement in the community it's ok - as
  long as two conditions are met: 1) there is a clear option that means
  "no merge in the parent at all; just leave things the way they are";
  2) the "prompt-the-user" solution also works in Tortoise.

> The scenario that I would want is a kind of vendor repo (i.e. should
> fail on commit with non-clean subrepo, but update substate if changed
> on commit, maybe with a note/status). Is this that? I'm confused by
> your "will not be updated". Also we probably want some discussion on
> how this should be represented in the .hgsub{,state}.

I was not going to represent it in any way in those files. The
.hgsubstate file is mostly invisible to users -- it's content is updated
as part of the commit, so 'hg status .hgsubstate' will never tell you
what the next commit will really do.

I hope this clears up the goal of the patch series, otherwise please ask
again.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20110208/96a0039a/attachment.asc>


More information about the Mercurial-devel mailing list