On Fri, Jul 3, 2009 at 11:37 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> 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>>
> > 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).
>
> 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
> tagged copies.
>
> > 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.
>
>
I believe there is a python or perl script available (
http://subversion.tigris.org/tools_contrib.html#svncopy_pl) that can be used
to 'fix' the revision numbers when the tag is created. I've never used it
personally, but I believe that this very situation is the reason behind its
existence.
From the readme:
svncopy --pin-externals (or svncopy --tag) will update any unversioned
> svn:externals in the destination tree to contain the current version of the
> directory listed in the svn:externals definition. This effectively pins the
> reference to the current version, and is the behaviour you want for tagging.
We currently have a similar situation in our repository, and we will be
moving to this solution in the future.
Cheers,
Daniel B.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2368986
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-08 00:36:27 CEST