[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 20:29:03 +0100
User-agent: Mozilla-Thunderbird (X11/20080109)


Stephen Leake wrote:
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.

First? Before what, Abe's changes? You cannot enforce the merge, before allowing further commits. Just think about Abe and Beth continuing their work, and Chuck doing the merge.

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.

Yes, sometimes even then. Sometimes I just want to get rid of a file, no matter if another user added some comments or not.

Also keep in mind, that these events don't necessarily have to be close in time. Maybe I'm working on a branch, where I don't need file foo anymore. But on mainline, it's still maintained. In such a case, I certainly don't want to be bugged about those changes I'm losing. I told monotone to get rid of them, end of the story.

That's why there's a warning;
I just want to treat all warnings as errors.

Treating *all* warnings as errors is certainly wrong here. Warnings are not meant to abort the ongoing action. But errors do.

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 general, I agree. However, you are assuming the changes are lost, which is not the case: a merge only *adds* a revision. It doesn't change or remove anything.

Everyone is still free to check out an old revision and branch from that or look at the files, which are no longer present in a following revision. So again, I'm thinking turning that into an error makes things worse, rather than better.

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.

Well, yes. It's not really different from what's needed today, in this case.

Another use-case that gives the same non-content conflict is when
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

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.

Maybe, that's up to the user, so monotone can't know.

However, I still maintain the point that this second case, where two distinct node ids need to be merged into one is somewhat related to the copy problem, where a single node id needs to be duplicated for two files, which are going separate ways from there on (asymmetric copy). In both case, I'd rather like monotone to keep track of that change, instead of working around it.

If we track that somehow, we should think about both variants, IMO. Because both are useful. And they are similar enough to be handled similar internally. (Think about merge issues here, for example Abe and Beth doing the merge simultaneously, but decide slightly differently. Then merge the resulting revisions again).

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.

I don't quite follow. What does a missing workspace have to do with usefulness of prompting?

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

You mean a variant which creates a merged revision with one node id dropped, and the other one gets the merged contents? Well, that's nice, yes. And might help some users.

Hm.. okay, just keep in mind, that dropping a file does also drop it's history. So the user should be able to decide which one to drop. Ah.. I see, your '--merge-drop-right' proposal already covers that, good.

Wouldn't the same arguments also apply to yet another additional '--merge-by-renaming' option, which would rename the non-content conflicting files 'foo' from the two ancestor revisions to 'left-foo' and 'right-foo' in the merged revision? Of course the user later on probably wants to rename again, but I consider that a very similar helper, which simplifies the merge. Or well, maybe we would need to prompt for new names, to be equivalent to the currently proposed '--merge-drop-right' option. So that no arbitrary file names are introduced.

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.

The same as in the current process: If monotone tells you that it cannot merge due to such a non-content conflict, you create a (helper) revision which drops or renames the offending file(s). On top of that, you can then do the merge. A GUI could certainly help automating that process. And it can probably do a better job than monotone on the command line.

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.

Coll, I'm looking forward to that.



reply via email to

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