gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Making microbranches popular


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: Making microbranches popular
Date: Tue, 27 Jan 2004 08:24:06 -0800 (PST)

    > From: Mirian Crzig Lennox <address@hidden>

    > That's the solution I would favour.  I don't think the sorting is that
    > huge an issue; version number sorting in tla-1.1 was broken for months
    > before anyone noticed.  When it was finally fixed, nothing else
    > stopped working.  That suggests to me that (a) version number sorting
    > isn't as important as people might think, or (b) that version numbers
    > in their current implementation are so limited that people aren't
    > using them.

The problem isn't sorting -- the problem is namespace complexity and
namespace ambiguity vs. user expectation.

The "namespace ambiguity" problem refers to the disjointness of
archive names, package names, and version names.  It's handy to be
able to look at a string and tell which of those three things it is
without having to searching through archives.   Package names and
version names can in theory be made more liberal -- but they can't be
made completely arbitrary.   A single string must never be both a
valid archive name and a valid version name, for example.

The "user expectation" problem refers to what happens when you start
to make the various kinds of names almost-but-not-quite-arbitrary.
It signals users that the intention is to let them use any name they
can think of.   But they can't use any name they can think of without
triggering the namespace ambiguity problem.

A simple solution here is to simply not lie to users by creating the
illusion of arbitrary names.  Instead, pick name syntax that is
sufficient but not particularly ambitious -- something that only
"takes over" a relatively small part of the namespace of strings.
That keeps the code simple and maximizes opportunities for future
extensions.  Alas, it generates complaints of the form "that's _too_
restrictive for my needs."

An alternative solution is to try to make the names as permissible as
possible.  To create the illusion of arbitrary names.  That makes the
code harrier and makes future extensions more difficult.  Each time
the set of permitted names changes, ancillary tools such as browsers
must be updated (and if the change collides with some names that
_they_ are already using .....).  Alas, it will predicatbly generate
complaints of the form "that's _too_ restrictive for my needs."

-t




reply via email to

[Prev in Thread] Current Thread [Next in Thread]