Re: [Gnu-arch-users] Arbitrary version names

[Tom Lord]

    > From: Catalin Marinas <address@hidden>

    > It looks like this was previously discussed but I don't know whether
    > there are plans to allow this. I have a linux--arm--2.6 branch which
    > contains the main kernel with additional patches. Once the tree is
    > stable enough, I would like to create a tag named something like
    > linux--arm--2.6.7-arm1 (that's maybe a CVS oriented thinking),
    > eventually with --seal, and continue the development on
    > linux--arm--2.6.

    > There is another possibility - linux--arm1--2.6.7 but I still think
    > that -arm1 should be part of the version string. Adding a --2.6.7.1
    > version is not really feasable since Linus just released a 2.6.8.1
    > kernel, and the kernel version might have 3 or 4 numbers.

    > The tla modification for this looks quite simple but I prefer not to
    > diverge from the arch concepts. Any other suggestions (or am I too far
    > from properly understanding the arch concepts)?


As miles reported, "Tom doesn't like it" but I'd like to add some info
about *why* i don't like it and under what circumstances my mind can
be changed.  The executive summary is that, in this specific case, I
do like it and patches are (imo) welcome.

The why part: basically, I'm just being reflexively conservative.  I'm
completely convinced (on principle) that the arch revision namespace
needs some (somewhat arbitrary, definately finite) _structure_.  The
same way that real world book libraries need a cataloging system,
revision control needs a roughly 2-d-table naming scheme.  I carved
out such a namespace for revisions and, in doing that, "claimed" only
a very small subset of the space of Strings.  E.g., most strings are
not valid arch revision names.   Those strings that are arch revision
names are partially ordered in various handy ways.

It pays off, in the long run, to be a bit stingy with namespaces.  For
example, if arch names are just a tiny subset of Strings in general,
then I can take some other tiny subset (say, hypothetically, "BugGoo
names") and make one big set that combines, say, arch names and buggoo
names.   As long as the set of arch names and buggoo names are
disjoint, I can let people type in either one or the other and tell
them apart.

Every "relaxation" of the arch revision namespace increases the size
of the set of strings which are valid arch names.  Therefore, every
relaxation *decreases* the possibilities for combining arch names with
some other set of names (like buggoo names).   

Therefore, the only reason to ever relax the constraints on the
namespace is, if in so doing, we add new *structure* to the arch
namespace, and we are convinced that that structure is desirable.

Now, to your specific example.    I gather that you want a
"sub-version branch" added to the namespace.  So that instead of:

        category[--branch]--version--revision

names are:

        category[--branch]--version[--version-branch]--revision

Quite honestly, I think I've changed my mind.   I *do* like that.

It's come up just about once too often.   Even library cataloging
systems undergo (purposefully snail's pace) evolution in response to
need.   The demand for a "version-branch" has come up so often that I
can't really dismiss it any more.

-t