Best practice: "Current Version" tag

[Mark Clements <gm...@kennel17.co.uk>]

We have an application written for a specific client that we manage using
subversion.  All development takes place in the trunk, and when changes have
been made and tested and are ready to be installed on the client's server we
export the trunk and upload the result.

I would like to have a 'live_version' tag that holds the currently installed
version, so that any of our developers can access the latest version without
needing to connect to the client's server.  It also gives us a safe backup
if anything happens to the live server.

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.

The reason that this isn't handled as a branch with merging, is that we want
it to behave as a tag - i.e. once created it should never be changed.

In theory this is no different from creating v1.0, v1.1 tags, and so on,
except:
* We don't care about any old versions
* We want the tag name to stay the same so that it easy to keep a local
working copy that points to it, without needing to switch.

Is this a sensible approach, and a good method of handling the situation, or
do you have any better suggestions?

- Mark Clements



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Best practice: "Current Version" tag

[Mark Clements <gm...@kennel17.co.uk>]

"Ryan Schmidt" <su...@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

Re: Best practice: "Current Version" tag

[Ryan Schmidt <su...@ryandesign.com>]

On Mar 20, 2007, at 11:06, Mark Clements wrote:

> We have an application written for a specific client that we manage  
> using
> subversion.  All development takes place in the trunk, and when  
> changes have
> been made and tested and are ready to be installed on the client's  
> server we
> export the trunk and upload the result.
>
> I would like to have a 'live_version' tag that holds the currently  
> installed
> version, so that any of our developers can access the latest  
> version without
> needing to connect to the client's server.  It also gives us a safe  
> backup
> if anything happens to the live server.
>
> 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.
>
> The reason that this isn't handled as a branch with merging, is  
> that we want
> it to behave as a tag - i.e. once created it should never be changed.
>
> In theory this is no different from creating v1.0, v1.1 tags, and  
> so on,
> except:
> * We don't care about any old versions
> * We want the tag name to stay the same so that it easy to keep a  
> local
> working copy that points to it, without needing to switch.
>
> 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.


-- 

To reply to the mailing list, please use your mailer's Reply To All  
function


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org