Rainer Deyke wrote:
> To cut this ongoing discussion short: Is there anything that revision
> aliases would allow you to to that the current tagging mechanism does
> not allow you to do?
> Note: You can currently tag the whole repository, for every definition
> of "whole repository" that matters, by setting up your repository
> like this:
> Note: You can (and should, in the absence of built-in merge tracking)
> keep track of merge points using the current tagging mechanism.
Or in the absence of a good way to record the last merged revision,
which revision aliases would give.
> If there is anything that revision aliases allow you to do that cheap
> copies don't allow, I would love to hear it. If there is nothing,
> then the only benefit of revision aliases is syntax sugar. In that
> case, the problem can be solved quite elegantly by writing a
> tag-aware subversion client, without changing anything on the server
Well, I've suggested merge-tracking (I think tagging each merge, as you
suggested above, is a remarkable kludge around the lack of a way to
track revision numbers) and a way to link in to the issue tracker
(ISSUE_1423_FIX, for instance). Both of these are currently possible,
but with extra tools and/or digging (merge tracking generally requires
an extra script, or digging through log files; issue tracking normally
works one way only--notes in the issue tracker saying "this was resolved
in revision 42"). There are a bunch of creative people using
Subversion; I wouldn't be surprised if they came up with their own uses
for revision aliases. Basically, think of what causes you to have to
say '-r 1234' or '-r <date>' (I can never remember the syntax for that
one), and consider whether or not it might be convenient to have an
easy-to-remember mnemonic for that revision number.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Feb 28 14:46:01 2006