似乎有很多版本控制系统。因此，要得出一个不好的结论，就必须容易写一个。
为了编写简单的文件版本控制系统，必须考虑哪些问题？ （最低必要功能是什么？）
对一个人来说这是一项可行的任务吗？
答案 0 :(得分：21)
了解版本控制的好地方是Eric Sink's Weblog。例如，他最近的一篇文章是Time and Space Tradeoffs in Version Control Storage。
另一个很好的例子是他的一系列文章Source Control HOWTO。是的，这都是关于如何使用源代码控制，但它有很多关于开发人员在设计系统时必须做出的决策和权衡的信息。最好的例子可能是他关于Repositories的文章，他解释了存储版本的不同方法。我从这个系列中学到了很多东西。
答案 1 :(得分：10)
有多简单？
您可以使用单行shell脚本upversion.sh编写版本控制系统：
cp $WORKING_COPY $REPO/$(date +"%s")
对于大型二进制资产，基本上就是您所需要的！它可以很容易地改进，例如将版本文件夹设置为只读，也许记录每个版本的元数据（例如，您可以在$REPO/$(date...).meta处有一个文本文件）
这听起来像是一个巨大的简化，但它与许多电影后期制作机构使用的资产管理系统并不相同（例如）
你真的需要知道你想要什么版本，为什么......
对于大型二元资产（比如视频），您需要专注于可视化比较版本的工具。你也可能需要处理依赖性（“我需要image123.jpg和video321.avi来生成这个图像”）
使用代码，您需要专注于在任何两个版本之间制作差异非常简单的事情。此外，由于对源代码的编辑通常较小（来自具有数千行的项目中的几个字符），因此复制每个版本的整个项目将非常低效 - 因此您只存储每个版本之间的差异（{{ 3}}）。
要对数据库进行版本控制，您可能希望存储有关架构的信息，跟踪新表或列，或者对现有数据库进行调整（而不是计算数据库文件的增量，或者像前两个系统一样制作副本）< / p>
没有完美的方式来版本化所有内容，你必须专注于做好一件事.Git非常适合文本，但不适用于二进制文件。 Adobe Version Cue非常适合使用二进制文件（图像），但对文本无用。
我想要考虑的事情可以概括为......
答案 2 :(得分：6)
查看关于（D）VCS的问题“core concepts” 简而言之，编写VCS将涉及对每个核心概念做出决策（中央与分布式，线性与DAG，以文件为中心与以存储库为中心，......）
不是“快速”项目，我相信;）
答案 3 :(得分：4)
如果你是Linus Torvalds，你可以在一个月内写下像Git这样的东西。
但是“版本控制系统”是一个模糊且可伸缩的概念，你的问题实在无法解决。
我会考虑问问自己你想要达到的目标（了解VCS，学习语言，......）然后定义一些明确的目标。拥有一个项目是件好事，但在很短的时间内实现可达到的目标也是一件好事。小小的成功对你的士气有好处。
答案 4 :(得分：3)
这真的是一个糟糕的结论。我个人的观点是，问题领域是如此广泛而且普遍困难，没有人能够“正确”地解决它，因此人们试图从不同的角度和不同的假设一遍又一遍地解决它。
当然，这并不意味着你不应该尝试。请注意，许多聪明人都在你面前，所以你应该做好功课。
答案 5 :(得分：2)
The Git Parable可以用较少技术的方式为您提供良好的概述。 它是git原理的一个很好的抽象，但它非常好地理解了VCS应该能够执行的内容。除此之外的所有事情都是相当“低级”的决定。
答案 6 :(得分：1)
良好的增量算法，良好的压缩和网络效率。
答案 7 :(得分：1)
一个人可以做一个简单的学习机会。您可能考虑的一个问题是如何有效地存储纯文本增量。一种非常流行的增量格式是one from RCS（许多版本控制程序使用）。你可能想研究它以获得想法。
答案 8 :(得分：0)
最小的必要先决条件是详尽而准确的测试套件。没有人（包括你）会想要使用你的新系统，除非你能证明它是可行的，可靠且完全没有错误。
答案 9 :(得分：-1)
要编写概念证明，您可能会将其删除，实施或借用Alan提到的工具。
恕我直言，VCS最重要的方面是易用性。这听起来像是一个奇怪的声明，但是当你想到它时，硬盘驱动器空间是最容易横向扩展的IT商品之一，因此可以容忍不良的压缩甚至真正的草率增量。人们要求改进版本系统的主要原因是更直观地完成常见任务，或者支持人们最终需要的更多功能，但在发布之前并不明显。由于版本控制工具往往是单片并且在公司中完全集成，因此切换成本很高，并且可能无法在不破坏现有仓库的情况下支持新功能。