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

Best practice: "Current Version" tag

From: Mark Clements <gmane_at_kennel17.co.uk>
Date: 2007-03-20 17:06:19 CET

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
Received on Tue Mar 20 17:07: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.