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

FW: Philosophical question: Tagging & Structure

From: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
Date: Fri, 3 Jul 2009 15:26:27 +0100

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Friday, July 03, 2009 2:28 PM
> To: Robert Dailey
> Cc: Bolstridge, Andrew; users_at_subversion.tigris.org
> Subject: Re: Philosophical question: Tagging & Structure
>
> On Fri, Jul 03, 2009 at 08:07:45AM -0500, Robert Dailey wrote:
> > On Fri, Jul 3, 2009 at 4:14 AM, Bolstridge, Andrew <
> > andy.bolstridge_at_intergraph.com> wrote:
> >
> > > I’d do the tagging the way it “should” be – take the current revision
> > > number, and remember it.
> > >
> > > If you ever want to get the current state of your release, do a checkout
> > > using that revnum. Really simple.
> > >
> >
> > But that's what tags do. They give a name to that revision number. It's a
> > lot better than writing it down on paper somewhere. This still doesn't
> > address the issue of tagging multiple branches. If dependencies are in
> > different branches, those branches must be tagged at the same time the
> > project is. You can't do this with one tag operation.

No they aren't. Tags in svn are branches, pure and simple. Which works fine in large part except for the case you've seen where you want to tag disparate sections of the repository; and for the case where you don't want a lot of tags to be created. If we used it, we'd have a hundred tag branches for some of our products by now!

> >
> > Given the implementation of Subversion, I'm not sure if this is possible,
> > but it would be a great thing to have.
>
> You could be creative and put your own tagging meta data into
> a versioned property at the repository root:
>
> $ svn propget rcdelay:tags ^/
> foo:/branches/devel_at_42;/branches/experimental-stuff_at_23
> bar:/branches/bugfix-branch_at_32
> 1.0:/trunk_at_20
>
> And then have some script that uses this to run 'svn export'
> appropriately (you don't need working copies of tags, right?).
>
> That's what properties have been made for -- arbitrary meta data you'd
> like to attach to your versioned tree, and use with add-on tools which
> provide functionality Subversion does not provide.
>
> Of course, something like this could be made part of Subversion, too,
> as, say, svn:tags. But that's a long process. Patches welcome, but I
> guess getting everyone in the community to agree that a scheme like
> this is good and useful to have in Subversion's core would be the hard
> part :)
>
> Stefan

Someone once did this, they stored the tag info in revprop 0.

http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=756563

sometimes I feel there is a little too much religion and not enough practicality. One of the reasons for not accepting that patch was that the problems attempting to be solved were "The things you do not like are essential parts of the Subversion design."

I like that branches design, it's great. Unfortunately, I think someone figured that tags could be implemented using this great branch feature.. and from then on, any alternative method was considered a lesser one. I think this is a classic programmer mistake - I've done it myself, implemented a cool feature I loved, showed it to the customer who promptly says "no, we wanted something much simpler", and I have to eat my beloved code and put the basic feature in for them. OSS devs on the other hand, gets to choose for themselves what gets in or not, and so the fancy feature gets it every time, even in cases like this, where the simple solution is actually the better one.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367816

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-03 16:27:28 CEST

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.