Brad Appleton wrote:
> Okay. So it sounds like the request sint so much concerned about
> tagging as it is about having the ability to associate the
> revision number with a more mnemonic alphanumeric identifier
> (but nonetheless unique), and to be able to use either the
> global revNUM or the global revNAME almost interchangeably in SVN.
Yeah, it's not entirely an uncommon request.
> What are some of the different ways I can do this in SVN, and how
> practical is each and how feasible is it to automate?
Let's see.
> - one approach "psychotic tagging", is apparently not recommended :-)
Well, not entirely unrecommended either. If you want it, you can have
it. For example, making a toplevel directory "revnames" and copying
each commit there under a descriptive name is a definite
possibility. Obviously no-one would wish to check out that directory,
but no-one should have a need to, either.
> - what if I associate the identifier in the log?
Possible, and requires nothing new from Subversion.
> - can I create a NAME property for a global revision number?
Also possible. Revisions have normally three properties: author, date
and log message. You can add more if you want. The only catch here is
that I don't think it is possible to add a revision property that
appears at commit time (with the subversion client), but you can add
it after the commit.
> - does it make practical sense to implement a mechanism inside or
> outside of SVN that simply maps revnames to revnums and vis-a-vis?
> [ e.g., $(revname $(revnum $REVNAME)) eq $REVNAME ]
>
> $ svn commit --message "Corrected # of cheese slices."
> Sending sandwich.txt
> Transmitting file data .
> Committed revision 3
> $ myrevmap -revnum 3 -revname MyRevName
> Associated revision 3 of <??> with 'MyRevName'
> $ svn log --revision `myrevnum MyRevName`
Works splendidly - if it would be practical in use, I couldn't say.
> or use a NAME= keyword for the --revision option and commit command,
> as in:
>
> ## NOTE: sample possible syntax - NOT an actual working example!!
> $ svn commit --name MyRevName --message "Corrected # of cheese slices."
> Sending sandwich.txt
> Transmitting file data .
> Committed revision 3 (NAME=MyRevName)
> $ svn log --revision NAME=MyRevName
This obviously would require changes to the Subversion client - but it
is by no means a big change. "--name" could be just another revision
property.
> If something like that was worthwhile, then one could perhaps
> implement a pre-commit trigger (or some other mechanism)
> to somehow force a name to entered (or deduced).
Pre-commit-hooks can inspect a commit that is about to happen, and
reject it based on the contents or the log message or whatever. It
could certainly enforce naming revisions.
***
We can even for a moment discuss the actual features of such a thing
being added to Subversion.
First of all, since what we want is being able to map revision names
to revision numbers, we would most definitely need a new table in the
subversion database for this. This can be done without breaking our
version compatibility guarantees at 1.1 if wished.
Like you suggest, "svn commit" could take a "--name something" as a
parameter naming the revision being committed. The name could be a
revision property on the commit, and it could be afterwards modified
with the normal revision property modification methods. The only
special thing about it would be that it automatically updates the
revision name table as well, and enforces uniqueness.
All the Subversion commands taking revision arguments could take in
the new revision names directly. Right now, we accept HEAD, BASE,
COMMITTED and PREV as special (and {DATE}), so we could just rule
those as special (or rule all-caps names special) and just restrict
problematic characters in the revision names. Then a simple usage of
"svn log -r foo:bar" could use the revision names.
So, what could be done with these? Well, for example per project
revisions. Instead of having a global revision of "15242" for a
commit, you could add "project-242" as a revision name. I'm sure
everybody can come up with plenty of uses.
The problem with these would be that they would be indeed global. You
can't tag a copy of a directory with "last-merge" without problems,
instead you'd have to have something like "proj-a-dir-xyz-last-merge".
There would be some churn in the server side for implementation of
this, and possibly in the protocols and interfaces - but it would not
be a huge change to make, and it could be made for 1.1 by the
compatibility guidelines.
***
But, is it worthwhile to make this change? Everybody has their own
opinion ofcourse, but right now I don't think so. Tagging covers
already 95% of the use cases and a lot of the rest can be handled
outside Subversion. Creating a new method for doing mostly the same
thing will add confusion, and make people tag less - which makes them
stick to the old CVS-style habits even where proper tagging would be
the better choice. But, it can be argued both ways - and the
suggestion probably has still a lot to improve on to be even more
useful and worthwhile again.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 29 12:26:26 2004