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.

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

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.

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.

How would you know which project tag w.x.y.z is from?

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.

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.

Pingback from  13 Links Today (2007-09-20)

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.

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 =)

I like this structure:

-bin

-src

-lib

-default.build

The build at level of bin,src, and lib.

You forgot lib ?

Pingback from  Daily Links - November 9, 2007 | GrantPalin.com

Pingback from  Structuring Your Subversion Repository | GrantPalin.com

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 forgot to mention SOURCE folder under the trunk in my previous comment.

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.

svnbook.red-bean.com/.../ch05s04.html