Jim Blandy wrote:
>Nobody disagrees that symbolic revision names would be easy to
>implement. That's not why we avoided them. We avoided them because
>we thought we had a simpler way to do a better job.
>
>What are you trying to do with Subversion at the moment that
>Subversion's tags handle poorly, but that symbolic names for revisions
>would do well?
>
>
The only example I've heard is that of "I want to move a couple of files
back to the state of the tag"
Currently this is done with:
svn merge -rBASE /path/to/origin/of/wc /path/to/tag/desired ./filename
This has the downsides of:
- tending to be a lot to type
- unlike an update, you are not given an error when you try to commit
without "un-merging"
- there is no "memory" of the merge so that it can be un-done easily
(an update would let you just say "update" with no
revision specified to get back the latest- though the latest still
probably isnt what is wanted, what you really want is what
-rBASE was before the last update- an alias which does not currently
exist.. so either way would probably have a problem.
With the current implementation, you need to manually reverse the merge)
Of course, the other example of "I want to examine a tag, but don't want
to accidentally commit to it" can be easily fixed with hook scripts.
As an aside, I use tags primarily for auditing, and do most backtracking
through log-mining and svn blame, so I am _not_ the best-versed in this
use case.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 20 17:56:23 2006