Bazaar Presentation.

Fri Mar 26 20:04:09 GMT 2010

Hi John,

On Fri, Mar 26, 2010 at 1:36 AM, John Szakmeister <john at szakmeister.net>wrote:

> 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.
>

Thanks for explaining this. It is a good point, and I will update the
presentation to state that the process shown is the simplest method of
migrating a single bzr branch, or Git clone, and that it doesn't migrate
hooks or server-side plugins. I added some extra notes about migrating a bzr
repository, but it should be more strongly noted. As for taring up the SVN
repo, I thought this was discouraged, especially when moving to a different
file system. My understanding is that the svnadmin/dump process is the
preferred and recommended method of migration. Which still makes my point
valid. Migrating a SVN repo the recommended way is still way more
complicated than migrating a Bazaar repo. In my experience, the more steps
there are to a procedure, the easier it is to forget one. :)

>
> 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 do. One thing that I think the presentation is missing is at least one
slide on this very subject. I covered merging a little bit when I explained
how bzr has made my life easier at work, but I can certainly include some of
these other ones. Renames are a true benefit, but unfortunately, you only
really gain this benefit when it's hosted by bzr. Renames in bzr, still come
across as a delete and add when committed to a SVN repo (understandably so).
But it's still a great feature to bring up.

The logs are also a nice feature. I've often shown-off BazaarExplorer to my
co-workers, and the log viewer always raises some Ooohs, and Ahhhs. :)

Are there any others you can think of that would be worth showing?

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

I completely agree. Popular tools exist because they help their users. If
SVN didn't serve a purpose, it wouldn't exist, or at least, it wouldn't have
survived and become as popular as it has. SVN has served us very well up
until this point, and it's because of some recent developments with a larger
and more distributed team that it's just now starting to "fail". We are
certainly making due with SVN, but moving to a DVCS, would make our lives
easier, and it's my opinion that Bazaar is the right DVCS for our needs.
This is primarily due to Bazaar's flexibility, it would allow us to work the
way we want, team to team. Each team can make use of a different work flow,
or combination of workflows to fit their needs.

This is something Bazaar does well I think. It's ability to work the way we
want to work is really (in my opinion) what sets it apart from the others.

Just m2c.
Eric

-- 
Learn from the past. Live in the present. Plan for the future.
Blog: http://www.townsfolkdesigns.com/blogs/elberry
jEdit <http://www.jedit.org> - Programmer's Text Editor
Bazaar <http://bazaar.canonical.com> - Version Control for Humans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20100326/316e5f0c/attachment.htm 