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

Re: Best practice: "Current Version" tag

From: Mark Clements <gmane_at_kennel17.co.uk>
Date: 2007-03-21 16:10:28 CET

"Ryan Schmidt" <subversion-2007a@ryandesign.com> wrote in message
> On Mar 20, 2007, at 11:06, Mark Clements wrote:
> > Here is how I envision the process using a new tag to hold the current
> > version:
> >
> > Development work takes place in trunk.
> > When it is time to update the client's server with the latest version:
> > * Delete the current 'live_version' tag.
> > * Copy trunk to '/tags/live_version' tag.
> > * Update a local working-copy that points to '/tags/
> > live_version' (or create if necessary).
> > * Export the local working copy.
> >
> > Is this a sensible approach, and a good method of handling the
> > situation, or do you have any better suggestions?
> Sounds like a reasonable approach.
> The only potential problem I see would be that since the tag is
> deleted and then recreated, the working copy may not see the old and
> new tags as the same object, so it's possible an svn update would
> fail. If so, you may have to use svn switch instead.

I've done a test, and it seems to handle 'svn up' without any problem, i.e.
it recognises them as the same object. Interestingly (and I was surprised at
this) it also recognises the physical files as the same. I created the tag,
changed a single file in trunk, deleted the tag and recreated it from trunk.
When I did 'svn up' on the tag it detected the modified file as 'modified'
and everything else was untouched. What I would have expected was that
there was a 'delete' operation on all the files, followed by an 'add'
operation. Note that the history looks as I would expect (i.e. details
about the original copy operation are not present).

Anyway, the technique seems to do what I want even if SVN seems to be a bit
cleverer than I expected :-). Unless I hear of any better alternatives in
the next day or two, then this is what I'll go with.

Thanks for your help.

- Mark Clements

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 21 16:30:35 2007

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.