To merge or not to merge?

[John Arbash Meinel]

Aaron Bentley wrote:
> I thought I'd share an interesting dilemma: should I branch, merge or
> pull?  I'm not sure what it says about our model that I'm confronting this.
> 
> I'm about to do some more hacking on the 'log' command.  I've got a
> 'log.perf' branch, which seems like the appropriate place to work.
> Currently, my log work is shown as 'fully merged', which means that its
> line in bzrk stops last Saturday.  If I merge bzr.dev, commit, and then
> submit to PQM, that line will be added to the bzrk display for the past
> week, and that display is already 10 lines wide, with 5 colour
> repetitions.  So doing a merge is selfish-- it takes up a lot of space
> in bzrk.  And in general, it makes visualization of the development
> process trickier.  For continuing work, it would be necessary.  Since
> it's not, I shouldn't.
> 
> In the old days, I could pull bzr.dev without throwing away my history.
>  That would show nicely in bzrk, as a convergence and then a split.
> Nowadays, it makes my branch basically indistinguishable from bzr.dev,
> though the display in bzrk is basically unaffected.

Well, my understanding of Robert's changes to bzrk is that it actually
shows a merge at this point the same way you would show a pull. As a
convergence in the past, and then a new tip starting.
Because of that property. If the entire branch has been merged in, and
then you merge back, it isn't interesting enough to warrant a whole new
line. The changes weren't "in-flight" at the same time as when other
people were working.

> 
> Finally, I could start a new branch, of bzr.dev.  Maybe I'd set the nick
> to log.perf, or maybe I'd just call the branch log.perf2.  But that
> clutters my repository.
> 
> So for this case, I've decided to just pull.  I can't really envision a
> use for my existing log.perf branch.  Anyone curious enough can just get
> the revisions from bzr.dev.  Software archaeology can be fun, but you
> can get too obsessive about these things.  Perhaps if we had tags, I'd
> leave a tag on my log.perf last revision, but it's ultimately not such a
> big deal.
> 
> Aaron

From an 'this the stuff I worked on' point of view, doing the merge is
better. It is also better from "Aaron's log.perf branch introduced a
bug, lets figure out what change of his it was".
Because of nicks and bzrk, we probably could figure out a good head to
go back to. But it is also nice to just have a branch sitting there
which has the right left-hand parents.

If you use bzrk, you could find the revision-id, and then do a 'bzr
branch -r revid:foo' and have it again, though, so it isn't a strict
requirement.

So, I would merge. Falling back to pull as the next best thing, and
branch as the least desirable.
John
=:->

PS> I think the reason it is 10 lines long is since the sprint, there
has been a lot more concurrent development going on. And I know I've
been working harder to get user patches merged. And since we now use
bundles, they all show up as independent development, rather than patches.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060622/279523ca/attachment.pgp