[PATCH 2 of 2 v2] subrepos: make subrepositories sticky

[Martin Geisler]

Mads Kiilerich <mads at kiilerich.com> writes:

> Erik Zielke wrote, On 01/26/2011 01:20 PM:
>> # HG changeset patch
>> # User Erik Zielke<ez at aragost.com>
>> # Date 1294241235 -3600
>> # Node ID 63c76fed1e6b482eeec7b19496bc673da3cd2038
>> # Parent  4c003dc9ab3cd8f379f9f761931bddcf03bce21e
>> subrepos: make subrepositories sticky
>>
>> Making subrepositories sticky means that if we have the following
>> links between main repository and subrepository:
>>
>> r0 - s0
>> r1 - s1
>> r2 - s2
>>
>> and have updated so the revisions are not at the linked states, e.g.
>> we are at r1 in the main repository and s2 in the sub repository. Then
>> when we update the main repository, the subrepository stays at s2,
>> unless we use clean when updating.
>>
>> Example:
>>
>>      Current state: r1/s2
>>      hg up 0
>>      Current state: r0/s2
>
> I don't agree on that. In the working directory the subrepo was at s1
> but has been changed to s2. The update of the outer repo wants to
> change s1 to s0. That is a conflict that requires a merge, and as long
> as we only have merge tools for file content that should give the '
> subrepository sources for %s differ\nuse (l)ocal source (%s) or
> (r)emote source (%s)?' prompt.

Hmm, I had forgotten we had such a prompt...

I think we should avoid adding more prompts -- I don't think anybody
likes them since they give a clumsy command line interface. The biggest
problem is that they get boring really quick when you have 70+ subrepos
like our client.

But I agree that this represents a conflict and this was also how I
described the problem in the first place. We just chose to auto-resolve
the conflict using the internal:local merge tool, so to speak.

We chose this since the situation can be pretty complex: the subrepo is
updated to a conflicting revision, in addition it may be dirty and there
might be (ignored) build artifacts that should not be deleted. Leaving
it alone seems like the best solution to me.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/