> -----Original Message-----
> From: OS [mailto:os_at_portfoolio.com]
> Sent: Monday, February 18, 2008 12:19 AM
> To: users_at_subversion.tigris.org
> Subject: feature request: svn revision alias
>
> And that made me think whether it would be difficult to implement that
> in svn natively.
>
> The svn revision is pretty much equivalent to what a tag is in other
> systems.
> But it's a numeric value, hard to remember, etc -- and people wish to
> give tags descriptive names.
>
> Wouldn't this be useful:
> svn alias <rev> <name> (or svn revalias <rev> <name>)
>
> Then one would be able to use <rev> and <name> interchangeably in
other
> svn operations.
> Call it the poor man's svn tag! :)
That's about as useful as putting license plates on the rear bumpers of
airplanes. =)
In SVN, an alias or revision number by itself is useless. You need a
dir to go along with the revision/alias to be accurate. Aliasing 'FOO'
to a revision in a repository doesn't tell me a damn thing. What code
does FOO (or revision 1234) apply to? A revision can have check-ins
from multiple directories _across_ multiple baselines. Even if FOO is
from a check-in under one tree, does FOO apply to the root of the tree,
or just for a subproject?
Ex:
I check-in /branches/rel.1.0/big_project/logging/log.java as
revision 1234. I alias 1234 as FOO. Does FOO apply to 'rel1.0',
'big_project', or just the 'logging' component?
Ex #2:
I fix a logging bug and merged the code fix across three
branches as revision 1234:
/branches/prod.1.0.1/logging/log.java
/branches/rel.1.1.0/logging/log.java
/branches/rel.2.0/logging/log.java
What does revision 1234 or FOO actually represent?
../tags/some_dir clearly establishes a baseline. The tags/some_dir
eliminates the need to remember a random revision number, which is what
you're asking for.
Ex:
svn copy /branches/rel.1.0/big_project/logging /tags/logging.1.1
SVN already does what your users want to do.
I went from seven years of ClearCase before using SVN. Initially, I had
a bear of time with the idea of one and only one revision number, no
traditional revision tree, and the lack of traditional labels/tags.
Nowadays, I don't miss any of those things. And more importantly, I can
see how the old RCS paradigm has really limited systems like ClearCase,
Dimensions, CVS, etc., which do implement "traditional" tags/labels.
Your users need to get used to the (large) paradigm shifts in SVN.
(Except for the (criminal) lack of merge tracking and merge bugs,) I've
found that SVN is a great system based on solid paradigms. SVN works,
but SVN will not work if you try to force it to do things the way you
did in the old country. Which is why you put tail numbers and
transponders on airplanes instead of license plates mounted on rear
bumpers.
Lecturing aside, the purpose of a tag is to create a baseline. 'svn
copy' is how you create a tag/baseline in SVN. Instead of placing tags
or labels on files, you simply create a directory (normally under
.../tags) of the versions you want, and that directory becomes a
tag/baseline. It's a simple concept, but for some reason, people are so
used to the paradigm of applying tags "in-place" to existing files that
creating a tag directory is somehow "complicated."
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-19 16:31:32 CET