[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: I, too, miss tags.

From: Rob van Oostrum <rob.vanoostrum_at_blastradius.com>
Date: 2006-02-26 19:15:44 CET

Here's my thinking on this discussion:

- Unless you have a trunkless/branchless repository, simply creating a
textual alias for a revision number is useless in terms of using it as a
tag to refer to a specific version of your application.
- Mapping a URL+revision pair to a label in a versioned property does
exactly the same thing as 'svn copy trunk tag' would. You'd still have
to go in and parse a potentially very large file to find the information
you want, and you'd then have to write more wrapper functionality to let
you act on the information. Writing a wrapper around 'svn log -v
--stop-on-copy tag-url' (where tag-url is dynamically constructed by the
wrapper to stick the base tags url in front of the label name) would do
the same thing as what has been suggested several times over in this
discussion. Same thing for creating the tag (or branch for that matter):
write a wrapper that prepends the base tag URL to the tagname. I don't
see the inherent benefit of one over the other, except of course for the
fact that the 'my way' is already covered for in SVN, and 'yours' is not
- For any property approach to be feasible/accurate, you'd have to find
a way to distill *versioned* URL information from an individual file so
that you can establish whether a file inherits a tag from one of its
parent directories *within the context of the revision you're looking
at*. I'm pretty sure there is no way to implement this accurately
without touching the SVN (client) API and quite probably its internal
implementation. At the very least you wouldn't be getting by with just
writing a wrapper around the svn client, but rather writing your own
additional client functionality against the SVN API, possibly coupling
the svn and your client behind a wrapper interface.

My advice to you would be to find ways to get what you want using what's
already there. What you and others are asking/looking for is too far
removed from how SVN was designed to work. You've been pointed in
feasible directions many times on this thread yet you seem stuck on
wanting things a rather particular way. It's not that SVN can't do what
you need it to do, it's that it can't do what you want it to do, the way
you want it to do it. There is a big difference between the two that you
seem to be overlooking.

Path of least resistance my friend.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 26 19:13:48 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.