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: Mark Thomas
Subject: Re: [Gnu-arch-users] Re: Making microbranches popular
Date: Tue, 27 Jan 2004 18:54:31 +0000 (GMT)

I've been pondering this for a while now, and I have a suggestion.  It's
quite heretical, but please consider it :)

I think we might need a radical shake-up of the namespace.  Ignoring
incompatibility briefly, I suggest the following:

Reorder `category--branch--version' to `category--version--branch'.  If we
are popularising microbranches they *are* subordinal to versions, unlike
the unrelated cartesian space that Tom has referred to before.  This
should also avoid some confusion amongst users: when I initially started
using Arch, I didn't realise that branches were supposed to be related
trees, so I had things like proj--devel, proj--report, proj--presentation,
and so on.

Make both version and branch optional (though branch requires version), in
the sense that `category', `category--version' and
`category--version--branch' are all valid as fully qualified branch names.

Relax the character type constraints so that:

* Categories can contain any character other than whitespace, @ and --.
* Versions and branches can contain any characters other than whitespace,
   = and --

The lack of @ in a category distinguishes it from an archive name. -- is
used as the separator, of course.  I will mention = below.

Sorting amongst versions could be done by:

repeat until difference is found
  {
    skipping all non [[:alnum::]
    pattern matching  ([[:digit:]]+|[[:alpha:]]+)
    compare digit matches numerically, alpha matches lexically, and
    always digits before alpha.
  }

This might not solve all cases, though (which I think was Tom's objection
to arbitrary version numbers).  I think this should be good enough for the
most popular cases and is certainly better than munging them into the
existing namespace.

I think this will work for nearly all cases.  We will now get names like:

  tla--1.2                    mainline devel for tla
  tla--1.2--markbt            my personal branch
  tla--1.2--integration       an integration branch
  tla--1.2--small-fixes
  tla--1.2--syntax-change     an example microbranch

Plus people can have:

  project--1.4a
  project--1.4b
  project--1.4b--bug-5243-fix     a microbranch :)
  project--1.5
  project--1.5a
  scratch
  website--2004-01
...

At this point, we have of course lost upwards compatibility, but we still
have backwards compatibility if we accept the quirk that version numbers
and branch names have been reversed.

I would also like to propose a change in archive and patch-log directory
structures, that is:
   category/category--branch/category--branch--version
be changed to
   category/version/branch

In the cases where no version or branch is given, =default can be used
(hence my reservation of = in version and branch name).

This breaks backwards compatibility unless we explicitly code it or
convert archives and trees :/



Like I said, heretical stuff.  It's just a suggestion.

Regards,

  Mark.

*puts on asbestos underwear*
-- 
|| Mark Thomas
|| efaref.net
||
|| Cats know how we feel. They don't give a damn, but they know.




reply via email to

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