Re: [Gnu-arch-users] Re: [BUG] feature plan -- downstream branches

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > Miles Bader wrote:
    > > On Tue, May 25, 2004 at 05:13:51PM -0400, Aaron Bentley wrote:

    > >>In fact, is it a programmatic requirement to have it in the 
    > >>package-version?

    > > Note the comment that branches containing `:' will be hidden in 
listings of
    > > branches (abrowse, etc) unless otherwise instructed -- I thined this is 
a
    > > very good feature, and it obviously is a lot simpler/cheaper to 
implement if
    > > you can do it just by looking at the name... (looking at the patch-logs 
is
    > > enormously expensive)

    > Looking at the patch-log for the latest revision isn't that expensive. 
    > (according to my reading, the variables would be copied from patchlog to 
    > patchlog.)  Often less expensive than reading a .listing file.  And 
    > there'd be other goodies in there, like the branch-description, that 
    > you'd likely want to see when [ar]browsing.


Sure, but, think bigger, or with broader scope.  There will be
situations where what you have is a list of version and/or revision
names, and want to browse those sensibly --- but you won't necessarily
have ready access to the corresponding archives.  So it has to be all
in the name.

There's a design principle there that I'm not great at articulating:

On the one hand, you have physical properties of revisions (such as
ancestry and, with this feature, version variables).

On the other hand you have logical properties of revisions provided by
their location in the arch namespace.

You could think of the arch namespace as a _cataloging_system_ for
revisions subject to the constraint that it may not be deterministic
(e.g., presumably the revision level for a revision with no ancestor
is base-0 but, strictly speaking, nothing requires that.   The name,
"base-0", if applied in the expected way, helps you find stuff --- but
arch doesn't lock down the meaning of that name.

There's two distinct activities going on:  people are making actual
revisions (with their specificity of ancestry and so forth) --- and
they're also, separately, naming those revisions.

The upshot is that the namespace should have features that _resemble_
features of the "physical" revisions (e.g., downstream branches) ---
but it's a separate thing.

For some reason, this pattern of a separate but imprecisely analogous
cataloging system seems to work out in some situtations (e.g.,
libraries).

The namespace should be structured in such a way as to make a
reasonable cataloging system for revisions ---- and the revisions
should be structured by things like ancestry relations and version
variables.  Separate, comperable, often highly correlated .... but
more or less separate.

(So, you might ask, why can't I use `import' to create a patch-34
revision?  And the answer is: yes, someday we have to take those
training wheels off so that you can.)

-t