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

[Markus Schiltknecht]

Hi

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
> > > 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 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
> "thermometer-honeywell".
>
> I don't see where "copying" is useful; we don't need more files, just
> the right names for these two files.

Agreed.

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

Regards

Markus