Re: I, too, miss tags.

On Sunday 26 February 2006 20:15, Rob van Oostrum wrote:

> Here's my thinking on this discussion:
>
> - Unless you have a trunkless/branchless repository,

I would say "tag/-less" repository. Branches are fine.

> simply creating a textual alias for a revision number is useless

I strongly disagree.

> in terms of using it as a
> tag to refer to a specific version of your application.

For *my* application, if you mean that, it would be very useful :).

> - 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,

Eppss... what large file? A list of 1000+ labels you call large? Come on, perl
parses it in milliseconds, even on today's slowest machines.

> and you'd then have to write more wrapper functionality to let
> you act on the information.

I tend more and more to think that a wrapper will be trivial, something like:

REV=$(svn pl -v | grep ${TAG_LABEL} | awk '{print $1}')
svn ${command} -r $REV ${1+"$@"}

> 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.

I find 'svn log -v --stop-on-copy' to be a very obscure, ad-hoc feature that
is only needed to remedy the missing label functionality. Implementing true,
labels, IMHO, would be simplier and clearer.

> 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
> ;-)

Yes, your guess is right, that is upsetting for me ;) -- just a little bit ;)

> - 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.

Oh dear, why so complicated?!

What I need is a simple list of correspondence "<revision
number>:<tag-label>". Thats it. It can be kept anywhere -- in a file, in a
property, in a paper notebook ;). I tend to think now that simply using a
versioned property at repo root will do the job.

> 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.

No no no, no need to change SVN API, at this point! ;)

Maybe this overcomplicated view of labels is what keeps you arguing against
them? If so, I do agree. Such complicated design is an overkill, and would be
a "feature creep". But it can be done in a very simple way, IMHO.

> My advice to you would be to find ways to get what you want using what's
> already there.

To some extent, it is what I am going to do. I will use properties to store a
list of labels. I will use a wrapper around a regular 'svn' client.

This has drawbacks, but as a proof of concept and a prototipe will be just
fine.

> What you and others are asking/looking for is too far
> removed from how SVN was designed to work.

I don't think it is. SVN is intended (at least it is declared so) to version
filesystem trees. If so, it should do this faithfully, without requiring to
add any special directories.

Like it adds al kinds of convenience features like logging, merging, etc., it
could add a labling as well. Why not?

BTW, maybe this functionality could be handled as a client-side plugin? Then
both you and me could be satisfied (you would not have those superfluous
labels in SVN code, I would not need to use those superfluous tag/ dirs ;)

> You've been pointed in
> feasible directions many times on this thread yet you seem stuck on
> wanting things a rather particular way.

I have many times pointed out that I do not find the solution good, or even
acceptable in the face of easy possibility to get true tags-as-labels.

> 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.

No, I do not overlook it. I just don't agree to be forced to use a specific
method by a tool that could easily support my way.

Programs are designed for people, not people for programs, aren't they?

> Path of least resistance my friend.

So is mine. Strangely, it takes us to the different locations...

Regards,
Saulius

-- 
Dr. Saulius Gražulis
Institute of Biotechnology
Graiciuno 8
LT-02241 Vilnius
Lietuva (Lithuania)
fax:          (+370-5)-2602116
tel.: office: (+370-5)-2602556
      mobile: (+370-684)-49802, (+370-614)-36366
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org