Question

我还没有看到一个连续版本控制系统 - 一个可以在开发代码时保存代码更改的系统，而不是等待正式签入。这些更改将保存为“未签入”当然，但是，在您实际办理正式登记手续之前，他们会被保存起来进行备份和查看。

我还没有看到这个，并想知道它是否存在，或者它是否存在，以及为什么它可能会或可能不是一个好主意。

现在程序员认为源代码控制是整合代码包，但为什么不把这些数据包缩小并连续集成呢？

- 亚当

Answer 1

现在程序员认为源代码控制是整合代码包，但为什么不把这些数据包缩小并连续集成呢？

我想说DVCS现在基本上已经这样做了，不是因为它们是分散的，而是因为提交速度要快得多......使用git我比SVN更经常地提交..它也使得提交“chunk”变得简单“或特定的代码（使用git add -i或git gui），通常更侧重于跟踪代码行，而不是完整的文件（如”Subversion“这样的”传统“VCS）

此外，正如你所说，git固有的工作方式意味着“更改将被保存为'当然未选中'”。当你提交时，更改是本地的，然后你将它们推送到远程机器使用单独的命令..您可以在每次保存时提交，然后根据需要将它们重新绑定到单个提交中。

对于执行“连续版本控制”的工具，您可以使用shell脚本完成此操作，例如..

while [ 1 ]; do
   git add -a && git commit -m "Autocommit at $(date)";
   sleep 10;
done

有一个脚本CACM（github），它可以做类似的事情

[CACM]监视特定目录，并将所有更改提交给独立的Git存储库。

仅使用：

cacm --repo dir_of_git_repo --watch dir_to_watch

我不确定你为什么要这样做..我发现使用VCS最有用的一点是我改变了（自上次提交以来）的差异。似乎持续/自动提交只会是噪音..

此外，"e" Text Editor有一个有趣的功能，它通过分支可视化撤消历史记录。有blog-post on it屏幕截图。

Answer 2

持续自动保存的工作不是版本系统的任务，而是编辑器的任务。当你在版本系统中看到一个新版本时，它应该代表其他版本的一个有意义的变化，而不是每个半开的单词。

Answer 3

Eclipse有一个名为“本地历史记录”的功能。它将在保存之间保留源文件的副本。它甚至可以为您跟踪已删除的文件夹。它拯救了我的屁股多次。您可以将本地历史记录视为仅在本地计算机上发生的低级版本控制。当然，当您在不同的机器上工作时，您将拥有不同的本地历史。

Answer 4

您可以使用分发版本控制系统，例如bazaar，git，Mercurial。然后你可以在本地提交。

Answer 5

我已经看到一些基于inotify的插件用于各种DVCS，但是那些只能是如此聪明。实际上，理想的做法是将存储库存储在写时复制文件系统上，以便这些频繁的粒度（和不可变）版本的文件保留在DVCS之外。

像其他人所说的那样，我更愿意做出许多小小的承诺。使用DVCS，您不必担心打破主干或主分支，只有在完成后才能推送。在编辑文件时无需担心有毒修订。

在Linux上，我使用ext3cow来存储我的HG / Git存储库。这给了我你描述的那种功能。可悲的是，我不知道这样的事情是超出便携的Linux。也许一些疯狂的团队会在Python中提出一个。

这个问题之前已经出现了好几次（虽然每个都在不同的背景下），所以对ext3cow（但是便携式）之类的东西的需求肯定是显而易见的。然而，我不希望DVCS本身出现这种膨胀，特别是在巨大的树木上。

我认为你真的需要从文件系统中询问，而不是DVCS。

Answer 6

你的意思是Subversion autoversioning？

免责声明：我不是说autoversioning对于开发是一个好主意，或者我个人会这样做，但技术存在。

Answer 7

您不想签入每次更改。您想要检查可以一起工作的原子变更集。您不希望向方法添加参数并保存，将其签入（以及CI构建运行），然后进行构建中断，因为您尚未更新对方法的调用。

Answer 8

如果你愿意，你可以使用像git这样的DVCS提交每一行或字符。一般来说，我认为在使用DVCS时尽可能经常地提交，以便使用git bisect等工具轻松解决问题是一个好主意。如果你想要你描述的效果，你可以编写你选择的编辑器来编写每个保存的代码...在实践中我会认为这会有点多。

Answer 9

有些人会为此目的设置一个开发分支，并让开发人员在将其更改为质量保证级别分支之前提交他们的更改。在提交并将这些更改合并到主开发分支之前，您甚至可以让开发人员在他/她自己的分支中进行重大更改。因此，分支可以解决这个问题。

Answer 10

我认为Eclipse在每次保存时都会这样做或曾经做过类似的事情。当我的代码在尝试识别错误时最终被黑客攻击时，它为我节省了几次。

Answer 11

这是一种不同的方法。几乎每天我都会遇到停止工作的情况，我不知道为什么。我倒了几分钟，检查了哪些更改以及哪些文件。所以我同意对Continouos版本控制的需求。

与此同时，您确实不想每天将数以千计的小更改检入存储库。

好的，这就是你要做的。你使用两者但不要混合它们。您的源代码控制应该由整个团队使用，并且您不时地检查它。与此同时，您运行一些本地个人文件版本软件，可以保存每一个小的更改，并使您可以轻松地实际使用这些信息。

就是这样。我使用History Explorer，因为我帮助开发它，但也有其他人。

Answer 12

您可能对JetBrains开发的连续版本控制系统感兴趣。它还没有公开，但我在马尔默的JetBrainsDay的主题演讲中展示了它的一些特点：http://new.livestream.com/jetbrains/jetbrainsday1/videos/29348962

Answer 13

拥有超过几年的Java编程经验，我仍然记得（怀旧）Visual Age为开发过程带来的新颖方法。 Visual Age对源代码采用非文件方法。代码存储在关系数据库中。您通常会处理显示单个方法的视图。你也有一个完整的文件视图，但你不会那么用。

关于版本控制，它会生成每个保存的版本。您可以使用版本号/名称显式检查方法，类/接口，包或整个项目。它还允许在方法级别对源进行更精细的控制。一旦我开始使用Eclipse，虽然它继承了Visual Age的许多功能，但今天有一个历史记录功能可以在本地保存代码的所有“保存”，我不禁觉得我后退了一步。

Answer 14

作为Dan mentioned，IBM Visual Age IDE保存了您保存的源代码文件的每个版本。然而，这种方法不限于IDE; DEC VMS操作系统采用与versioned file system类似的方法。在VMS中，每个文件的全名都包含一个版本号，每次保存文件时，都会创建一个版本号比以前最高的版本高1的新副本。

这两种方法都不像我们今天所知的那样完全匹配版本控制，因为两者都缺乏分支（或者，就此而言，任何特别设计的功能都是为了方便多个人在同一个源文件上工作）。但是，它们都用于备份人为错误，这对我来说是版本控制最有用的方面。

Answer 15

Rational ClearCase具有动态视图的概念。在Windows上，您的开发视图显示为映射驱动器，但是一旦您点击保存，您的代码更改将存储在服务器端。那是你在找什么？

正如您所期望的那样，通过这种方式进行权衡，就像Si的回答above一样，这不是建议......

Answer 16

VESTA怎么样？

http://www.vestasys.org/

连续版本控制

16 个答案: