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

[Stephen Leake]

Markus Schiltknecht <address@hidden> writes:

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

No, before dropping the file.

> You cannot enforce the merge, before allowing further commits. Just
> think about Abe and Beth continuing their work, and Chuck doing the
> merge.

Right; I was only talking about the events required to allow Beth to
complete the merge she is doing.

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

Then you are leaving it up to the other user to figure out what to do
with their changes. Which may be the right choice in some situations.

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

It will be a problem when you merge back to mainline; the bugs fixed
added by those later changes will reappear. Unless they were
fixed by your branch; it depends on the details of the situation;
there is no general "right" answer.

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

It may be wrong for your use case; it is correct for mine. That's why
it should be a user option.

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

That's true, but the changes are lost from the _head_ of the branch.
That's what I mean by "lost". I assume that's why there is a warning now.

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

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

> So again, I'm thinking turning that into an error makes things
> worse, rather than better.

Not for my use case.

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

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.

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

Well, I there also needs to be a --merge-drop-left if you want the
user to choose which to drop. But then you have to specify the right
option for each conflict; --merge-drop-right is supposed to apply to
_all_ conflicts at once.

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

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

It's easy enough to rename at the moment. And you want to specify new
names for each conflict separately; that's complicated for a single
command line.

Even if you let monotone use arbitrary names, you still need to
specify either --merge-by-renaming or --merge-drop-right for each
conflict separately; too complicated for the command line.

>>>> 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, now I understand. 

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.

-- 
-- Stephe