Exactly! I'm getting the impression that the term "label" has some
semantic baggage here, and this is the root of some of the issues.
I, for one, have never seen a label as anything more than a symbolic
name for a revision that *cannot* be changed -- it's set at commit time
(e.g. as a --label flag on svn commit) and that's the end of it, apart
from the ability to use the label again in "--revision" switches.
Now, applying the 80:20 rule, I feel this gives most of what people need
without a massive re-design/development effort.
--Tim
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
> "TimeSafe").
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 12 22:55:15 2005