Immediate merge of a bundle vs branch -r + pull and later merge

[Andrew Cowie]

Had a bit of an experiment today: thus far I've rather frantically been
doing

(1)
        $ cd working
        $ bzr merge ~/Desktop/whatever.bundle

into my working directory branch, then with a whack of changes that need
committing to merge.

My situation is that and I have typically needed to carry out a
considerable number of changes to fix up the submissions before
accepting them as 'mainline' worthy. Until now I have been doing this
during the merge commit, which has been working well enough. ie

(1a)
        [resolve conflicts *and* make changes]
        $ bzr commit
        $ bzr push ../mainline

One thing it doesn't do, though, is give me the ability to back out _my_
changes easily... if I `bzr revert` it returns to base pre-merge state,
not to submitted changes state. [That is certainly useful as the
mechanism to reject an entire file worth of changes, but otherwise is a
bit in the way]

A related issue is that I can't see what _I_ changed that easily - it
all compounds as one in the diff. [I'm sure there's some magic -r
syntax, but `bzr diff -r -1..` wasn't it]

And finally, rather annoyingly, I can't use `bzr log` or `bzr viz` to
see the revisions submitted until I after  complete the changes and
commit. That's burned me a few times when I've realized that the commit
messages were utter shit but only I'd already accepted and moved along.

++

Following a suggestion Robert made to me in Birmingham, today I instead
tried manually seeing what the base revision was, creating a branch to
that revision, and then did a pull:

(2)
   $ tail ~/Desktop/whatever.bundle
        [manually extract base revid from last few lines]
        $ cd ..
        $ bzr clone -r revid:andrew at oper...34f6a0b mainline whatever
        $ cd whatever
        $ bzr pull ~/Desktop/whatever.bundle

Whew. That was a lot of work.

The difference being that this second form leaves me in a fully
committed branch that represents the state from the submitter. The up
side is that now any changes I make are plain old every day deltas and
can easily be identified (fairly limited value), output to a .diff file
and sent to our list with commentary about what needed to be fixed and
why I look forward to not having to do that again (quite handy; been
doing that by hand) and gives me the rollback checkpoint missing above
in (1).

The obvious downside is all the work to create it. And of course it's a
lot harder to see what the actual contribution was, but for that I can
always pull up the bundle.patch file in a text editor.

From here on I'm forecasting, but as a guess, after happily working for
a bit, I will have to

(2a)
        $ bzr merge ../mainline
        [resolve conflicts]
        $ bzr commit
        $ bzr push ../mainline

or
(2b)
        $ cd ../mainline
        $ bzr merge ../whatever
        [resolve conflicts]
        $ bzr commit

I'm not sure [yet] if there's a qualitative difference between these two
variations. My guess is that the (2a) case will have the effect of
pushing the contributed and now merged revisions to the trunk edge vs
them being out on the side and then "merged in" as in the usual (1a) and
this (2b).

++

Can anyone suggest something procedurally or tool-use-wise that could be
improved above or that would tip the balance in favour of the merge
technique (1) or the pull one (2)?

My hunch is that (2) is better, but I hope I'm missing something to make
it more workable.

AfC
Sydney


[As ever it seems like I'm paddling upstream a bit, but I'm just happy
to be able to contribute feedback from the "small growing into medium
sized project" user space. So apologies for any boat rocking, and thanks
for all your help and a terrific tool that works in-spite of me not
being a DVCS guru quite yet]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070821/05748652/attachment.pgp