On 26-Feb-06, at 1:15 PM, Rob van Oostrum wrote:
> 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.
Why?
> - Mapping a URL+revision pair to a label in a versioned property does
> exactly the same thing as 'svn copy trunk tag' would.
No. It wouldn't label the trunk, it would make a new copy of it.
Forcing the use of --stop-on-copy which leads to...
> 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.
But it would be much slower and more awkward to deal with...
REQUIRING a bunch of added scripting (a major pain on Windows) to
deal with it in a even remotely reasonable way. The idea of making a
script to do what we are after in my view is more of a proof of
concept. Once its usefulness is proven, the labeling functionality
should be added to subversion so that awkward scripting isn't needed.
It's pretty clear from this discussion that tags are an awkward hack
to get at the functionality that people asking for "labels" really want.
> 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.
I don't follow what you are getting at.
> My advice to you would be to find ways to get what you want using
> what's
> already there.
Which we have done, with the proposal to use a property on the
directory to be labeled and a fancy script to deal with the work.
> 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 like what is being requested is unreasonable. Consider that
other version control systems have exactly the feature that is being
asked for. I don't see how it is in any way "far removed" from the
way Subversion was designed to work. As it is, I have NEVER made a
'tag' with subversion. Instead I am maintaining files with the
revision number that certain builds were made from. I find it much
more natural to work that way rather than hacking the functionality
on to cheap copies.. which requires all sorts of mucking about with
hook scripts to get working properly. Hook scripts on windows are
painful, and the very idea that they are REQUIRED to get basic
functionality out of Subversion is telling. It means that subversion
doesn't have support for the feature built-in, requiring every
installer of subversion to hack on the functionality themselves. End-
users of subversion should not be required to program common features
themselves.. it means subversion, as it ships, is incomplete.
Now, I realize that making a file of revision numbers is not ideal.
As I understand it, theoretically the revision numbers could change
if someone decided to dump/load with a filter. 'Tags' would survive,
but the revision number labels, as we have suggested they be hacked
on with properties, would be garbled. But tags don't do what we
want. They don't label a revision, they make a copy of it. It
doesn't appear to be the same thing and it is awkward to use it in
that way. Tags are TOO flexible, there is nothing enforcing that
they make sense. I can copy the trunk of ProjectA into the tags
directory or ProjectB and then when I try to use the tag as a basis
for merging or rebuilding an old release on ProjectB everything will
be hosed. The solution is more complex scripting with hooks...
requiring the user to basically be a subversion developer to add the
missing constraints that come built-in to other version control systems.
> 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.
But it can... which is why properties and wrapper scripts have been
discussed that will prototype what we want to do.
> There is a big difference between the two that you
> seem to be overlooking.
>
> Path of least resistance my friend.
It's not our fault that the subversion developers offer up so much
resistance to a much request feature :). It's not our fault that
they appear so much in love with cheap copies that they think it is
the solution to every problem.
Who's *really* not "getting it"? Those requesting the feature, or
those that are saying "that's not the subversion way" ?
Scott
---------------------------------------------------------------------
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:44:05 2006