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

[Mads Kiilerich]

On 01/31/2011 12:11 PM, Martin Geisler wrote:
> 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.

I am not proposing to add a new prompt but to use the existing prompt as 
it was intended.

I also don't like these prompts, but that is how we currently resolve 
manifest merge conflicts. Consistency and predictability is important - 
and hardcoding an answer is IMHO not a good solution.

.hgsubstate is resolved as a part of the manifest merge, but each of the 
lines could be considered more like a file merge. Would it make sense to 
use the merge-tools configuration (or something similar) for .hgsubstate 
line merges? That could make it possible to specify --tool 
internal:local if you really want to ignore any conflicting changes made 
in The Other Branch.

/Mads