Jeremy D. Miller -- The Shade Tree Developer

We usually have our SVN structured like this:

/project

  /tags

      /...

  /trunk

      /lib

      /src

So that the lib (binary dependencies) get versioned with the src so it's recompile-able throughout history.

How do you (Jeremey and community) structure it?

Oops, 'Jeremy', rather. Sorry, too many 'e''s in there.

I fully agree.  When using VS.Net 2005 with Team System source control, I include a /lib folder in my project, and let the /bin stay out of source control.  Project references are made to the /lib folder, and so the automated build also finds them easily.  

I go one step further, and include all internally developed dependancies in /lib as well.  This way, each project includes the specific version of the dependancy that it was compiled with.  When the dependant dll is updated, the maintenance developers of the projects that use that dll can decide when to implement the new version.

What Tim said

We use a similar structure:

/Engagement Name 1/

   Main Development/

       Solution Name.build

       Solution Name.fxcop

       Solution Name.sln

       Application/

           Project.Domain/

           Project.Persistence/

           Project.Presentation/

           Project.WebApplication/

       Databases/

           Schema Scripts/

           Queries/

       Dependencies/

           Atlas/

           NHibernate/

       Project Stuff/

       Tests/

           Project.Domain.Tests/

           Project.Persistence.Tests/

           Project.Presentation.Tests/

       Tools/

           FxCop/

           NAnt/

           NMock2/

           NUnit/

   Release Candidate Stabilization/

        (branch of main)

   Production Bug Fixes/

        (branch of main)

/Engagement Name 2/

   ....

We've broken the bonds of the cryptic abbreviated folder names. :) All the tools are there for CruiseControl.NET to build/test/analyze each commit. Note the "project stuff" folder; that's where we keep requirements, estimates, developer notes, client messages... whatever is important.

PS: I hope the comments engine doesn't chew up my indenting because this would look like crap.

You should have a look at the Maven projects for Java. Their dependency management scheme is quite nice and obviates the need to place binaries in an SCM. What I never liked about storing dlls, etc in an SCM is when you have multiple projects that use the same binaries-- you end up having copies of the same binary throughout an SCM.

jimbolla (or anyone), where do you put your build outputs?

The Visual Studio default of adding obj + bin folders to every project seems less than optimal.

Also, what's a good list of svn:ignore patterns for Visual Studio work?

I'm used to letting Visual Studio handle its own ignores (via the source control provider), but in this case I'm not using one.

We keep our dependencies in vendor branches and use the svn:external property to include them in source control.  This allows for auto updates of dependencies, if the build breaks we just have to point the svn:external to previous version.  It works nice and it helps us resolve issues with dependency versions much quicker.  The only downside is when we tag we need to ensure the libs point to the correct revision of the dependency.

/projects/projectA

 /trunk

   /lib

     nhibernate=https://repo/vendor-bin/nhibernate/latest

     rhino-commons=https://repo/vendor-bin/rhino-commons/latest

   /src

/vendor-bin/

 /nhibernate

   /latest

   /1.2.0-CR1

   /1.2.0-GA

 /rhino-commons

   /latest