Re: some bzrmerge.el questions

[Stefan Monnier <monnier@iro.umontreal.ca>]

> bzrmerge.el looks very helpful. Some questions:

> 1) Can I use it with bound branches? (It seems so, I just want to check.)

Yes, all my branches are bound.  Just like `merge', it only operates on
the checkout anyway, so it shouldn't make any difference whether it's
bound or not.

> 2) Say there are 20 revisions to merge, and revision 10 is one to skip.
> What seems to happen is, it merges revisions 1-9, then stops.
> (Maybe it only stopped because there were conflicts?)

Yes, it should only stop when it encounters conflicts.

> This is fine. After dealing with any conflicts, should I run bzrmerge
> again to get revisions 11-20, and then commit everything at once;

That's the intention.

> or should I commit in the middle, before merging 11-20? (Maybe bzr
> won't let me do it the wrong way.)

You can do that as well.  Either should work.

> 3) Is there a way I can manually specify a revision(s) to skip?
> Eg if someone did not use the appropriate magic word(s) in the commit
> message.

Currently, no.  But you can easily tweak the code to change the regexp
so it matches all commits.

> 4) What is the right thing to do if a change is going to have to be
> substantially rewritten in order to merge? Eg changing a different
> file to the original change? Should one fix it all up before
> committing the merge; or commit the merge (with conflicts resolved at
> least), then make a separate normal commit to implement the feature;
> or does one totally skip merging the relevant commit, and do it by
> hand as a new commit? The last two options seem nicer because the
> person doing the merge can ask the person who made the original commit
> to fix it.

I think it depends on the particular case.  When I've had to do that
(e.g. a change in tramp.el which moved to tramp-sh.el) bzrmerge
signaled a conflict and I resolved it by hand (by applying the failed
patch to the other file) and then updated the ChangeLog comment to say
"tramp-sh.el".
But if the resolution ends up with completely different code, I think it
makes sense to commit it as a new change rather than as a merge of some
other change.

The one important thing is to make sure we don't drop changes, so it's
better to first commit a new solution on the trunk, and then merge the
old solution (and just resolve the conflict by leaving the code
unchanged), rather than merge first and then install
a different solution.  Sadly, this is sometimes inconvenient: I may
want/need to merge *now* because I want to install something that
depends on an yet-unmerged change and then bump into a conflict in
someone else's code, at which point you may find you prefer drop his
change so you can go on with yours and hope he won't forget to install
an updated solution.


        Stefan