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

[Martin Geisler]

Mads Kiilerich <mads at kiilerich.com> writes:

> 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.

Right, I see.

> 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.

Yeah, it's a little unfortunate. But it's not that bad: we tell the user
that we've not tried to merge (mess up) his subrepos and that he can use
--clean if he want the merge to go the other way.

> .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.

Hmm, I guess 'hg update --clean subrepo' should be enough. The patch has
a simple goal: subrepos should be left alone unless they are at their
expected revision. I prefer if we don't complicate this too much by
making it dependent on new infrastructure to merge .hgsubstate lines and
whatnot.


-- 
Martin Geisler

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