Greetings, Brian H. Toby!
> I am trying to get beyond my rather simple use of svn and would like
> some advice. My goal is to have two releases of a package available,
> one bleeding edge and the other stable. I want to keep the URLs to
> both releases stable. This seems like a reasonably common thing that
> one would want, but google has failed to find this discussed (probably
> because I am using the wrong lingo to describe what I want.) Anyway, I
> can see two ways to implement this:
> 1) Keep the bleeding-edge release in the trunk and use a tagged
> version for the stable release. When I am ready to make a new stable
> release, I delete the stable tagged release from the repository and
> then copy the trunk reusing the same tag name.
> 2) keep the stable release as the trunk and work on the bleeding-edge
> release as a branch. When I am ready to make a new stable release, I
> use merge --reintegrate and commit to update the stable release and
> then delete and recreate the bleeding-edge branch.
> Option 2 seems to be the way that svn is designed to be used, but is
> more complex. I guess it is more robust, if someone commits a change
> to the stable. Are there any other reasons to go that route? Is there
> an even better choice?
Nope. It's the case 1. You branching stable version to tags, leaving /trunk as
your workplace.
Could as well copy to branches:
copy /trunk to /tag/<version>
delete /branch/stable
copy /tags/<version> to /branch/stable
/trunk is your mainstream, especially if you're working mainly alone on the
project.
If you need space for experimenting, or if you need to backport some changes
from trunk to stable, you create a new branch from stable branch, port
whatever you want to it, then merge it back to stable and delete the one you
used to backport.
--
WBR,
Andrey Repin (anrdaemon_at_freemail.ru) 12.01.2010, <14:00>
Sorry for my terrible english...
Received on 2010-01-12 12:10:40 CET