octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving to Octave Forge to mercurial


From: Patrick Noffke
Subject: Re: Moving to Octave Forge to mercurial
Date: Fri, 14 Jun 2013 10:21:48 -0500

As long as you are considering changing things, I wanted to throw out
bazaar (http://wiki.bazaar.canonical.com/) as a candidate.  Perhaps
you've already considered bazaar in the past, or perhaps it is worth
considering again.

For their sales pitch, check out this:
http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html

A counter-point (based on an older bzr sales pitch) from Mercurial is here:
http://mercurial.selenic.com/wiki/BzrVsHg

Bazaar can interface to svn, git, hg, and other repos.  I've used the
bzr-svn plugin over a year ago.  I found it to work fine when pulling
down a svn repo, but when parallel work was happening in both bzr
(branch of svn) and svn, when I tried to merge work from svn, things
broke.  The issues I had may have been fixed, but because I pulled
down with an older bzr-svn, and did a lot of work, my branch was
screwed up and I couldn't really get past the issue (basically I
needed to start over with the newer bzr-svn plugin, re-do all the
work, and then hope for the best).  I don't know if this would apply
to Octave, since, once we switch, I would expect the old repos would
be blocked from commits.  In that case, you probably just want to
import the repo directly into the new one.  If you want the gory
details of my issue, see here:
https://bugs.launchpad.net/bzr/+bug/485601

Here is info on the foreign repo interfacing:
http://wiki.bazaar.canonical.com/ForeignBranches

I really like bazaar's GUI tools (especially qbzr).  See the first
link above for a screenshot showing the history (second figure).

I didn't know until reading the sales pitch that you could associate
bugs with check-ins.  However there are other ways to do this, such as
trac.edgewall.org (where you can easily cross-reference bugs to
commits and vice-versa).  But maybe there's a way to associate the
savannah bugs with the commits, I'm not sure.

I have found bazaar's performance to be fine when using a native bzr
repo.  But when using bzr-svn to branch from a 3GB+ svn repo, it was
slow as a dog and used a ton of RAM.  Don't ask why our repo was so
big.

I also really like the concept of treating file and directory renames
as first-class citizens.  I'm not sure how much of an issue this is
with mercurial, but bazaar's approach is way better than svn's
handling.

The stacked branches kind of sound like they might work for working on
the 90 or so packages, but I'm not sure yet.
http://doc.bazaar.canonical.com/latest/en/user-guide/stacked.html

They have the concept of nested trees, but take note of the first line
on this page:
http://wiki.bazaar.canonical.com/NestedTreesDesign

A SO answer recommends using bzr-externals instead of nested trees:
http://stackoverflow.com/questions/6161085/nested-trees-design-in-bazaar
https://launchpad.net/bzr-externals

I use bazaar at home for all my personal projects, but I don't have
any complicated workflows to deal with there.  Nonetheless, I've had
no issues at all with those repos.

Patrick


reply via email to

[Prev in Thread] Current Thread [Next in Thread]