On Sep 30, 2004, at 9:30 AM, Tristan Seligmann wrote:
> even if you always release from the same repository subtree
> (eg. trunk), you're referring to data by two "coordinates": location in
> the filesystem, and revision number. By making a copy, you preserve
> both of these coordinates, instead of only one (the revision number).
You only preserve that by making a read-only copy, which is not
directly supported by subversion. (E.g. if this is delegated to Apache,
then the access method http:, svn:, file: would give you different
states of read/write access. So it is not a feature of subversion.)
If the copy is not read-only then then nothing is really 'preserved' at
all.
But it is more than simple access rights. Suppose someone tags a
release and puts the tag somewhere unexpected. I know that there is a
tag representing the state of the trunk at some important revision. How
do I find that tag? Unfortunately it is not easy to look at all of the
tags made of a particular branch throughout it's history, because
subversion does not manage that for you. It is a manual process
relying on naming & layout conventions as it is.
> If you introduce the concept of a labeled revision that is limited to a
> particular subtree, then I see no major difference between a copy named
> '/tags/releases/1.0.0' and a "label" named '1.0.0 release'.
If the label was a property of the thing that was labeled, as Simon and
James have pointed out, you will see them from the 'other side'. A
history of the trunk would show when it was labeled. Finding a
particular tag now works differently, you would have to check
history/logs of each tag to find where they came from and relate that
to the source you were interested in, rather than looking at the source
and finding the important markers that were made on it.
> Of course, if you're proposing to do away with /tags, /branches, etc.
> entirely
I'm not proposing anything like that. I like cheap copies, but they
have some limitations when used as labels. I like the flexibility they
offer, I'm not talking about a different implementation of an existing
feature. I'm talking about a new feature that provides more
information, so that subversion can mange some things that it *should*
know about, rather than making those things something each user must
manage with some external process.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 30 18:44:14 2004