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

[Martin Pool]

On 8/21/05, John A Meinel <address@hidden> wrote:

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

I'd say it like this: bazaar-ng (like arch, unlike
monotone/git/mercurial) uses hashes for integrity checks, not for
identity.

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

It's perhaps best explained by an example:

Suppose you send me a patch to do something, and I say "OK, but please
fix X", and we iterate a few times.  In a sense the patch itself is
evolving.  But most scm systems don't track this: it's either
committed into a particular branch or not.  Once it's committed, it is
in some ways lost: a later update of conceptually the same patch is
not strongly tied to the previous ones.  What quilt and stgit do is
keep the patches as patches, so that you can see how they change over
time.

A different approach is for the work conceptually represented by that
patch to be on its own named branch, which is repeatedly merged (or
not) into the mainline.  This is more or less what Scott's HCT
(hypothetical changeset tool) does, and it is being used for this by
some people working on Ubuntu.

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

This has changed a bit over the last few weeks: Mark is happy with how
the Python code is progressing and the reaction to it from people
inside and outside Canonical that we're going to focus much more on
bzr, and on building tools like hct on top of it.  That doesn't mean
baz 1.x is going to be dropped on the floor, but there will be a
tapering-off of contributions from Canonical people in coming months. 
So the future of the arch C codebase (including baz 1.x) depends
mostly on where other people want to take it.  I hope people who have
been using tla/baz will like bzr and choose to move to that.

-- 
Martin