Robert Dailey wrote:
> On Fri, Jul 3, 2009 at 4:14 AM, Bolstridge, Andrew
> <andy.bolstridge_at_intergraph.com <mailto:andy.bolstridge_at_intergraph.com>>
> 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).
I haven't tried, but don't you get this if you copy a workspace built that way
to a tag (with all the downsides of doing that, like not necessarily having any
other history of files there)?
> Secondly, tag operations should allow a user to select multiple
> branches. A tag would then contain multiple, distant branches this way.
Why? Externals are a better way to get sub-components, but they should point to
> Given the implementation of Subversion, I'm not sure if this is
> possible, but it would be a great thing to have.
The problem here is not so much not being able to create the tags you want but
the time that you let the libraries (externals) float pointing at their HEAD
revisions. A cleaner approach is to tag the sub-components at 'release-tested'
points, make a release branch of the main code where you peg the externals to
the appropriate tags, then create QA and release tags from the branch. This way
additional changes can be made anywhere in the project or library trunks without
affecting your current builds and release and the final tags are created atomically.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-03 15:39:18 CEST