[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: William Uther
Subject: Re: [Monotone-devel] How to join identical branches?
Date: Thu, 14 Feb 2008 10:47:39 +1100

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

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.


Will       :-}

reply via email to

[Prev in Thread] Current Thread [Next in Thread]