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

让本地源代码树镜像服务器源代码树是最佳做法吗？在我看来，这是应该的，但我的工作部门并没有这样做，我觉得这很令人困惑。如果不是，偏离服务器源代码树有什么意义

编辑：澄清我的意思-假设我们要映射到本地计算机上的源目录位于服务器上：

\\TeamServer\Project\Releases\2008

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

D:\2008\U发布

而不是：

---

D:\Project\Releases\2008

我不知道这是否是最佳实践，但我也更喜欢镜像源代码树。就启动和运行新开发人员而言，这少了一个“问题”。当涉及到相对路径时，如果不镜像源树，最终可能会对您造成不利影响

---

可能有人在最初设置时犯了一个错误，但从未得到纠正。我觉得这只是个小麻烦；这只是生活在一个不完美世界的副作用之一；）

有一个原因不这样做：当您可以访问生产机器时。在这种情况下，我更喜欢有不同的路径。这使得我更可能注意到我的“rm-rf”放错了框…

我更喜欢在自己的目录中尽可能靠近根目录的单独项目/发布对。点击目录树或者第无数次输入“c:\project\releases\2008”——这是一个可怕的PITA

---

我还认为，将源文件签出到不同的路径往往会清除关于项目位置的错误假设（我们有一些生成后事件，它们会做一些令人讨厌的事情）。

如果您的本地树需要与服务器上的路径相同，那么您就不能签出多个副本。在我工作过的最后两个地方，我在任何给定的时间都会签出树的多个副本（部分），这取决于我正在处理的不同bug或功能以及这些bug或功能所在的产品分支的数量

---

就我个人而言，我不知道源代码树存储在服务器上的什么位置，我也不需要知道。我只是运行了

cvsco

或

svnco

来获取我工作目录中的树的副本。只要我在源代码树的某个地方运行

make

或

ant

，它下面的所有内容都会编译。

我认为mirrow是一种很好的实践，我也喜欢这样做，但是，我有一个额外的临时文件夹，用于我需要签出新版本的情况，例如，用当前版本测试某些内容，或修复比我现在做的事情优先级更高的错误。

最重要的是理解为什么做出选择，并使用团队确定这是否是您想要的改变团队购买对于此类决策非常重要——团队不仅仅是开发人员。源代码管理树包含文档、测试、资源等内容，因此有一个合理的机会，即结构是由多方确定的，以找到共同点

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

使用TFS，您可以选择映射多个工作空间，因此您在本地计算机上执行的操作不受服务器上的结构的限制。我个人和团队的偏好是使用单个工作区映射到源代码管理根目录。考虑到TFS中的搁置功能，不必担心签出多个副本，因为如果需要处理其他内容，可以搁置这些副本

---

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

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

您应该能够在存储库中签出同一项目的多个工作副本—如果您坚持使用相同的层次结构，这是不可能的

在我从事的一个大型项目中，几乎有数千个文件假定工作副本位于固定的绝对硬编码路径中（

\projectname

）。为了与项目的多个分支合作，我们不得不使用不同的驱动器号（在Windows上），这意味着我们必须将硬盘划分为多个分区（通常有6个或更多分区）。这很不方便

最终，我们不得不将该项目整合为一个更大项目的子项目。这意味着要改变所有这些绝对路径，这是一项乏味而耗时的任务

---

使用相对路径会给你更多的灵活性；但是，如果每个人的项目根都位于完全相同的位置，您将不会注意到是否有人意外地在某处添加了绝对路径。

您能解释更多吗？你不反映服务器源代码树是什么意思？只是好奇-你用什么来进行源代码控制？我的一位开发人员最近仍在这样做，尽管shelving允许他这样做，而不必手动复制到另一个文件夹。我们使用subversion作为源代码管理，使用tortoise作为客户端。如果您需要签出多个副本，正确的方法不是创建一个分支吗？我一直认为分支就是为了这个，所以在某个时候它可以被合并回来。如果你有几份不同的复印件，你觉得怎么样