On Wed, May 04, 2005 at 01:13:01AM +0200, David Gómez wrote:
> Hi Tim ;),
>
> On May 03 at 02:24:49, Tim Hill wrote:
> > I confess not to understand the "anti-label" arguments...
>
> I don't understand them either. We know the good things about "svn
> copy", it's a O(1) operation, it doesn't takes a lot of disk space,
> etc. Nobody says "svn copy" is bad. I think it's a good system to
> create branches, and for create tags for whoever wants to have that
> directory structure.
>
> But it'd be very useful to provide the additional possibility to add
> mnemonic names to revisions an be able to reference them with the -r
> parameters. As somebody said, i don't know if it was you, it's
> exactly what it's been doing now with dates and keywords (BASE,
> HEAD, etc.), so why not add a method to create your own tags?
[...]
Excuse me for chiming in here, but I'd like to say I agree with this,
too. IMHO, we should not confuse symbolic revisions with tags (in the
CVS sense). This used to be my mental block that made me dislike
symbolic tags, but now that I consider it more carefully, it does make
a lot of sense.
First of all, forget about CVS tags. We all know that is already
adequately addressed under the current system. But consider this:
Subversion is essentially a filesystem with full history over time.
The reason we want a filesystem with time history is so that we can
retrieve the state of the filesystem as it was at time X. But since
the history of the filesystem generally has a lot of checkpoints (lots
of commits), it is infeasible for a user to keep track of which
checkpoints (revision numbers) are of interest. In fact, in the ideal
case we *don't want* to require the user to play with revision
numbers.
Instead, what makes sense is to provide the ability to point at some
time X and say, let's call this landmark by the symbolic label L1, and
point at some time Y and say, let's call this landmark L2. Then when
the user wishes to refer to this landmark, for whatever reason, she
can just say "what was this file like at landmark L1?" or "what is the
changelog for this directory at landmark L2?" - instead of needing to
comb through the entire history of the file/directory to locate the
revision of interest.
The landmarks help the user navigate through what may be a very
elaborate history of the filesystem, by identifying key points of
interest (important revision numbers) with meaningful names that
immediately communicate to the user what they refer to. A name like
"3.0-beta" is much more meaningful than "revision 7391".
Of course, we can just copy the files to /tags/3.0-beta and then refer
to that instead, but IMHO this defeats the whole purpose of having a
filesystem history. The directory /tags/3.0-beta is a particular part
of the filesystem *at the present time*, whereas what I want is "what
does the filesystem look like at the time of revision 7391"? - i.e. I
want to access the *history* of the filesystem at some particular
landmark; I don't care about what it looks like *now*.
And what if I want to label the state of the *entire* filesystem at
time X? Sure I could copy the entire filesystem to a subdirectory, say
/tags/timeX. But that to me has defeated the purpose of having
filesystem history in the first place. I can easily do exactly the
same thing on a non-history-tracked filesystem (i.e., without using
subversion) and achieve the same effect. The directory /tags/timeX
exists in the *current time*, but all I needed was for some generic
label "timeX" to refer to that particular point in the filesystem's
history, *in the past*.
It seems rather unfortunate to me that while I can do precisely this
(accessing a specific point in the filesystem's history) if I use raw
revision numbers, yet I can't give names to these numbers. The
capability is already there; it just needs better usability. IMHO, we
should move away from using revision numbers---let the machine take
care of that; human beings handle names better than numbers.
This seems something so easy to implement (unless I missed something
obvious), and so obviously beneficial. So why is it a "bad thing"?
T
--
I think Debian's doing something wrong, `apt-get install pesticide', doesn't
seem to remove the bugs on my system! -- Mike Dresser
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 4 02:01:32 2005