On May 2, 2006, at 12:43 PM, Dan Weeks wrote:
On 2006-05-02 12:40:29 -0400, Eric Coleman wrote:
Thanks for the information.... The reason is that:
This is a commercial product. We need to maintain the current release while we finish work up on the next version. The next one is the biggest update we've done since launch, and well, just don't want to get caught with our pants down.
Isn't that what tags are for? you then work on a tag and merge any changes you need upstream to the trunk.
That's what branches are for. A typical workflow for creating a major new version of a product might be:
1. tag the the last stable shipped sources from the trunk (svn cp $repo/trunk/ $repo/tags/1.0.1) 2. work on the unstable/development version commences on the trunk 3. maintenance work on the stable version can proceed on a branch from the old trunk snapshot (e.g. if you need to do bug fixes on stable version, create a branch: svn cp $repo/tags/1.0.1 $repo/ branches/1.0.x)
A variation on this is to perform the new development on a branch, and keep the trunk for maintenance on the stable version.
The question is how comprehensive the changes are; if there's really _no_ sharing and no history between the two versions, Eric probably wants to do what Sune said if he wants the new code to be the trunk:
But really, why not do this:
- Delete trunk.
- Move in new files.
- Commit.
It's the simplest option for the scenario where literally _everything_ is different, from the ground up. But it's not usually what you want to do, because it doesn't preserve the history of the files.
Chris