[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion "labels" vs. "tags"

From: Brad Appleton <brad.appleton_at_gmail.com>
Date: 2005-05-25 08:08:42 CEST

David Weintraub wrote:
> Making labels synonyms for revision numbers would probably accomplish
> 90% of what is needed for labels (and with the use of tags and hooks,
> we could do the rest). However, in all other version control systems,
> you can choose what to tag. If I have four separate projects in my
> repository, I may only want to label the flies in only one of those
> projects. If labels are synonyms for revision numbers, putting a label
> would mark all of my projects.

Julian Foad wrote:
> OK, so you don't want a "label" to just mark a point in time, you want
> it to mark a set of particular versions of particular files. So the
> concept is the same as Subversion's "tags"; it's just the useability
> that bothers you.
> If you will now agree that the concept that you call a "label" is the
> same as the concept that Subversion developers call a "tag", then we
> seem to have arrived at a shared view.

I think that labels/tags and revision-aliases are different things that
may indeed have some overlapping uses but which ulitimately serve
different purposes:

* I use labels to define my own configurations to the VC tool: when I
want to define the configuration, including the set of things in it as
well as the set of versions of those things, I use a label. And I give
it a meaningful name.

* I use aliases to reference configurations that were automatically
defined for me by the VC tool: when the version-control tool
automatically tracks the state after each commit, and assigns it a
number, and when I want to associate a meaningful name with that, I use
a revision-alias

In a nutshell:
- a label is "call by value" (or by "copy")
- a revision-alias is "call by name" (or by "reference")

aliases are references to an immutable configuration. I can change the
reference, but I cannot change the content it references. If I need the
same name to refer to a subsequent configuration, I dont change the
definition of the configuration, I reference a subsequent configuration
with the same name (thereby "moving" the reference)

aliases also need not create any nodes/copies in the directory tree, for
that is not their purpose. They are an alternate lookup-name, they arent
  intended to be the same as immutable copies with all the semantics
that go with it (e.g., versioning).

I would use aliases (rather than labels) for things like "checkpoints",
or to capture the current "blessed" configuration (e.g., a floating
label). I would not be inclined to use them to establish formal
baselines that I would eventually freeze. I would be inclined to use
labels to establish formal baselines that I then freeze once they are
"baselined" (blessed).

Several folks seem to be equating "copies" and "aliases" as different
implementations of the "same solution/feature". I think they are not the
same or equivalent solution/feature/ I think they do different things
associated with different purposes. And while it is true some of the
effects of each are the same, each has effects that are different from
the other, and those effects are what would make me choose one over the
other in a given situation.

Someone was concerned about "revision aliases" not being clear about
which portion of the repository they reference. I think that, based on
the above, it would be very clear. The revision alias is no more, and no
less "global" then the revision-number. Anywhere you could use the
fully-qualified revision-number, the "alias" would mean the exact same
thing. Anywhere you could use the unqualified global revision number,
the alias would mean the _exact_ same thing. It's simply a lookup that
adds an extra-level of indirection to "macro expand" to a revision number.

That's my $0.02

Brad Appleton <brad@bradapp.net> www.bradapp.net
    Software CM Patterns (www.scmpatterns.com)
    Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 25 10:46:30 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.