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

[John A Meinel]

Martin Langhoff wrote:
> On 8/21/05, Matthieu Moy <address@hidden> wrote:
>
> > What's the future of tla 1.x? Same for 2.0. Given that the main
> > contributors of GNU Arch--except Tom--are mostly people working now on
> > Bazaar-NG, I _guess_ Bazaar is the way of the future.

...

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

Just as a point of clarification, bazaar-ng (bzr) is actually snapshot 
centric, rather than patch-centric.
It does similar hashing for everything. But it associates a unique 
identifier to each hash, rather than using the hash as the identifier.
(One problem with using hashes as ID is that if you do get a collision, 
there is nothing you can do about it.)

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

In bzr, if I have merged from you, I generate a revision, which you can 
then pull into your tree, so the trees have slightly different looking 
history, but are effectively equivalent.

It isn't quite the same, since in git, if you and I happen to make 
exactly the same change, then we have the exact same tree identifiers. 
But there certainly is work to do merging such that you don't have the 
back-and-forth problem of Gnu Arch.

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

I'm not sure what you mean by being able to "edit the patch". You can 
always do that. Even if you apply it, and then modify the code, you have 
effectively modified the patch.

bzr is looking to have a slightly modified patch(1) format as an 
emailable changeset. For basic changes, you can just use the patch 
program to apply it to your tree. But patch doesn't actually handle 
everything (it doesn't handle renames very well, and certainly doesn't 
track which file a patch should go to if there has been a rename in the 
past).
For the bzr specific portions, we take advantage of the pieces that 
patch ignores (a header and footer, and the one line with *** before 
each actual patch).


> 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 think you need to be aware of what "the core" is. That has been the 
core for Gnu Arch.

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

My understanding is that the reason Bazaar-NG has the NG is because they 
are planning on transitioning from the current Bazaar into the new one, 
once the research portions have been done, and various features have 
solidified.

From what Robert Collins has stated, each version of Bazaar, will 
likely incorporate a few important solid features from bzr, until 
eventually they are the same. With a definite road such that you will 
always be able to upgrade a version 1.X tree into a 1.X+1 tree.

I think their compatibility standards are slightly stricter than that. 
But I suppose in some ways, yes, Bazaar as it stands right now, will 
eventually be phased out. But only because it is evolving, not because 
it is being dropped on the floor.

> cheers,
>
>
>
> martin
> pd: send flames privately if you must. please ;-)

John
=:->

signature.asc
Description: OpenPGP digital signature