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

Re: FW: Philosophical question: Tagging & Structure

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Fri, 03 Jul 2009 10:15:17 -0500

Bolstridge, Andrew wrote:

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

A large number of tags and branches is not a problem for subversion. Why is it
a problem for you? Note that the directory structure is arbitrary, so you could
make a tags/QA/ and tags/release/ structure if you don't want it to look
cluttered when you browse the releases. And while tags are the same as branches
to subversion, they should not be the same to you. By convention (sometimes
enforced by hooks), you never modify a tag after it is created so you can
reference it by name later instead of needing to track revision numbers to get a
known version.

And if you tag your components separately and point the externals to the tag you
want, your other problem goes away too.

-- 
   Les Mikesell
    lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2367825
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-03 17:17:08 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.