3

是否可以通过将更改发布到“哑”文件服务器并在另一端重新组装它们来镜像存储库（在您选择的 SVN、Git、Hg 等中）？

流程示意图

可能的担忧包括

  • 处理移动/重命名/删除的文件
  • 二进制文件
  • 空目录

例如，我理解svn diff > r1.patch意味着您丢失了二进制文件，因为 SVN 不打算包含它们。

注意：这并不是在文件服务器上放置一个存储库（除非有一种方法可以在不上传整个存储库文件的情况下做到这一点），因为我们正在尝试最小化带宽。此外，存储差异而不是存储库意味着可以进行加密。

4

4 回答 4

3

是的，有可能

颠覆

  • 从修订版 N ( svn diff -c N --git PATH > PATCH.N) 制作 git-patch；
  • 存储补丁；
  • 在另一侧应用补丁 ( svn patch PATCH.N <WCPATH>);

水银

单一变更集交换（对合并集也不利）

  • 将变更集 N 导出为补丁 ( hg export -g -r N -o %b-%r.patch) (-o 带有文件名，用于一个目录中的多存储库)；
  • 存储补丁；
  • 在另一侧应用补丁 ( hg import --exact -s 100 FILENAME.patch)。

范围集交换

捆

  • 捆绑范围 N:M ( hg bundle --base parent(N) --rev N::M N-M.hg);
  • 存储补丁；
  • 在另一侧应用补丁 ( hg unbundle -u N-M.hg)。

出口

  • 将范围集 N:M 导出为补丁 ( hg export -o %b-%r.patch -r N::M)（文件名为“repobasebame-revno.patch”的补丁集）；
  • 存储补丁；
  • 相应地（从最少到最多）在另一侧应用补丁。
于 2013-01-23T05:28:24.270 回答
2

因为git有bundle命令。它创建给定修订的二进制存档。您可以在每次提交的基础上或成组地将任何历史记录放入包中，复制到文件服务器，然后恢复回存储库。

git bundle create file.name revisions..list- 用于创建捆绑包的命令。

git bundle unbundle file.name— 恢复修订的命令。

明确地，您应该为您的捆绑包按时间顺序命名，以免混淆它们。

它适用于git并且据我所知，hg它也有bundle命令。这就是你绘制它的方法。

另一种方法可能只是init在您的 Dropbox 文件夹中新建中间存储库，然后将您的提交从主存储库推送到那里，然后让 Dropbox 将其与镜像同步。然而，在这种情况下，只有在 Dropbox 同步完成后才能将镜像存储库拉入。否则数据可能不一致，因为 git 使用大量小文件来保存存储库内容。可以通过打包存储库内容来避免这种行为。但是，如果您为了安全起见，捆绑方法将最适合您...

编辑：关于svn我最近得到了另一个线索。如果您可以使用标准备份方法git来hg实现您的需要，为什么您可以尝试本问答svn中描述的标准备份方法？

svnadmin dump repositorypath -r LO_REV:HI_REV > backupname.svn备份修订。

svnadmin load repositorypath < backupname.svn恢复数据。

于 2013-01-18T15:46:56.627 回答
0

您是否有任何理由不只是使用像 github 这样的存储库托管程序？这将最小化带宽，因为 git 只推送差异。

于 2013-01-22T11:10:06.257 回答
0

git 本身在发送所需的差异方面做得很好，所以根本不需要。对于 mercurial (hg) 也是如此，如果 bzr 没有，我会感到非常惊讶。显然，像 svn 或 cvs 这样的集中式 VCS 不会。仅当存在其他限制时，您将文件传送到文件服务器才有意义（如果有，我们需要了解它们才能真正提供帮助）。

您也可以使用 rsync(1) 复制存储库，但在这种情况下，您不能指望 VCS 确保没有人看到半更新的内容，如果您这样做，请务必小心。通常（bzr 除外）您可以在其他地方备份和恢复存储库，它应该可以正常工作。

在任何情况下，永远不要盲目相信隐藏在有缺失位的彩色方块后面的人告诉你的内容......检查自己，阅读文档，寻找推荐的做法，并进行一些实验。

于 2013-01-23T01:07:39.343 回答