我很好奇是否可以复制受版本控制的目录并开始处理这两个副本。
我知道从一个VCS到另一个VCS可能有所不同，但我故意不指定任何VCS，因为我对不同的情况感到好奇。
我最近和一位同事谈论在SVN做这件事。我认为应该没问题，但我仍然不能100％肯定，因为我不知道SVN究竟在工作副本中存储了什么。
但是，如果我们谈论DVCS世界，事情可能会更加不清楚，因为每个工作副本本身都是一个存储库。现在面对这样做，我决定问这个问题。
稍后编辑：
有些人问我为什么要那样做。以下是整个故事：
在SVN的情况下，因为不在办公室，与SVN服务器的连接非常慢，所以我和我的同事决定只查看一次来源并制作本地副本。这就是我们所做的，它运作良好，但我仍然想知道它是否有效，或者它刚刚发生。
在bzr的情况下，我打算将“主”仓库移动到另一台服务器。所以我想把它复制到那里并开始考虑主要的回购。我想最安全的是做一个克隆。
答案 0 :(得分：6)
在Subversion中，每个.svn文件夹都包含了包含文件夹所需的内容。并且由于所有本地路径都存储为相对路径，因此在复制原始结帐树之外的整个或部分树时，您是安全的。他们将继续在新家中运作。
我经常从我的主干外面复制子树，将新副本切换到其他分支/标签，并在“克隆”本地副本上执行必要的操作。这样，如果由于任何原因，我需要回去并在行李箱中做一些事情，我在原始位置有一个未受干扰的行李箱副本。
另一方面，将源控制目录复制到其他源控制树中是不安全。如果你要覆盖任何.svn文件夹，你很可能会破坏你的目标副本。
答案 1 :(得分：3)
我偶尔会在SVN中这样做，但我没有遇到任何问题。我相信在SVN中存储的所有内容都是目录的原始状态和指向它所来自的存储库目录的指针。
所以基本上它就像你认为的那样有效。
对于那些好奇我为什么要复制的人，我首先检查出一个较大的项目时，我的网络结账问题非常缓慢。相比之下，简单地从另一台计算机上复制似乎为我提供了所有相同的好处。
答案 2 :(得分：3)
在svn中，没问题。您可以使用该副本，就像您已进行第二次结帐一样。
我建议你第二次退房。如果你想要一个没有.svn文件的副本，svn export会创建一个。
答案 3 :(得分：2)
对于bzr，如果你只是将.bzr目录复制到另一个位置，它就会起作用。它不会存储有关其所在路径或其所在主机的任何信息，因此您可以将其复制到任何地方，并期望它可以正常运行。
答案 4 :(得分：0)
我建议不要，因为你正在规避源控制机制。
但也许你可以解释'为什么'？
答案 5 :(得分：0)
您还可以查看两份工作副本（至少使用SVN）来说明work / copy1和work / copy2并同时处理这两个版本。
我想知道你想要实现的是什么，因为复制可能不是你问题的最佳解决方案。
答案 6 :(得分：0)
这取决于VCS。我在CVS中知道它在每个版本控制的目录中存储（隐藏）目录。当然，这些文件随后会复制到该目录的任何副本。
通常情况下，您不希望复制rsync工具附带选项（-C）的隐藏文件，以忽略这些文件，就像CVS一样。
答案 7 :(得分：0)
当我从Visual Studio中重新组织文件夹布局时，我对SVN感到有些头疼。在解决方案中移动的文件夹将逐字地移动文件系统中的文件夹，包括隐藏的.svn文件夹。这会导致提交问题，因为.svn数据与旧路径相关联，并且我没有找到重新关联到其新路径的方法。 SVN clean up运行正常但没有修复任何问题。移动文件夹后，SVN switch不允许您更改它。我只能通过删除已移动文件夹及其子文件夹中的所有.svn文件夹来解决此问题，然后重新添加该文件夹。
我对此修复程序的问题是您丢失了对这些文件的版本跟踪，因为SVN将其视为全新的。此外，它不会通过存储先前版本的差异来有效地存储文件内容。
根据SVN文档，建议允许svn客户端执行所有文件夹移动/创建/删除，以使所有内容保持同步以进行下一次提交。 Visual Studio并不总是可以接受。幸运的是，大多数问题都是在提交期间捕获的，特别是如果你使用TortoiseSVN。
答案 8 :(得分：0)
对于SVN，这通常会像其他人已经说过的那样起作用。
如果你在机器之间复制，你可能会遇到麻烦。例如，如果您使用file：//存储库URL访问SVN存储库，则很可能会中断。这同样适用于http：//或svn：// URL，其中服务器访问可能不同。
为了保持安全，我只是在新地点结帐。如果你想在新的工作目录中有很多未经修改的更改（通常是一个坏主意），那么你可以使用rsync复制你的源代码而不引入.svn目录。
答案 9 :(得分：-2)
在我看来，GIT也可能满足您的需求，因为您提到断开连接或蹩脚的连接。 GIT也有非常好的SVN支持，所以这两者是互补的，你最终会得到一个很好的版本文件系统。