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

[Stephen Leake]

William Uther <address@hidden> writes:

> On 14/02/2008, at 12:55 AM, Stephen Leake wrote:
>>
>> Markus Schiltknecht <address@hidden> writes:
>>
>>>> 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.
>
> I assume you're talking about this warning:
>
>> mtn: 2 heads on branch 'testbranch'
>> mtn: [left]  587b23da811ee8998263ee61cfc3d99411d2584e
>> mtn: [right] 85420004b753e4dc93bfba9ad2f2243395e025b7
>> mtn: warning: Content changes to the file 'testfile'
>> mtn: warning: will be ignored during this merge as the file has been
>> mtn: warning: removed on one side of the merge.  Affected revisions
>> include:
>> mtn: warning: Revision: 85420004b753e4dc93bfba9ad2f2243395e025b7
>> mtn: [merged] 3d6188cf266a7e45ef2a6d01262d0aa05478f654
>> mtn: note: your workspaces have not been updated

Yes.

> If you make that warning an error, then the nodes become
> unmergeable. The best you could do would be to merge nodes from
> before either the drop or the edit, and then suspend the other
> micro-branches.

Hmm. Yes, I had not thought thru in detail how to "fix" the warning.

> Instead of making the warning an error, you could make that warning
> _smarter_ by having it produce a diff for you to see what changes
> are being dropped. It could even prompt to see if it should a) drop
> the changes, b) write the patches to a temporary file, or c) try to
> apply the patches to a different versioned file.

Yes, that would be useful.

>> 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.
>
> Which the above smarter version would achieve, but you'd have to tell it
> which file to apply the patch to.

Right.

>>>> 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"?
>
> This would then be like dropping the conflicting file on one side of
> the merge, then merging again and attempting a two-way merge (NOT a
> three way merge - there is no common ancestor). 

Right; I'm just automating that process.

> Another issue here is that you need to know when the two-way merge is
> appropriate.  If the files really are different then you'll have
> trouble merging them.  I guess that is fine as long as you can
> abort the revision merge in the two-way file merge.

That's why there is a prompt. But yes, aborting the merge should also
be supported, to let the user change their mind after seeing the
actual file contents.

-- 
-- Stephe