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
Received on Tue Mar 20 21:13:43 2007