> -----Original Message-----
> From: Scott Palmer [mailto:scott.palmer@2connected.org]
> Sent: Sunday, February 26, 2006 1:42 PM
> To: users@subversion subversion
> Subject: Re: I, too, miss tags.
>
>
> 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?
Because adding a "version_1_0" label for revision X to the root of a
repository that contains many branches will not tell you anything. What
branch in that revision actually contains version_1_0 of your
application? What if your repository contains multiple modules, each
potentially containing many branches?
>
> > - 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...
Actually, it only creates a pointer to where you copied from. I don't
understand what the inconvenience is in also having on-the-spot access
to a full copy of the tag. Furthermore, svn log -v --stop-on-copy [tag]
should only ever return one revision, which will also give you the
commit message telling you why, when and by whom the tag was created. If
a tag was created off another tag, it will also let you dig further
down. All things you wouldn't have with flat labels.
>
> > 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.
Clear & awkward to you perhaps. For the past 2 years, I've managed SVN
repositories for a couple dozen large multinational accounts, quite a
few of which are many Gigabytes large and contain in excess of 40k
revisions each. We initially migrated from CVS to SVN *specifically*
because one large client ran into a scalability issue directly related
to CVS' implementation of tags. Ironic?
> > 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.
Dir A ---> tag X (added in r200, removed in r210, re-added in r250,
removed and re-added in r301 and r302)
Dir B
Dir C
- foo (added in r100, removed in r201 and re-added in
r300)
How would your simple wrapper implement these scenarios:
1) r200 of tag X: should contain r100 of foo
2) r250 of tag X: should not contain foo
3) HEAD of tag X: should contain r300 of foo
It's easy enough if you always grab from Dir A (that is only even
possible if you always know where each tag happens to have been stored).
But what if I say: give me the revision of foo corresponding to tag X at
revision 250? Assuming foo even still exists on HEAD, your wrapper would
have to go up from foo one directory level at a time and recursively (or
should that say reverse-recursively ;) check each parent at EACH
qualifying revision for the presence of tag X.
The cumbersome svn copy trunk tag approach already gives you all of this
without an ounce of the trouble.
>
> > 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.
Of course SVN is incomplete. So is every other application ever written.
You don't need hook scripts to get any of the functionality suggested.
They would merely help you enforce restrictions on the use of the
repository.
>
> 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.
It doesn't appear to be the same thing because it isn't the same thing.
Why would you want to label a revision? Unless your repository has no
branches/tags and only consists of one codeline, the revision is going
to refer to any number of copies of your codebase. What would the point
in that be?
> 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.
Huh? You must be doing something completely wrong. I only say this
because I depend on tags for the exact same things (i.e. reconstructing
version of a codebase, determining the from/to of merges, etc) many,
many times a day. There is nothing it will not let me do. Could it be
more straight-forward? Sure. Do I need it to be? Not really. The cost is
far outweighed by the benefits. But that's just my own perspective
having migrated all the repositories I work with from VSS and CVS.
> 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.
But it can't, which is why you want to change something by prototyping a
wrapper script to help convince SVN developers that what you're
suggesting is not only possible but also valuable enough to invest time
in.
>
> > 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" ?
While my opinion in this matter should be obvious by now, let me suggest
that you try and step back for a different perspective:
The SVN developers have been working on this for quite a few years now.
They are some of the smartest people in SCM development you'll find
anywhere. When met with such broad disagreement, try not to assume that
everyone else is wrong or not "getting it". Try and think about why so
many people that are bound to be smarter than both you and I are saying
that you're wrong.
You might actually learn something ;-)
If you don't need overly flexible cheap copies, you could always go back
to CVS/VSS and get exactly what you want. Of course, that would mean
missing out on all the things you *do* like about SVN. In the end, every
piece of software is bound to have its pros and cons. Right or wrong,
and I really don't think it's either, SVN went the direction it did. I
would seriously urge you to look closer and get beyond the semantics of
"it's not a tag, it's a copy!" because I think you're missing out.
Cheers
Rov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 26 20:56:11 2006