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

RE: trunk naming best practice question

From: Bob Archer <Bob.Archer_at_amsi.com>
Date: Tue, 7 May 2013 14:20:38 +0000

> For the trunk, what's the common practice to name a version of the trunk?
> We have a trunk and it's not ready for branching.
> We also feel that we need a more specific name for the trunk than what we
> have now called version=trunk.
> However, we can't be specific since we don't know what the branch name
> would be while at the same time, we need to perform daily builds for QA
> testing.
> What's the best practice in use with SVN ?

Really, it's about whatever works best for you. We no longer use the name "trunk" on our projects. I guess it works ok if you branch for release... but that wasn't working for us. So, instead of using "trunk" we use the version number... so in our project you would see...


Our procedure is to only merge up versions. We build and release from out version path [branch]. Feature branches are created for items that will take more than a day or more than one person is working on it. We fix bugs in the lowest version number that we are still supporting and merge that fix up all the way through our non-released dev version.

This also helps us a lot with our build server, because we had to constantly redefine what was in the "trunk" working copy. This way creating a build project for a new release is much easier... we svn copy the version to the new release version, update the cruise control.net config file that is in the project folder with the new version number, checkout the new version path to the build server, update the ccnet.config root config to point to the new version.

We also generally don't build from feature branches, but we could if we wanted to. However, the build scripts would have to be changed a bit since artifacts are copied to a folder based on version number atm.

Once again, whatever works best for you. Using a trunk that was never the same version from week to week didn't work for us. We also were doing a lot of cyclic merges and needed a better way.

Received on 2013-05-07 16:24:22 CEST

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.