[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: Thu, 14 Feb 2008 10:14:15 +0100
User-agent: Mozilla-Thunderbird (X11/20080110)


I think we have an understanding, that there are different use cases, which both need to be considered.

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

Yes, but that's more painful than preserving the changes during the
merge, in my use case.

I doubt that in general, when taking into account all the information which theoretically needs to be preserved. However, in your use case, where merging file contents and dropping one file is fine, that's certainly true and applicable.

Ok. That's a new feature; I'm not at all clear how to add that. We
could add a cert that says "merged node <id>"; then the hard part is
getting all the commands related to history to use that cert.

No, node ids are local, per database. So you cannot store certs (not even attributes) which refer to node ids. This would require additions to the internal revision and roster data format, AFAICT.

Well, I there also needs to be a --merge-drop-left if you want the
user to choose which to drop.

I was thinking that the user can swap the revisions, and put that on the right, from which he wants to drop files, but well...

But then you have to specify the right
option for each conflict; --merge-drop-right is supposed to apply to
_all_ conflicts at once.

Oh, yes, that's another good point.

If we could record the fact of the nodes merging in the history, it
would not matter which was dropped.

Yes, that's how I'm imaging it working. Especially, later merges could succeed.

With the above variant, if Abe and Beth do the merge simultaneously, and Abe decides to merge into node id 1, but Beth decides to merge into node id 2, guess what happens when the two sync and merge again: due to die die die merge, *both* files will be gone - with the changes lost warning, yes, but they will disappear. Because monotone cannot currently track that users decision properly.

It's easy enough to rename at the moment.

You are arguing that the process of dropping a file and merge into another one should be automated, but find renaming easy enough? I don't see that much difference in those two processes. For both, you need to commit a revision, which can then be merged with the other head.

And you want to specify new
names for each conflict separately; that's complicated for a single
command line.


By "automate merge" I meant that mtn would "prompt" the GUI for help
when it got to a conflict. But I don't think the automate stdio
interface supports interaction like that, so I guess I really mean we
need a way to do all the steps that "merge" currently does via
automate stdio. That capability may already be there; I'm not sure.

The first step would be "give me a list of all non-content conflicts".
I don't see that in the automate commands yet. Adding that might
actually be easier than adding --drop-merge-right to merge; I'll look
into it.

I'd prefer such an approach a lot. And yes, the automate interface could certainly do more in that area. A "try this merge" command (which would return possible non-content conflicts as well as content conflicts) would be very nice, IMO.



reply via email to

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