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

Re: Philosophical question: Tagging & Structure

From: Robert Dailey <rcdailey_at_gmail.com>
Date: Fri, 3 Jul 2009 08:07:45 -0500

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.

Tags in Subversion, from my investigation need 2 major improvements. Tags in
Subversion shouldn't be simple "copies". I should be able to only tag a
specific part of a hierarchy in the repository, much like you would use
sparse checkouts. For example, in the root of the repository you may have 5
directories: Project1, Project2, Project3, Library1, Library2. I should be
able to only tag Project1, Library1, and Library2. Project2 and 3 would not
be in the tag (This would be a sparse tag).

Secondly, tag operations should allow a user to select multiple branches. A
tag would then contain multiple, distant branches this way.

Given the implementation of Subversion, I'm not sure if this is possible,
but it would be a great thing to have.

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-03 15:08:35 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.