octave-maintainers
[Top][All Lists]
Advanced

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

bzr for Octave


From: Jordi Gutiérrez Hermoso
Subject: bzr for Octave
Date: Fri, 14 Jun 2013 11:49:59 -0400

On 14 June 2013 11:21, Patrick Noffke <address@hidden> wrote:
> 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.

bzr is sadly dead or moribund:

    http://stationary-traveller.eu/pages/bzr-a-retrospective.html

Its own developers don't recommend it anymore.

I am truly sad about this, because bzr worked very hard to present a
nice UI, which is more than can be sad than the current leading brand
in DVCS. I like hg because it also tries to be nice to the user, even
if it doesn't work as hard at it as bzr.

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

This is something that we do manually right now by putting the bug
number in the commit message. A real system would involve patching
Savannah. Or we could use something crazy like b:

    http://www.digitalgemstones.com/projects/b/

Our current system seems to be working well enough, though.

> 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've used bzr a few times with Emacs. Its performance did not impress
me. Octave has approximately as long of a history as Emacs, so I
wouldn't expect bzr to work well for Octave.

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

hg rename handles this case fine.

> 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

At a glance, this is approximately the same as what we're doing right
now by having GSoC students clone our repo, work on it, merge it
regularly with Savannah, and submit pull requests.

> 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

This is sort of like Mercurial subrepos. The problem is inherently
complicated in all VCSes.

- Jordi G. H.


reply via email to

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