[Top][All Lists]

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

Re: [Gnu-arch-users] Future of GNU Arch, bazaar and bazaar-ng ... ?

From: jblack
Subject: Re: [Gnu-arch-users] Future of GNU Arch, bazaar and bazaar-ng ... ?
Date: Mon, 22 Aug 2005 15:42:24 -0400
User-agent: Mutt/1.5.9i

> I apologize if this is a bit tactless and offtopic. After using Arch
> for a long time, and playing with other SCMs ocassionally, I am
> preparing to transition all my projects to GIT. I have been polishing
> the cvs import that git includes, and I have an extremely draft Arch
> importer I've been working on this weekend on a ferry trip across the
> Cook Strait. I will be polishing it through the week.

Different strokes for different folks. Git and Bazaar tackle different,
but related problems and what works for me may not work for you. 

> This transition is tainted by the fact that patch-centric SCMs have
> disappointed me a bit. GIT (I am actually using cogito, which provides
> nice and easy shell wrappers) is patch-smart but not patch-centric,
> and the more I use it, the more apparent it is that is a good design
> decision.

By the time Git starts handling the problems that Bazaar is, its going to
bump into the same problems that Bazaar is.

> YMMV. Arch and other patch-centric SCMs are forever-diverging: there
> is nil support for identifying when two branches are identical. If a
> small group of developers work on their own branches, and exchange
> patches, most if the time you have the same tree, just different
> "record" of patches. GIT knows that instantaneously, and marks it as
> an un-branching: convergence. The trick of constantly hashing files
> and trees pays of handsomely.

Its certainly true that Arch and company have had a rocky few years. I
think that sort of problem should be about over with Bazaar 2.0. Bazaar
2.0 is designed _specifically_ to handle most of the problems that the
first set of 3rd gen revision control systems learned about -- often the
hard way. 

That said, not all of the problems have been solved quite yet. There's
still a problem or two out there that are Really Tough to solve.

> GIT doesn't natively do cherry-picking. It tries too hard to merge
> branches fully to be good at that. But you can use Stacked GIT (StGIT)
> which does cherry picking and many patch tricks on top of GIT. As git
> is doing the 'formal' SCM, StGIT stacks patches on top of a formally
> committed history. Patches in the stack are extremely malleable - a
> weirdly nice concept of being able to "edit the patch". One of git's
> GUIs, qgit, is poised to start doing cherrypicking, possibly based on
> StGIT.

Definitely cool. How many patches can it track before it starts falling

> OTOH, Canonical people are doing some really interesting things with
> bzr and hct. hct  is tied to their launchpad project (there was a good
> talk at Debconf5 about it); I think it's interesting, specially if you
> are looking for patch-centric tools. Canonical has a strong driver:
> they need strong SCM tools to manage Ubuntu efficiently. It's a bunch
> to watch, even if I don't agree with the technical decisions at the
> core of their SCMs.

I left this one because I like reading it. :) 

> Sorry again for flogging a different scm. It's strange times for Arch
> users, as tla is orphan and baz will probably be orphaned by Canonical
> at some point not too far away.

Nah. We haven't orphaned Bazaar. There's a Bazaar 1.x and a Bazaar 2.x.
Different code bases, different implementation, but still solving the same

You don't need to worry. If you use Bazaar today, the company will make
sure that you'll be able to use Bazaar tomorrow. =)

 James Blackwell      |   Life is made of the stuff that hasn't killed
 Tell someone a joke! |   you yet.                       - yours truly
GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400

reply via email to

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