I would recommend one line of versioning per repository for most cases. Here is a sample trunk set up with a VS.Net solution.
root
- trunk
– bin
– nant
– log4net
– src
– project 1
– project 2
– mysolution.sln
– CommonAssemblyInfo.cs (for version number, etc)
– automatedbuild.build
– clickToBuild.bat
- tags
– 1.0.0.1
– 1.0.0.2
– 1.0.0.3
– 1.0.3.1
– 1.0.3.2
– 1.0.0.4
– 1.0.0.5
- branches
– 1.0.0.3-hotfix
It can be ok for one project but if you want to handle more than that, or like to reuse things it will be very hard. It is very untypical and mixes several different things together. E.G a trunk is meant to be tagged later (most of the time). Why would I like to tag project 1 and project 2 in one tag? I recomend to read.
http://svnbook.red-bean.com/en/1.0/ch05s04.html#svn-ch-5-sect-6.1
I forgot to mention SOURCE folder under the trunk in my previous comment.
Thanks Jeff for this input, helpful it is.
This is how I structured SVN in our development department:
- Product Root
– trunk
– bin (product deliverables)
– lib (external referenced libraries/frameworks)
– autoBuild.build
– branches
– tags
– docs (Product documentation & issue tracker log)
However, I’m confused in regards to NUnit & NHibernate, what should be within the repository and what level?
Cheers,
I like this structure:
-bin
-src
-lib
-default.build
The build at level of bin,src, and lib.
You forgot lib ?
Excellent!
Exactly how I have mine setup. I feel warm and fuzzy now =)
Except mine has a dir called libs instead of bin for external dependecies.
I also have a folder in the root called docs or extras for things that shouldn’t be branched all over the place like original PSD’s (if a web project), documentation etc… Branching the hell out of your PSD’s can quickly explode your file size =)
We have a “Libraries” project for external dependencies and a “TestLibraries” project that contains nunit, Rhino.Mocks, etc… i.e. all libraries that are not shipped.
Also, on projects that use code generation, I have a CodeGeneration folder that contains all the templates and config files for generating the data access layer base classes… versioning these templates alongside the code that is generated has saved some major headaches.
I use a similar structure with one exception: “bin” is called “tools”, because “bin” is my target folder for the build process, i.e. it will contain all deliverables.
We use an almost identical tree with one exception. The bin folder in our environment is the dumping ground for things built for this product and in most cases what is deployed. We add a sibling folder “lib” that we use for all external libraries and our own framework. Then all the projects reference the local lib folder so you don’t have to worry about external version issues with other products.
Also, we use a different repository for each product. Otherwise projects would share the revision number count.
@Diego,
Each project has a “trunk”. Each trunk has a “tags” and “branches”. The tags for a particular trunk belong to the project in that trunk.
Project2 has a different trunk, different tags, different branches, and most of the time, a different Subversion repository.
Do NOT put more than one project (Solution in VS.Net terminology) in a single trunk. Even if the system produces several assemblies, they are all the same version since they are part of the same system. Different system, different trunk.
@Joe,
I would recommend this for any source control system. A “tag” in Subversion is a “Label” in some other systems.
How would you know which project tag w.x.y.z is from?
Hehe… I use a very similar layout. I’ll often have “libs” or “tools” folders next to the “src” folder for external binary dependencies.
For MbUnit.Gallio, I managed to omit the CommonAssemblyInfo.cs approach to setting assembly versions by injecting custom targets into the projects with the $(CustomBeforeMSBuildTargets) property when building from the command-line. The common assembly info is generated in a temp folder instead and added to the @(Compile) item group dynamically.
That looks strangely familiar Jeffrey. I think Steve would approve.
@Damien,
We did the “Shared” piece by just using a separate repository. I have no idea if that’s better or worse for SVN. Regardless, I like using SVN externals underneath each project’s \bin folder so that you only have to check out from Trunk.
This is similar to what we use but we have one level above trunk where we separate the various different actual projects (not necessarily VS projects).
We also have a ‘shared’ at top level where we put re-usable libraries and routines used by many separate projects.
[)amien
Would you reccomend this for other version control systems (such as TFS)?
The “official” guidance on Codeplex seems convoluted to me, whereas your approach is similar to almost everything I’ve ever seen.