Re: Subversion "labels" vs. "tags"

On 5/23/05, Julian Foad <julianfoad@btopenworld.com> wrote:
> David Weintraub wrote:
> > For example, I'd like to use an older version
> > of a particular file in my current working directory. If I knew the
> > version number, I could do this:
> >
> > $ svn update -r<REV> foo.c
> >
> > But, I can't use the "svn update" with a tag at all. Instead, I have
> > to use svn copy:
>
> No, no, no. Use "switch" for that. Have you read the Subversion book? I
> believe it explains how "switch" is the more general form of "update", able to
> change your WC to reflect another place in your project tree (e.g. to a tag) as
> well as another point in time.

Yes, the book explained how "switch" is a superset of the "update"
command, but it uses it as a way to work off a branch. That is, you
switch the whole URL to a branch. This way, you don't have to create a
whole new working directory, and you hope that the changes between
where you were working and the branch you're currently working on are
minor, so the "switch" command is more efficient than a new checkout.

Is there another way to use "switch"? Can I simply "switch" just a few
files and not my whole working directory?

Many times, developers discover bugs in the most recent versions of a
few files that prevents them from doing their work. They'd like to
revert just those files to the last good build and continue their
work. Once the bugs in the problematic files are fixed, they'll update
once again to the latest versions of those files.

> Ah, but maybe you are assuming that tags or labels only refer to a previous
> version of the current line of development of a file - that is, a direct
> ancestor of the current head. If you want a "label" to be strictly a synonym
> for a revision number, that's a much easier problem and one which is pretty
> much separate from (orthogonal to) Subversions's tags. You haven't yet said
> (on this list) what you want a "label" to be.

Labels can be used as snapshots in time, and I use them to mark the
versions of each file in every build. It isn't uncommon for an
environment have a label like "BLESSED" that points to the last
"blessed" copy of the build.

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.

> You've probably gathered by now how most developers feel about the way tagging
> is done:
>
> o The status quo is intentionally very flexible.
> o It works sufficiently well in practice.
> o The command-line user interface is more clumsy than it need be for the
> common use cases. There is room for improvement and we are glad to discuss this.
> o GUIs can provide a much slicker interface.
> o A need for an alternative or additional tagging concept has not been
> sufficiently demonstrated by anyone.

I agree with the first two points: Subversion is very flexible, and
tags as they stand now do work. Unfortunately, I also agree with the
third point to: The command-line user interface can be awkward when
refering back to a tag/label/or whatever you want to call it. .

The goal is to be able to use whatever labels will be in a fairly
simple and straight forward manner as found in other version control
systems. For example, I can do this in RCS:

$ co -r2.1 foo.c

And, that will check out revision 2.1 of file foo.c into my working
directory. I can also do this:

$ co -rREV_1_2 foo.c

And that will checkout the version of foo.c with the label REV_1_2.
And that will checkout all the files with the label REV_1_2 on them.
(The same with the rcsdiff and all other rcs commands)

This could easily be done by making a lookup table between labels and
revision numbers. However, in almost all other version control
systems, I can selectively apply my label to a subset of files if I so
choose. It allows me to mark what files actually were involved in a
release or build and which ones aren't. A simple lookup table in
Subversion would not allow me to do this.

Maybe the solution is to improve the command line interface to make
tags easier to use in this manner. Maybe the solution is to use
properties and have an easy way to select files via properties. Maybe
the solution is to create a lookup table. To me, the actual
implementation is not important. I hated it when I was a developer and
my managers told me I had to use a particular implementation just
because they thought it was the latest thing to do.

However, labels are an important concept in version control and
configuration management, but they are still awkward to use in
Subversion.

--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org