Working directory structure for SVN Visual Studio repository

Question

I just introduced SVN in our company for our Visual Studio projects and created a repository that looks like this ("solution" is Visual Studio solution, containing 1..n projects):

/solution1/trunk/projectA/...
                /projectB/...
/solution2/trunk/projectC/...
/customerX/solution3/trunk/projectD/...
          /solution4/trunk/projectE/...
                          /projectF/...

Now, I have two options to structure the local working directories:

Option A: Let the user checkout each solution separately using AnkhSVN, leading to a structure like this:

/solution1/projectA/...
          /projectB/...
/solution2/projectC/...
/solution3/projectD/...
/solution4/projectE/...
          /projectF/...

or this, if I tell the user to manually create a customerX subdirectory:

/solution1/projectA/...
          /projectB/...
/solution2/projectC/...
/customerX/solution3/projectD/...
/customerX/solution4/projectE/...
                    /projectF/...

Advantage: The user can checkout only the solutions that he really needs. Disadvantage: Every solution needs to be checked out/updated separately.

Option B: Tell the user to checkout the whole repository using TortoiseSVN, leading to a structure that is exactly the same as the repository:

/solution1/trunk/projectA/...
                /projectB/...
/solution2/trunk/projectC/...
/customerX/solution3/trunk/projectD/...
          /solution4/trunk/projectE/...
                          /projectF/...

Advantage: It's very easy to "svn update everything". Disadvantage: The user also has a local copy of all branches and tags.

---

QUESTION: Since some projects are shared between solutions (let's say, e.g., that projectA is a library which is also used by solution3), we need to fix one directory structure, to make sure that the relative paths in the solution files are correct. Which option do you recommend and why?

---

EDIT: Thanks for all your excellent answers, in particular for mentioning svn:externals and for stressing the importance of a good repository design. I ended up updating my repository structure:

/trunk/solution1/projectA/...
                /projectB/...
      /solution2/projectC/...
      /customerX/solution3/projectD/...
                          -svn:external to projectA
                /solution4/projectE/...
                          /projectF/...

which ensures that a developer working on solution3 only needs to check out solution3 (and not solution1) and the solution can be checked out to any directory, i.e., the working directory does not need a fixed structure.

Answer 1

Hehe, this is probably not very helpful, but... neither. :)

I would have trunk at the very top level, with the projects and solutions organised underneath that alongside each other in a flat structure. Then I would use the svn:externals property on the solution directories to pull in the appropriate projects to the correct location in each developer's working copy.

The reason I'd organise things this way is that it gives you the benefits from both your option A and your option B. So, if developers only want to check out a single solution, they are free to do so. Likewise they can also check out the entire trunk if they'd rather do that instead (and they are able to do so without getting tags and branches).

Also, this approach of having a single trunk makes it far easier to tag or branch the entire repo, if ever you need to do that.

Answer 2

Option A - you do not want to be pulling the whole repository down (all the tags and branches) every time and it will encourage your users to think of the whole repository as a single entity which it isn't really - you want them thinking in terms of solutions and of tagging/branching in that context.

You address shared projects by referencing them as externals in the "root" of the appropriate solutions. This will mean that you may have the same project appear multiple times on your HDD but that's manageable.

There's a teeny bit more on the subject here: HowTo: Reference external SLN files with TeamCity