Re: [Gnu-arch-users] Bazaar 1.3 preview

[Robert Collins]

On Fri, 2005-04-01 at 10:05 -0600, John A Meinel wrote:
> David Allouche wrote:
> > On Fri, 2005-04-01 at 01:09 +0000, Mikhael Goikhman wrote:
> > 
> >>I didn't try baz 1.3 preview, but I would like to know about the status
> >>of several issues.
> >>
> >>1) Don't you think "tree-id" command is misnamed? Use "tree-rev" name
> >>if you feel "tree-revision" is not short enough (I don't feel so).
> > 
> > 
> > I concur.
> > 
> Well, one thing that I've notice digging through the baz code, is that 
> they actually are trying to restructure it, to potentially allow changes 
> to the namespace. I can't say where they are going, but some of the 
> structures look like a good place to change from c--b--v to maybe 
> c--b--v--s, or c--b1--b2--b3--v, or something like that.

The goal with the restructuring is to make libarch more agile. Tom has
talked about 'sub-version-branches' for example. (c--b1--v--b2).
Supporting that /should/ be no more work than teaching the namespace
that that is a valid patch-container, and the various serialisation
formats how to store such things. At the moment that is quite a hurdle :
the revision library, and the {arch} tree are not structured well for
that (the path length grows with bad O for every added component). The
baz archive is structured well to handle such variation - but will still
have problems : names varying only by case, and names so long some fs's
cannot have a single path element with that name.

> So it might be possible that because of a potential namespace 
> restructure they are looking to use a more generic term "id" then 
> sticking with revision.

The reason I didn't use 'tree-revision' is that its likely confusion to
users to see 'tree-version' and 'tree-revision'. The former would be
called 'branch' or 'tree-branch' or something similar in most other
[RV]CS's. version and revision are used interchangably by other [RV]CS
tools - we're the only one that I'm aware of that has two terms with
such a similar dictionary meaning having radically different meanings in
the tool.
(http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=version&x=0&y=0 
meaning 3 and 
http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=version&x=0&y=0 
meaning 2). 
When the user interface /requires/ users to understand that our meaning
of version is 'the controlled softwares version' and not 'the last
commit I did' - then its confusing.

So while tree-id isn't /great/ - and I'm looking for a great name - it:
is less confusing than having tree-version and tree-revision
is intuitive to new users (yes, I've asked).
better than renaming tree-version when the rest of the model still talks
about 'VERSION' when other systems would say 'branch'. Or 'Line of
development'.

> The internal structure they use is called arch_patch_id, which calls 
> fully qualified version name == branch. So internally the place where 
> patches go is a "branch".

Right... see above. If you abstract out the namespace as a policy
object, not a functional one, then you can change it rapidly when you
want to ;). In that model you have 2 components for a revision : the
branch its in, and the patch itself. Everything else is policy, and
should be mutable without breaking the rest of the code. Thats the goal
anyway.

Rob

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