源代码管理：应该是本地源树镜像服务器源码树吗？

Question

让我的本地源树镜像服务器源树是最佳做法吗？在我看来它应该，但是我的工作部门不这样做，我发现它很混乱。如果没有，那么偏离服务器源代码树的情况是什么？

编辑：澄清我的意思 - 说我们要在本地机器上映射的源目录在服务器上：

\\ TeamServer \项目\发布\ 2008

在我们的本地计算机上，该目录将如下映射：

d：\ 2008_Releases

而不是：

d：\项目\发布\ 2008

Answer 1

我不知道这是否是最佳做法，但我更喜欢镜像源树。在让新的开发人员启动并运行方面，它不那么“陷入困境”。当涉及相对路径时，不镜像源树最终会回来咬你。

有些人在他们最初设置时可能犯了一个错误，但从未得到纠正。恕我直言，这是一个小麻烦;只是没有生活在完美世界中的副作用之一;）

Answer 2

如果您的本地树需要与服务器上的路径相同，那么您不能签出多个副本。在我工作的最后两个地方，我常常在任何给定时间检查树的（部分）副本，具体取决于我正在处理多少不同的错误或功能，以及有多少分支错误或特征所在的产品。

就个人而言，我不知道源树存储在服务器上的哪个位置，我不需要。我刚刚运行cvs co或svn co来获取工作目录中树的副本。只要我在源代码树的某处运行make或ant，它下面的所有内容都会编译。

Answer 3

我更喜欢在他们自己的目录中拥有单独的项目/发布对，尽可能接近root。这是一个可怕的PITA，可以点击目录树，或者无数次地输入“c：\ project \ releases \ 2008”-part。

我还认为检查不同路径的源代码会倾向于清除有关项目位置的错误假设（我们有构建一些令人讨厌的事情的后期事件）。

Answer 4

有一个原因不能这样做：当您有权访问生产机器时。在这种情况下，我更喜欢有不同的路径。这使我更有可能发现我的“rm -rf”在错误的方框上......

Answer 5

我认为mirrowing是一个很好的做法，我也喜欢这样做，但是我有一个额外的临时文件夹，我需要签出一个新的版本，例如，使用当前版本测试某些内容或修复具有高优先级的错误然后我正在做的atm。

Answer 6

最重要的是要明白为什么做出选择并使用团队来确定这是否是您想要改变的事情。团队购买对于这些决策非常重要 - 团队不仅仅是开发人员。源代码控制树包含文档，测试，资源等内容，因此有多种合法机会可以由多方确定结构以找到共同点。

我们也在工作的地方使用TFS。我们有一个名为C：\ Source Control的公共根文件夹，它是所有Team Projects所在的主文件夹。之所以做出这样的选择，是因为各方都非常不喜欢驱动器会被各种文件夹弄得乱七八糟。

使用TFS，您可以选择映射多个工作区，因此您在本地计算机上执行的操作不由服务器上的结构决定。我个人的偏好以及我的团队的偏好也是使用单个工作空间映射到源控件根目录。考虑到TFS中的搁置功能，不需要考虑签出多个副本，因为如果需要处理其他内容，它们可以被搁置。

构建服务器也具有相同的映射。但是，这绝不会与部署结构相匹配。根据项目的标准删除构建。唯一出现问题的是在使用绝对路径时，例如在配置文件中。由于我们没有使用绝对路径（根据我们的开发人员指南中的定义），因此这不是问题。

Answer 7

人们对如何组织硬盘有不同的看法，为什么要强制执行特定的布局？

应该能够检查存储库中同一项目的多个工作副本 - 如果您坚持使用相同的层次结构，则不可能。

在我参与的一个大型项目中，数千个文件假设工作副本处于固定的绝对硬编码路径（\projectname）。为了与项目的几个分支合作，我们不得不求助于使用不同的驱动器号（在Windows上），这意味着我们必须将硬盘分成许多分区（6个或更多是常见的）。这非常不方便。

最终，我们必须将项目整合为更大项目的子项目。这意味着改变所有这些绝对路径，这是一项繁琐而耗时的任务。

使用相对路径可以提供更大的灵活性;但是，如果每个人都将项目根目录放在完全相同的位置，那么你不会注意到有人偶然在某处添加了绝对路径。