Is my source/development file hierarchy a good one?

Question

I'm looking to organise my source code file hierarchy. I'm a C# (.NET) developer and come from an only Windows background (no Linux/Mac). I plan on using Subversion for source control.

This is what I've come up with: (from subversion view)

Root of Subversion Repository

 CompanyName
    /ProjectCodeName
     1---/Branches
     1---/Tags
          2---/InitImport-01-09-2009    // Tag of the initial import of the code.
          2---/Release1.0               // Tag of release 1.0 of the trunk.
     1---/Trunk
          2---/Dev                      // Checked out by developers (main root).
               3---/Deploy              // Contains everything to build the product.
                    4---/Builds         // Placeholder for output of Scripts/Setup
                                        // -> (always empty in subversion).
                    4---/Scripts        // Contains scripts to build/copy.
                    4---/Setup          // Contains setup scripts/project.
               3---/Help                // Help documentation of the product (source files).
               3---/Resource            // Contains images, icons, etc for product.
               3---/Source              // The main source code.
                    4---/Shared         // Contains code/binary(dll) to be shared.
                         5---/Libraries // Contains own code to share.
                              6---/SharedClassLibraryExample
                              6---/SharedClassLibraryExample.UnitTests      
                         5---/Referances      // Contains third-party code (dll's)
                    4---/WinFormAppExample    
                    4---/ClassLibraryExample
                    4---/ClassLibraryExample.UnitTests
                    4---/SubProjectExample
                         5---/Shared
                              6---/Libraries
                              6---/Referances
                         5---/ClassLibraryModule1Example
                         5---/ClassLibraryModule1Example.UnitTests
                         5---/ClassLibraryModule2Example
                         5---/ClassLibraryModule2Example.UnitTests                   
               3---/Test                // Contains test cases for the product.
          2---/Docs                     // Checked out by developers/managers for 
                                        // design specs, etc.

I am open to any suggestions. Thanks.

Answer 1

Generally I think it's OK. But I think that you are going a little over the top with the source folder.

But please note that this structure will not work with distributed source control systems.

Answer 2

I personally think uppercase initial letters are a PITA because of the extra key-press for shift (UNIX is case-sensitive, and I live my life in the console).

The structure however looks sound. I (as a developer) would quickly navigate to /ProjectName/Trunk/Dev, where I would find the main categories of interest.

Maybe I would have chosen to move /ProjectName/Trunk/Dev/Deploy/Builds to /ProjectName/Trunk/Dev/Builds. Then again, I would never place binaries/builds under revision control. Common practice is to build outside the source-tree.

But overall the structure looks good!

Answer 3

1. Do you plan to have ProjectCodeName2 someday? If not, move everything back 1 directory.
2. Get rid of Dev. Developers will have both the code and docs, so they work on trunk. Let Managers get Docs.
3. Be careful not to branch any directory that contains binary files (like word docs). You can't merge them!

Answer 4

To make it simple here is a sample repository structure as I usually do it

/root
 / branches   -- for all the features that could take a little longer
 / tags       -- For the important revisions in the project life cycle
 / releases   -- Releases that are delivered to the customer
 / trunk      -- Where the actual work will get doe
   / Sources  -- The name says everything
   / Tests    -- Tests for the application being written
   / Lib      -- All the nice libraries that your application will use
 /Doc         -- Application documentation that is not revision dependent

I know that my structure is not so worked out as your original one. But I would suggest that you keep it as simple as possible.

Do not overcomplicated your repository structure. Rather invest in a build tool like nant and put the task of structuring your deployment packages to that.