![版本控制和备份,哪种组合?](https://linux22.com/image/501465/%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B6%E5%92%8C%E5%A4%87%E4%BB%BD%EF%BC%8C%E5%93%AA%E7%A7%8D%E7%BB%84%E5%90%88%EF%BC%9F.png)
我是一名独立开发人员,有 3 台电脑。另外,我的一个朋友有一个帐户,但从未使用过。我当前的设置是 GIT + 我自己临时的备份作业,该作业克隆存储库、压缩它、对其进行 gnupg,然后将其发送到远程 ftp。到目前为止,这对于我的源代码/docbook/xml 文件 + 较小的二进制文件(主要是图标 + 一些用于 docbook 的图像)来说效果非常好。
然而,我最近参与了一个 Flash 游戏项目,并专门为它创建了一个存储库,但 Flash FLA 文件非常大(我见过超过 70 MB)。而且窗口大小较小的 git repack 无法完成。此外,我发现我的一些文件使用回车符而不是换行符,GIT 不太乐意对这些文件进行差异处理。当我创建存储库时,我应该将其设置为在提交时自动将 CR 转换为 LF。然而,我并不知道这些问题。
出于绝望,我尝试了 Mercurial,但它的最大文件大小是 10 MB。
我在想,也许可以将我的项目拆分成二进制文件并将它们保存在 Subversion 中,因为二进制文件似乎没问题。源代码保存在 GIT 中。但这将是一项艰巨的任务,听起来是个糟糕的计划。
您使用什么版本控制系统?您如何备份?您如何处理二进制文件?
答案1
这绝对是一个糟糕的计划,分裂你的版本控制系统!
我们每天都会通过 SVN 提交二进制文件,其中一些文件也很大。当然请注意,您无法比较二进制文件,如果您的二进制文件为 20mb,则每次提交时,您都需要在 Subversion 服务器上再腾出 20mb 的空间。
至于我们的备份,我们每晚只需运行一次 SVNDump,进行类似于您的压缩和上传。
尽管如此,这个问题也许更应该由堆栈溢出伙计们,因为他们比我们 SF 的 VC 用户更活跃!
(不要担心在那里重新创建这个问题,如果有足够多的人同意它将被自动移动)。
答案2
关于 CRLF - 查看 git-config(1),特别是选项“core.autocrlf”,它可用于切换转换行为。
答案3
您希望备份 70M 文件,对吗?如果是这样,无论您使用哪种方案,您至少都会将它们复制到 FTP 站点一次。如果它们完全可压缩,git 很可能会在实际可能范围内尽可能好地压缩它们。
为了避免每次备份时将整个存储库复制到 FTP 站点,我会查看
- 如果可能的话,使用“git push”到备份站点或从备份站点“git pull”,前提是您可以在该站点上安装 git。这样只会发送缺失的内容,而不会重复发送 70M 文件。
- 如果这不可能,有些软件可以通过 FTP 等“哑”协议进行差分发送。很多年前,我参与编写了一个名为“syncftp”(syncftp.sf.net)的软件。我的朋友 Simon(syncftp 的大部分代码都是他编写的)后来又编写了另一个名为“gsync”的工具。还有“sitecopy”,http://www.manyfish.co.uk/sitecopy/。需要注意的是:您需要配置 git,以便它不会将太多文件重新打包在一起,因为复制过程将基于文件,并且如果打包文件发生哪怕一点点变化,它都会复制整个文件。因此,您将在存储库中损失一些打包效率,以便在备份带宽使用中获得一些效率。
(我将保存您的 CRLF 文件以供其他答案)