Question

首先，我知道这一点：How would you organize a Subversion repository for in house software projects? 接下来，实际问题：我的团队正在重组我们的存储库，我正在寻找有关如何组织它的提示。（在这种情况下为SVN）。这就是我们想出的。我们有一个存储库，多个项目和多个svn：externals交叉引用

\commonTools /*tools used in all projects. Referenced in each project with svn:externals*/
   \NUnit.v2.4.8
   \NCover.v.1.5.8
   \<other similar tools>
\commonFiles /*settings strong name keys etc.*/
   \ReSharper.settings
   \VisualStudio.settings
\trash /*each member of the team has trash for samples, experiments etc*/
   \user1
   \user2
\projects
   \Solution1 /*Single actual project (Visual Studio Solution)*/
      \trunk
         \src
             \Project1 /*Each sub-project resulting in single .dll or .exe*/
             \Project2
         \lib
         \tools
         \tests
         \Solution1.sln
      \tags
      \branches
   \Solution2
      \trunk
         \src
             \Project3 /*Each sub-project resulting in single .dll or .exe*/
             \Project1 /*Project1 from Solution1 references with svn:externals*/
         \lib
         \tools
         \tests
         \Solution2.sln
      \tags
      \branches

清除词汇表：解决方案意味着单个产品，Project是Visual Studio项目（产生单个.dll或单个.exe）

我们计划如何布置存储库。主要问题是，我们有多个解决方案，但我们希望在解决方案之间共享项目。我们认为将这些共享项目移动到他们自己的解决方案中没有任何意义，相反，我们决定使用svn：externals在解决方案之间共享项目。我们还希望将一组通用工具和第三方库保存在存储库中的一个位置，并使用svn：externals在每个解决方案中引用它们。

您如何看待这种布局？特别是关于svn：externals的使用。这不是一个理想的解决方案，但考虑到所有的利弊，这是我们能想到的最好的解决方案。你会怎么做？

Answer 1

我相信Pragmatic Version Control using Subversion拥有组织存储库所需的一切。

Answer 2

我们已将我们的设置与您发布的内容完全匹配。我们使用一般形式：

\Project1
   \Development (for active dev - what you've called "Trunk", containing everything about a project)
   \Branches (For older, still-evolving supported branches of the code)
       \Version1
       \Version1.1
       \Version2
   \Documentation (For any accompanying documents that aren't version-specific

虽然我认为不如你的例子那么完整，但它对我们来说效果很好，让我们把事情分开。我喜欢每个用户都有一个“Thrash”文件夹的想法 - 目前，这些类型的项目最终都没有在Source控件中，我一直认为他们应该这样做。

Answer 3

为什么要将它全部放在一个存储库中？为什么不为每个项目都有一个单独的存储库（我的意思是“解决方案”）？

好吧，至少我已经习惯了每个项目一个存储库的方法。您的存储库结构似乎过于复杂。

您计划将多少个项目放入这个大型存储库？ 2？ 3？ 10？ 100？

当你取消一个项目的开发时你会怎么做？只需从存储库树中删除它，以便将来很难找到它。还是让它永远躺在身边？或者当您想将一个项目完全移动到另一个服务器时？

那些版本号的混乱怎么样？一个项目的版本号如2,10,11，而另一个项目如1,3,4,5,6,7,8,9,12 ......

也许我很愚蠢，但我喜欢每个存储库一个项目。

Answer 4

我有类似的布局，但我的行李箱，树枝，标签一直在顶部。所以：/ trunk / main，/ trunk / utils，/ branches / release /等等。

当我们想要尝试其他版本控制系统时，这最终变得非常方便，因为许多翻译工具最适合基本的教科书SVN布局。

Answer 5

我认为提出的结构的主要缺点是共享项目只会使用添加的第一个解决方案进行版本控制（除非svn：externals比我想象的更漂亮）。例如，当您为Solution2的第一个版本创建分支时，Project1将不会分支，因为它位于Solution1中。如果您需要稍后从该分支构建（QFE版本），它将在分支时使用最新版本的Project1而不是Project1的版本。

出于这个原因，将共享项目放在一个或多个共享解决方案中（以及结构中的顶级目录）可能是有利的，然后在任何解决方案的每个版本中对它们进行分支

Answer 6

要添加到相对路径问题：

我不确定这是一个问题：
只需在名为“Solution1”的目录下检查Solution1 / trunk，同样解决Solution2：实际表示分支的“目录”的目标是导入工作区后不可见。因此，'Solution1'（实际上是'Solution1 / trunk'）和'Solution2'（Solution2 / trunk）之间可能存在相对路径。

Answer 7

RE：相对路径和共享文件问题 -

这似乎是特定的svn，但这不是问题。另一个人已经提到了单独的存储库，这可能是我可以想到的最佳解决方案，在这种情况下，您有不同的项目引用任意其他项目。如果您没有共享文件，那么OP解决方案（以及许多其他解决方案）将正常工作。

我们仍在努力解决这个问题，我现在有三种不同的努力（不同的客户端）我必须立即解决，因为我接手设置了不存在或不良的版本控制。

您如何组织版本控制存储库？

8 个答案: