Home/ Questions/Q 425683
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T19:24:16+00:00

I just introduced SVN in our company for our Visual Studio projects and created

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0