some bzrmerge.el questions

some bzrmerge.el questions

[Glenn Morris]

bzrmerge.el looks very helpful. Some questions:

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

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

This is fine. After dealing with any conflicts, should I run bzrmerge
again to get revisions 11-20, and then commit everything at once; or
should I commit in the middle, before merging 11-20? (Maybe bzr won't
let me do it the wrong way.)

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.

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.

Re: some bzrmerge.el questions

[Stefan Monnier]

> 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

Re: some bzrmerge.el questions

[Glenn Morris]

Unfortunately after resolving many text conflicts I ran into

https://bugs.launchpad.net/bzr/+bug/660935/

which currently prevents dealing with the contents conflicts caused by
files deleted from trunk having been modified in emacs-23.
So at present it's impossible to merge emacs-23 to trunk, AFAICS. :(

Re: some bzrmerge.el questions

[Glenn Morris]

Glenn Morris wrote:

> https://bugs.launchpad.net/bzr/+bug/660935/

Actually, it looks like there is a workaround.

Re: some bzrmerge.el questions

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 14 Jan 2011 03:19:09 -0500
> Cc: emacs-devel@gnu.org
> 
> Glenn Morris wrote:
> 
> > https://bugs.launchpad.net/bzr/+bug/660935/
> 
> Actually, it looks like there is a workaround.

Which is?...

I was about to write that if the problem is that bad (and being unable
to merge from emacs-23 _is_ bad), we could ask Bazaar developers to
give this bug high priority and provide us with some workaround.  But
if you already found one, that could be good enough.

Re: some bzrmerge.el questions

[Glenn Morris]

Eli Zaretskii wrote:

>> > https://bugs.launchpad.net/bzr/+bug/660935/
>> 
>> Actually, it looks like there is a workaround.
>
> Which is?...

The one I suggested in the last item of the linked bug report.

Re: some bzrmerge.el questions

[Glenn Morris]

>>> Actually, it looks like there is a workaround.
>>
>> Which is?...

Or indeed just use rm + bzr resolve, as pointed out on the Bazaar
mailing list. Wish I'd known about that yesterday. :(

Re: some bzrmerge.el questions

[Glenn Morris]

Glenn Morris wrote:

> Unfortunately after resolving many text conflicts I ran into

Oh well, I see you merged it, up to exactly the same point I was
working on. At least I might know what to do next time.

BTW, the ChangeLog piece often includes too much - see the corrections
I just installed. Sometimes it duplicates existing items, often it
includes one line too many.

Re: some bzrmerge.el questions

[Stefan Monnier]

>> Unfortunately after resolving many text conflicts I ran into
> Oh well, I see you merged it, up to exactly the same point I was
> working on.  At least I might know what to do next time.

Sorry.  BTW, I also committed a change to smerge, which I used to
automate most of the conflict resolution (there was tons of spurious
conflicts with the copyright year update, as you must know, and most of
them could be resolved automatically).

> BTW, the ChangeLog piece often includes too much - see the corrections
> I just installed. Sometimes it duplicates existing items, often it
> includes one line too many.

Sounds like a bug in change-log-resolve-conflict.  If you could take
a look at it and try and figure out how to solve/detect/avoid the
problems you've seen, that would be very helpful.


        Stefan

Re: some bzrmerge.el questions

[Glenn Morris]

Stefan Monnier wrote:

> BTW, I also committed a change to smerge, which I used to automate
> most of the conflict resolution (there was tons of spurious
> conflicts with the copyright year update, as you must know, and most
> of them could be resolved automatically).

Well, that would certainly make anyone who resolved them all by hand
look foolish...

Could you add a similar thing for changes in comments that only relate
to loaddef checksums? I think in such cases, it should not bother
merging the change.

>> BTW, the ChangeLog piece often includes too much - see the corrections
>> I just installed. Sometimes it duplicates existing items, often it
>> includes one line too many.
>
> Sounds like a bug in change-log-resolve-conflict.

Of course, I haven't seen it happen again since.

