Brad Appleton wrote:
> I think of a mnemonic name for a revision as something different from
> the sort of first-class label some are speaking of (one that possibly
> requires versioning of the configuration of the label, in order to be
> The mnenomic is simply an alias. I could possibly even define more
> than one for the same global revnum (provided the name isnt already in
> use). The purpose isnt to define the content of the configuration
> corresponding to the revnum, the purpose is to be able to use a
> meaningful, memorable name for a state of the codebase that is
> automatically stored+tracked by the system anytime I checkin.
> With "tags" or "labels" as most tools implement them, the purpose IS
> to define the content of a configuration of the system that is
> otherwise NOT auto-captured, *and* to associate it with a meaningful
> name. I think there is a use for that as a separate thing in SVN, and
> that "copies" with some read-only flag set serve that purpose just fine.
> A traditional "label" manually creates a named configuration.
> A revision alias simply associates a name with an autogenerated
> id/address for an automatically created+stored configuration.
> I think they are different things, just like the list of symbol names
> in a symbol-table is different from the actual data/memory values that
> are referenced by the addresses that the "symbols" map to.
Ah, the voice of reason! :)
I can only say that I agree 100% with the above.
Of course, at this moment it takes a bit of work to actually get a
non-modifiable tag in Subversion, what with having to install and manage
a hook script that allows additions to a tags/ directory but disallows
modifications within it. But I see this as a minor usability bug, not a
problem with semantics. In-repository ACLs would solve that issue, and
server-side configuration could solve the "finding the tags directory"
issue for clients. Both features are on the roadmap.
BTW, everywone who's pushing for labels in a separate namespace (i.e.,
something that would behave just like the current tag-like copies do,
but would be stored differently) should bear in mind that DAV
interoperability practically forces us to have directories, branches and
tags in a single tree (namespace).
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed May 11 15:49:58 2005