[Top][All Lists]

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

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

From: Markus Schiltknecht
Subject: Re: [Monotone-devel] How to join identical branches?
Date: Wed, 13 Feb 2008 12:55:31 +0100
User-agent: Mozilla-Thunderbird (X11/20080110)

Hello Stephen,

Stephen Leake wrote:
Right; I'd like monotone to offer to help start that, by calling the
normal external merger on the two files.

Okay, that's a reasonable goal, IMO.

but the resulting file will have to carry on one or the other
existing node id. This might affect future merges. Also consider
what to do with the other node id. If you simply drop that by
deleting the file (in favor of the other one), any future changes to
it, which should have been added to the merged file, will get lost,
due to die die die.

The use case I am concerned with here is that there really should be
only one file, named "foo"; Beth and Abe just happen to realize that
separately, and commit slightly different versions of it.

There can be lost changes if Beth resolves the conflict by dropping
Abe's version, but Abe makes more changes before syncing. In that
case, monotone issues a warning when Abe syncs and merges his changed
"foo" with Beth's drop of it:

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

Oh, cool. I didn't know monotone issues a warning in that case.

To recover, Abe must manually check out his committed revision, and
merge it with Beth's.

This is about equally painful as having to rename a file before being able to merge. But it occurs much less frequently. Only if the dropped node_id gets changes which also need to be merged. So yes, this might be beneficial for the situation described above.

Note that it is actually difficult for Beth to drop Abe's revision;

The revision? You mean to drop the file, right?

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.

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.

getting to the case where changes are lost is difficult.

Not more difficult, than committing the "same" file (by filename) - which is how that whole problem arises in the first place.

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

Not sure how much that affects file undeletion, but it certainly has a lot to do with die die die.

I don't see any other solution to this case; one node must be dropped.

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

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.

3) If the user answers "no", stop with an error (as it now does). Or
   offer to rename the files.

Perhaps that is a more complex UI than mtn typically offers. I'll have
to think about doing this in Emacs DVC instead.

I don't know Emacs DVC, but that sounds like a good option.

Another solution would be to provide a new option --merge-drop-right for
merge. Then the flow would be:

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

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.

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.


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.



reply via email to

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