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

[William Uther]

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

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.

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.


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

> > > 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).  As noted in
later discussion, which side you drop is a choice you can't make as
'local' and 'remote'.

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.

If people then keep committing to the dropped file (in parallel with
this merge), then future merges would get the warning and prompt I
mentioned above.  They could choose to apply the generated patch
to the file with the same name.

Cheers,

Will       :-}