> 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...
/ProjectName
/v1.0.0
/v1.1.0
/branches
/feature1
/feature2
/tags
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.
BOb
