Bazaar Presentation.

[John Szakmeister]

On Thu, Mar 25, 2010 at 1:19 PM, Eric Berry <elberry at gmail.com> wrote:
[snip]
> I don't quite understand. To be honest, I haven't performed a full migration
> with bzr yet either. At least, not one where I've had to worry about hooks
> and plugins. Are you referring to migrating a single bzr branch, or a full
> bzr repository, and are you cautioning that the plugins and hooks won't go
> along with a push?

There was a long description of the process to move your subversion
repository from one location to another (svn dump, copy your hooks,
copy DB_CONFIG, create the new repo, load it, copy the hooks back,
restore DB_CONFIG), but a short one for Bazaar and Git.  I see several
faults with that.  One is that the procedure for Subversion is what it
is to help make sure you get all your hooks back into place, but the
Bazaar version didn't account for that.  You could move the repo by
just pushing it somewhere, but that doesn't take care of the hooks
because they're plugins, and plugins don't get transferred.  And,
Bazaar operates only on branches, so to take a whole shared repository
isn't a matter of a single pull/push.

Also, the Subversion story is much simpler these days.  FSFS is the
default backend.  So you can simply tar up the repo, and untar it
somewhere else.  Couple that with svnserve (my preferred hosting
technique), and it's really not so hard to move a Subversion repo.

> From my understanding, a bzr branch, or repository can be migrated using
> simple methods like rsync, or just taring up the entire directory. I'm
> assuming the same could be done with installed plugins and hooks. Is this
> correct?

That is true.  But that's not what was outlined in the slides.  The
hooks story gets a little more interesting if it's installed
system-wide or just for the user hosting the repositories.  A
system-wide install would be more difficult to just tar up the hooks
and plugins.  Either way, those hooks aren't stored with the repo or
branch, they're stored in either ~/.bazaar/plugins or have been
installed system-wide in $SITE_PACKAGES/bzrlib/plugins/.

I think in the end, Subversion is easier than was outlined, and Bazaar
is a little more complicated than outlined.  I personally think it's a
wash.  Some would say that the hosting story is better for Bazaar, but
as I'm currently trying to do that (and setup appropriate access
permissions and such), I'm inclined to disagree with that as well.

OTOH, there are some great features in Bazaar that you can't match
with Subversion today.  Branching and merging being the biggest.
Subversion does have merge tracking, but you have to tell it whether
you're re-integrating or not (and we usually forget that at some
point, which means we have to revert and try again).  Bazaar's Just
Works for most merging operations (the one place Subversion has Bazaar
beat is with cherry-picking revisions, but we do that relatively
little in our environment).  The other nice feature is true rename
tracking.  In Subversion, if you branched and made some fixes, then
tried to re-integrate those on trunk, but the files had been renamed
on trunk... well, you lose.  It patches the old version of the file
(although it may actually raise a tree conflict today... I haven't
tried this in a while). :-(  Bazaar recognizes that the file was
moved, and correctly patches it.  Bazaar's ability to have the entire
history of the branch at your fingertips is also very nice.  Coupled
with qlog, it's extremely powerful.  On the flip-side, for a really
active repository (multiple committers, and fairly frequent changes),
you have to constantly update your branch/working tree in Bazaar
whereas Subversion will silently rebase your changes.  The plus side
for Subversion is that your developer's aren't constantly faced with
errors telling them to pull and update.  The down side is that you
can't checkout revision X and have the exact same working copy that
you did when you made the commit.  Bazaar rigidity here helps to
ensure you can always get back to that exact state.

Maybe it's worth talking about that stuff in the presentation?  I
don't think the advantages/disadvantages are as cut and dry as "Bazaar
is better than Subversion" or "Git is better than Subversion" (despite
Linus's opinion).  It really depends on how your organization uses
those tools, what the structure is, what's willing to change about
that structure, what tools are you willing to put into place to help
cope with some of the differences (such as PQM-like entity to help
merge changes to trunk), and whether the kind of data your putting
under VCS is suitable (one project I've worked on in the past had a
lot of media and multi gigabyte binary files... that would fail under
most DVCSs today because of the assumption that they can hold the
entire content in memory).

That was a longer response than I initially intended, but hopefully
it's useful. :-)

-John