SVN layout -- best practice

Question

In CVS we have on project with multiple directories in there. There is a nightly build that has to pull in stuff from different directory in the same CVS project in order to build the nightly build. So I should have that in mind and I have to modify the build script to check things out from different repositories if we move to SVN.

I read the related SVN QA, but I have my own question that I need the answer for.
I can do:

/trunk
/tags
/branches
/3rdparty

Where everything we develop comes out of the /trunk and any 3rdparty that we don't change goes to /3rdparty.

All good, now the nightly build script has to tag the trunk, checkout the tag, check out the required 3rdparty stuff into proper directories, then start the build process.
The build result (compiled stuff) can stay on NFS mount for some period so Integration team can go back 2 weeks and recreate problems.

Are all my bases covered?

Answer 1

The SVN redbook here includes alot of information on layouts for different project types and how to manage them.

You may also want to use hooks/triggers/externals to pull in data from an independent repo called '3rd party'. So when a developer checks out one repo, he gets the 3rd part too. There are tons of ways to separate concerns but present a unified repo from component ones.

Good luck

Answer 2

It might be worth making use of a build engine like hudson or cruise control. The work flow is slightly different - tags are made after the build, but you can get extra modules that give you some control over that. Point is, all the dev work is done for you, and you get a decent framework for your nightly builds, and you get a nice web interface to control and monitor everything.

Personally, I'd put some externals definitions on trunk to pull in the appropriate 3rd party libraries into the appropriate places. That way, when you change 3rd party library version, you make the changes to trunk and don't have to modify the build scripts. It also means that you can build older versions just be checking out the appropriate trunk/tag/branch. Be warned - just do them on trunk, scattering them around can lead to murder.

I'd also layer the repo somewhat like:

project
 /trunk
 /branches
 /tags
3rdparty

Simply because this gives you more scope for adding more top level projects at some point. Doing this lets you manage different projects completely independently - and you can still use externals to reference the right versions from one to the other if there are dependencies - this nicely stops changes in one project silently breaking/changing dependant projects.

It's possible to do this using separate repos as well, which is fine, but in that case I'd put separate the 3rdparty section into a separate repo from the start.