"Ryan Schmidt" <subversion-2007a@ryandesign.com> wrote in message
news:CA04F900-24D6-44CD-BF6A-8F8024DF0F5D@ryandesign.com...
> On Mar 20, 2007, at 11:06, Mark Clements wrote:
>
[SNIP]
> > 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.
> >
[SNIP]
> > 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