Re: some bzrmerge.el questions

[Stefan Monnier]

>> BTW, I also committed a change to smerge, which I used to automate
>> most of the conflict resolution (there was tons of spurious
>> conflicts with the copyright year update, as you must know, and most
>> of them could be resolved automatically).

> Well, that would certainly make anyone who resolved them all by hand
> look foolish...

Well, it's when I started to feel foolish that I dediced to bite the
bullet and write the code in the first place.

> Could you add a similar thing for changes in comments that only relate
> to loaddef checksums? I think in such cases, it should not bother
> merging the change.

I might do just that next time I bump into such conflicts, but the
problem is that those are specific to Emacs code so I expect it'll take
more coding to figure out where to put that code.


        Stefan

Re: some bzrmerge.el questions

[martin rudalics]

 > Could you add a similar thing for changes in comments that only relate
 > to loaddef checksums? I think in such cases, it should not bother
 > merging the change.

During recent bzr updates I got a number (~ 5) of conflicts wrt loaddef
checksums.  I simply ignored them via bzr revert.  Was that the right
way to deal with this problem?

martin

Re: some bzrmerge.el questions

[Stefan Monnier]

>> Could you add a similar thing for changes in comments that only relate
>> to loaddef checksums? I think in such cases, it should not bother
>> merging the change.

> During recent bzr updates I got a number (~ 5) of conflicts wrt loaddef
> checksums.  I simply ignored them via bzr revert.  Was that the right
> way to deal with this problem?

AFAIK that's the right way: choose one of the 3 options (doesn't matter
which).  Then run "make" which should update the autoloads and in turn
update the md5 checksums to the value they need to take (which can be
a 4th value rather than one of the three from the conflict).


        Stefan

Re: some bzrmerge.el questions

[Glenn Morris]

I realize I am confused by "skipping". Naively, I thought skipping
would exclude the relevant revision entirely. However, a comment in
bzrmerge-apply says that it still merges the meta-data. I guess this
explains why revno: 99634.2.749 "!!!DO NOT MERGE TO THE TRUNK!!!" [1]
now shows up in `bzr log -n0' output on the trunk, even though I said
it should be skipped. Isn't it confusing to not merge the data, but
still merge the meta-data?

[1] A less hysterical "Do not merge to trunk" would have worked just
as well, BTW. (Though I admit I could have messed this up, because the
following commit changed the same code, but was not marked "do not
merge".)

Re: some bzrmerge.el questions

[Stefan Monnier]

> I realize I am confused by "skipping". Naively, I thought skipping
> would exclude the relevant revision entirely. However, a comment in
> bzrmerge-apply says that it still merges the meta-data. I guess this
> explains why revno: 99634.2.749 "!!!DO NOT MERGE TO THE TRUNK!!!" [1]
> now shows up in `bzr log -n0' output on the trunk, even though I said
> it should be skipped. Isn't it confusing to not merge the data, but
> still merge the meta-data?

There is simply no way in Bzr to merge part of a branch history: the
only kind of merge info recorded in the metadata says "all the branch
upto <foo> has been merged".

And really if you think about it, those "don't merge to trunk" changes
are usually changes which have already been performed on the trunk (tho
in a slightly different way, typically), so "applying" the corresponding
change amounts to doing nothing: if you used "bzr merge" instead of "M-x
bzrmerge", then you'd get spurious conflicts which you'd resolve by
choosing the pre-existing trunk version.  So bzrmerge just helps you
avoid those conflicts.


        Stefan

Re: some bzrmerge.el questions

[Glenn Morris]

Stefan Monnier wrote:

> There is simply no way in Bzr to merge part of a branch history: the
> only kind of merge info recorded in the metadata says "all the branch
> upto <foo> has been merged".

Oh I think I see. `bzr help merge' implies (to me) that it works, but
in detail it doesn't, eg

https://lists.ubuntu.com/archives/bazaar/2010q3/069894.html

Anyway; it's off-topic for this list. Thankfully I can just M-x
bzrmerge without worrying about the details. :)