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?

Principal

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

Savoyard

I may have seen some stuff about the release branch in the book, it will be a nice favor if you can point out where exactly it is. Thanks – Gradatim

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.

Margaretmargareta

Answer 3

Why don't you move the 3rd party into trunk? when every you branch a copy of 3rd party goes into branch. And obviously you wont change 3rd party stuff in branche because your branch has coded based on the existing 3rd party stuff.

I'm not so sure about tagging what you are talking about. Is that the version number you mean? If it is version number pass that thru script and label the build.

Royo

3rd parties in trunk? Please no, that way madness lies. 3rdparty is basically a vendor branch from the red-book, keeping them separate is my vote. – Margaretmargareta

Answer 4

If the "multiple directories" are separate components that you want to version independently, then you should have each in its own repository so that they can be tagged separately. But if this is all a single self-contained project (i.e. if you will generally be tagging and branching all components together), then you can probably put all of the code in the same repository.

You should consider using externals for the third-party artifacts.

Baseler

Answer 5

My script checks out trunk, modifies the files (adjusts version numbers in AssemblyInfo.cs files, etc.), then tags that. If you don't need to modify the files in any way, then tagging first would be good as well.

Other than that, your setup sounds good to me at least.

Shavon

have to reference 3rd party outside your base folder is not a good idea. I would create a folder under trunk\lib and put all the 3rd party stuff in there. This way you can avoid references to outside your base. IMGLO – Royo

Have you posted your script anywhere so I can take a look? Thanks – Principal

It's a FinalBuilder script, send me an email (address in profile), and I'll send you a copy. Unless you're using FinalBuilder though it probably won't do you much good. – Shavon