SVN Visual Studio存储库的工作目录结构 [英] Working directory structure for SVN Visual Studio repository

问题描述

我刚刚在我们公司为Visual Studio项目引入了SVN，并创建了一个看起来像这样的存储库(解决方案"是Visual Studio解决方案，包含1..n个项目):

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:

选项A :让用户使用AnkhSVN分别签出每个解决方案，从而得到这样的结构:

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/...

或者这，如果我告诉用户手动创建一个customerX子目录:

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.

选项B :告诉用户使用TortoiseSVN检出整个存储库，从而导致结构与存储库完全相同:

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/...

优点:"svn更新所有内容"非常容易.缺点:用户还具有所有分支和标签的本地副本.

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

问题:由于一些项目在解决方案之间共享(例如，例如projectA是solution3也使用的库)，我们需要修复一个目录结构，以确保解决方案文件中的相对路径是正确的.您推荐哪种选择，为什么?

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?

感谢您的所有出色回答，尤其是提到svn:externals并强调了良好存储库设计的重要性.我最终更新了我的存储库结构:

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/...

这确保仅使用solution3的开发人员需要 检出solution3(而不是solution1) ，并且可以将解决方案检出到任何目录，即工作目录不需要固定的结构.

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.

推荐答案

呵呵，这可能不是很有帮助，但是……都不是. :)

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

我会在最顶层使用trunk，将项目和解决方案组织在一个扁平的结构中，并且彼此平行.然后，我将使用解决方案目录上的svn:externals属性将适当的项目拉入每个开发人员的工作副本中的正确位置.

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.

我这样组织事情的原因是，它为您提供了选项A和选项B的好处.因此，如果开发人员只想签出一个解决方案，他们可以自由地这样做.同样，他们也可以检查整个主干(如果愿意的话)(而且他们能够这样做而无需获取标签和分支).

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.

这篇关于SVN Visual Studio存储库的工作目录结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！