How do you organize your projects folders?

Question

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?

Hi, 2018 here. What did you choose? – Danyal Aytekin May 04 '18 at 16:15 — Danyal Aytekin, May 04 '18 at 16:15

score 9 · Answer 1 · answered Oct 25 '10 at 21:06

9

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.

answered Oct 25 '10 at 21:06

Wyatt Barnett

20,685
50
69

JBRWilkinson · Accepted Answer · 2010-10-25T22:14:01.930

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.

Pretty reasonable, but -1 for requiring hardcoded absolute paths. Hardcoded relative paths should work for 99.9% of things. — Wyatt Barnett, Jan 04 '12 at 20:45

score 5 · Answer 3 · answered Oct 25 '10 at 20:59

5

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.

answered Oct 25 '10 at 20:59

mipadi

7,493
36
35

Moving projects from Current to Work to Archive don't go well with using source version control tools. In this case it's better to have folder references/link (outside of working copy). Maybe you are moving working copies inside 'archives', 'current' and 'work'? – Fil Jul 21 '17 at 15:14
1

@Fil: I use Git. Each project is its own self-contained repo, so it doesn't matter where it gets moved to. – mipadi Jul 21 '17 at 21:04

score 5 · Answer 4 · answered Oct 25 '10 at 22:10

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.

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

score 3 · Answer 5 · answered Jan 04 '12 at 19:41

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.

score 0 · Answer 6 · answered Oct 25 '10 at 21:04

0

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

answered Oct 25 '10 at 21:04

alepuzio

341
4
15

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

How do you organize your projects folders?

6 Answers6

Linked

Related