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