Re: [Gnu-arch-users] Re: baz, --full option, revision lists: What's the best behavior?

[Robert Collins]

On Tue, 2005-05-24 at 22:09 +0000, Mikhael Goikhman wrote:
> On 24 May 2005 21:03:39 +0200, Matthieu Moy wrote:
> > Since some commands display more than one version, the best way to be
> > consistant would be to have --full by default everywhere. Another
> > issue with this short format is that many commands currently limited
> > to one version, but could be extended to be able to follow history and
> > display several version names.
> 
> There are several issues here. The tla design strongly suggests that
> commands "revisions", "library-revisions", "missing" and "logs" work on
> one version only. And I mostly like this, as well as the arch namespace,
> something that bazaar[-ng] people want to remove.

The issue with the arch namespace is its punning with revision identity.
This makes the software able to be confused by people naively fiddling
with what they perceive as their data. I.e. 'I'm done with branch
foo--bar--0, I'll delete it.' A week later 'Time for a new branch,
foo--bar--0' - and *boom* - their cache, other peoples mirrors, cached
topology in siblings or derivatives of the old branch all get very
confused very quickly.

As a policy *tool* I'm very much in favour of a namespace that knows
about people and projects and branches and ... whatnot. However the
management of revision identity and the namespace should not be coupled
- the namespace should be layered on top such that:
 * branches can be deleted and recreated
 * anonymous branches can be created - this is a massive win in terms of
lowering the barrier for entry - and makes tools much more lovable.
 * The namespace can be extended without compromising the ability of
pre-extension tools to checkout code - or of third party scripts to do
the right thing.

A while back Tom proposed extending the Arch name space with a couple of
features (please excuse any minor errata here : this is from memory). 
The feature I want to raise here is the punning-based solution to the
'users want to reuse the namespace'. He proposed that each section of
the namespace get a sequence number, and that the system then treat
unqualified sections as requests for the highest sequence number. This
is a reasonable approach to solve the 'branch recreation' problem - but
doesn't solve the anonymous branch problem (and no, having reserved
names in the namespace doesn't), nor the namespace extension problem.

So yes - the namespace *as it stands today* must go. That said Martin
and I still disagree on exactly what should happen to it ;).

Cheers,
Rob

signature.asc
Description: This is a digitally signed message part