Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Good afternoon

I would like to know how do you guys organize your project folders?

I had once a boss that suggest me to organize by Customers.

Projects
|
|----Customer 1
     |---- A Cool Solution 1
           |---- source
                 |---- version1.0
                 |---- version1.1
           |---- docs
                 |---- analysis
                 |---- meetings
                 |---- manuals
|----Customer 2
|----Customer 3

A friend of mine told me to organize tem by Technology

Projects
|
|----.NET
     |---- C#
          |---- Customer 1     
                |---- A Cool Solution 1
                      |---- source
                            |---- version1.0
                            |---- version1.1
                      |---- docs
                            |---- analysis
                            |---- meetings
                            |---- manuals
|----Ruby
|----PHP

And you? Do you have a clever way to organize your project folders?

share|improve this question
add comment

6 Answers

up vote 4 down vote accepted

This is what we've been using:

Projects
|
|----Customer A
     |---- Project 1
     |     |---- BuildControl       (CI/nAnt/Make/MSBuild files and config, etc)
     |     |---- Documentation      (In XML format so we can 'build' them)
     |     |---- Source
     |     |     |---- Component X
     |     |     |---- Component X.tests
     |     |     |---- Component Y 
     |     |     |---- Component Y.tests
     |     |---- Testing
     |     Project 1.sln      (Has folders as per project on-disk structure)
     |---- Project 2
     |---- Shared/Common components
|----Customer B
|----Customer C
|----<Our Company>
     |---- Internal Project A
     |---- Internal Library B

We've been using this structure for multiple projects with many different customers for years now and it works very well.

It's very similar to your initial suggestion, but we use version control to manage the versioning. The server repositories are named as "Customer X - Project Y", rather than anything else. This allows us to have external contractors working on some projects but not able to access others as we can set permissions at the version control root.

Everyone checks out their working copies to wherever they want on their (Windows) dev machine and uses the SUBST command to map a drive letter to that location. That way we can have hard-coded relative paths in build files, etc, that work across everyones' setup. So, for example, we can have links to shared libraries, if we so wish. We usually use version control links/aliases to achieve this tho.

One big benefit of this structure is that you can isolate customers' code from each other. This is useful if you need to (a) send them regular updates of the source for integration purposes, (b) have external contractors working on selected parts of the code.

Your second suggestion won't work so well with a complex project which uses more than one technology.

share|improve this answer
    
Pretty reasonable, but -1 for requiring hardcoded absolute paths. Hardcoded relative paths should work for 99.9% of things. –  Wyatt Barnett Jan 4 '12 at 20:45
1  
Er, did I put absolute paths in there? –  JBRWilkinson Jan 5 '12 at 22:30
add comment

I'm pretty flat:

/Projects

Some varation getting there depending on box, but behind that there are just lots of individual folders for projects. Real deal lives in source control anyhow, so this is just the temporary local home.

share|improve this answer
add comment

I also have a flat structure.

/Projects

Agreeing with Wyatt Barnett, real deal lives in source control anyway.

Just want to add that there shouldn't be anything special about folder structure anyway, since many IDEs provide shortcuts to recent projects/files anyway. And how many projects does anyone work on anyway? Truly, only by definition, the recent ones.

Also, I only add recent projects into top level folder anyway. I archive all the older and completed stuff into:

/Projects/Old_stuff

or something like that. I archive what I generally won't be working on again.

share|improve this answer
    
You'd be surprised -- I typically need a dozen or so projects hooked up, current and ready to run on my "go" laptop and can easily open a half dozen in the course of a normal day. –  Wyatt Barnett Oct 26 '10 at 12:19
add comment

I have a structure that loosely looks like the following:

~/
|-- Developer/
|   |-- Projects/
|   |   |-- Archives/
|   |   |-- Current/
|   |   |-- Work/
|-- Projects -> ~/Developer/Projects/Current

Archives contains old projects I'm no longer working on. Work contains work-related projects. Current is all current development. Then, in my home directory, I symlink Projects to ~/Developer/Projects/Current. ~/Projects also includes symlinks to some work projects.

share|improve this answer
add comment

I have, in the past, used Subversion repositories to store my source documents, and followed the "project-minor" convention for repository organisation, which I have found to work very well for both large and small organisations.

We would structure our repository branches; tags & trunk as follows:

branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk

Within the actual source tree itself, we would use (something like) the following structure:

  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct-+
        |                               +-build
        |                               +-doc
        |                               +-test
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

The idea was (and still is) to use the structure of the repository to help structure communication between the engineering team; the customer-facing part of the business and various other stakeholders & domain experts.

To wit: Source documents that sit in one of the "project" directories get used (and earn money) only once. Documents that sit in one of the "productLines" directories earn money as many times as a product from that particular line gets sold. Documents that sit in one of the "libraries" directories earn money as many times as any of the products that use them get sold.

It makes the notion of amortization of costs explicit, and helps build support for source document reuse across the business.

In an ideal world, the customer facing part of the business would also use this structure to store presentations & other sales collateral, so developers can see what customer expectations have been created, right alongside the relevant product directory, and customer facing colleagues can track development progress on the features and products that they are selling.

It also means that there is a common structure over which our build automation tools can operate. (Our build scripts walk the source tree looking for "build" folders within which they find configuration files specifying how each component is to be built; a similar process happens for documentation generation and testing). Again, in an ideal world, the organization's website and other marketing collateral could be built in the same way.

As one final note; the continuous integration system knows that it needs to trigger a build; static analysis; smoke test & unit test run each time trunk is modified, each time any "tag" branch is modified, and each time any "AUTOMATED" branch branch is modified. This way, individual developers can use the CI system with their personal branches, an important capability, IMHO.

share|improve this answer
add comment

I think that you means "documentation folder". I organise my documents for sector first at all, after for customer/application, at the end for "developing and maintenance".

Example: Projects

  • Financial

    • Web application

      • App Alpha

         - source
         - functional docs
         - etc etc (testing, meeting with customer)
        
      • App Beta

         - functional docs
         - etc etc (testing, meeting with customer)
        
    • Desktop software
  • Energy & utilities
  • BLA BLA
share|improve this answer
    
What about version control? Doesn't an Alpha document become a Beta document as it progresses? –  JBRWilkinson Oct 25 '10 at 21:55
    
In local desktop I haven't all the copies of all the version: I have got the last stable version of code, documents, etc. If I need of another previous version I download this version by Subversion et similia (storing as another project in the sector: App Beta_version_XYZ if financial) –  alepuzio Oct 26 '10 at 13:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.