Re: [Monotone-devel] How to join identical branches?

[Stephen Leake]

Markus Schiltknecht <address@hidden> writes:

>> Note that it is actually difficult for Beth to drop Abe's revision;
>
> The revision? You mean to drop the file, right?

Yes; I should have said "drop the file from Abe's revision".

>> she first has to check out his head explicitly, then drop. It is
>> easier, and just as correct, for her to drop her version.
>
> Well, yeah, but you have to figure that out first. And maybe Abe has
> also committed changes she doesn't want to disappear.

which is why the contents need to be merged first.

>> In that
>> case, there cannot be future changes to the dropped version.
>
> That's certainly wrong. We are in a distributed system, it happens
> quite frequently, that Chuck syncs and then Abe merges. Even if Abe
> now syncs to a central repository right away, Chuck might commit
> changes to the file which Abe dropped as part of the merge.

Yes. I was considering the case of _only_ Abe and Beth. If Chuck gets
involved, it gets worse.

>> Hmm. If there is a third developer involved, they could be making
>> changes on Beth's version, that would eventually be lost with a
>> warning. In that case, I'd like an option to promote that warning to
>> an error.
>
> Uh.. that would involve tracking the reason for deletion (dropping)
> files. Because normally, you want the "deletion" of a file to be
> propagated across merges. 

But not if the merge will lose changes. That's why there's a warning;
I just want to treat all warnings as errors.

> Somehow, you would then have to be able to disambiguate between
> manually dropped files and files dropped due to a resolved
> non-content conflict.

I don't think that matters; what matters is the lost changes. If I'm
about to lose changes, I want to have the chance to preserve them in
whatever way is appropriate before letting the merge go thru.

In this case, the correct solution is to merge Abe's latest changes
with Beth's version of file "foo", drop "foo" from Abe's revision, and
finally merge.

>> Another use-case that gives the same non-content conflict is when
>> the
>> two files should have different names, but accidentally have the same
>> name. Then the solution is to rename one or both. Beth can rename
>> hers, and then rename Abe's after the merge, if necessary.
>
> Huh? The real solution to that would be support for copying file, no?
> In a way, it is similar, yes, because copying involves duplicating
> node ids for two distinct filenames. While the above involves reducing
> node ids to one filename.

I think we are both confused. Let me present a more concrete use case.

Beth is working on a new feature; a model of a Honeywell thermometer.
She decides to implement it in a file named "thermometer". At the same
time, Abe starts working on a model of a Westinghouse thermometer, and
calls his file "thermometer" as well.

In this case, the right solution is to rename Abe's file to
"thermometer-westinghouse", and Beth's file to
"thermometer-honeywell".

I don't see where "copying" is useful; we don't need more files, just
the right names for these two files.

This use-case is distinct from the first one, although monotone can't
tell that. Using the same ideas, the first use case is when Abe and
Beth both start working on the Honeywell thermometer; then there
should be one file, and the contents should be merged.

>> I would like to automate the process for the "should be one file" case.
>> When a non-content conflict is detected, I would like monotone to do
>> the following:
>> 1) Give a prompt like:
>>     "Non-content conflict detected. Merge the contents and drop
>> one?"
>> 2) If the user answers "yes", use the internal or external merger to
>>    merge the file contents into the remote file, then drop the local
>>    one, and proceed.
>>    Here "local" means "in the current workspace"; is that always
>>    "right"?
>
> I wouldn't use local and remote here, it's rather confusing. Because
> monotone doesn't differentiate between revisions created locally and
> remotely: both end up in the database, and both are needed for the
> merge.
>
> Also note, that the merge isn't associated with a workspace, but only
> with the database. This is why you need to manually do an "update"
> after the merge. IMO this should absolutely stay so, because it's a
> nice separation of concerns.

Ah, that's a good point.

That makes this prompt not very useful.

>> Another solution would be to provide a new option --merge-drop-right for
>> merge. Then the flow would be:
>> merge
>>     -- fails with one or more non-content conflicts
>> rename as appropriate to resolve some conflicts
>> merge --merge-drop-right
>>     -- resolves remaining non-content conflicts as described above, succeeds
>> That is a simpler user interface, since it doesn't involve
>> prompting.
>> However, it will be slower, since it involves two passes.
>
> I also like that better than prompting. I don't consider speed or
> having to type a little more to be real draw-backs here.

Ok. I'll work on implementing this solution.

>> A new "automate merge" would allow an external UI to do the right
>> thing in one pass; that would be the best solution.
>
> Well, do we really need that there? Isn't it better to simplify
> automatic creation of revisions (without requiring a workspace) and
> let automate-users (i.e. the GUI programs) create a helper revision
> before the merge? That would help a lot of other use cases as well.

I'm not clear what the helper revision is for, or what it consists of.

>>> Thus, I think it's currently handled quite well, by noticing the user
>>> of the conflict. 
>> It would help if how to handle this error message was discussed in
>> the
>> manual. Perhaps the error message could refer to the proper section of
>> the manual.
>
> Agreed.
>
>> There is currently a section "Advanced Uses | Workspace Collisions"; we
>> could add "Advanced Uses | Non-content Conflicts". I can do that, once
>> I get confirmation that I understand the issues correctly.
>
> That would be great, yeah. I'm gladly offering help and review for
> that.

Ok, I'll start by putting in the two use cases I'm presenting here.
I should be able to get to it later this week.

-- 
-- Stephe