连续版本控制

现在程序员认为源代码控制就是集成代码包,但是为什么不让这些包变小并持续集成呢?

我想说的是,DVC现在已经基本上做到了这一点,不是因为他们分散了,而是因为提交要快得多。。使用git时,我的提交频率远远高于使用SVN时。。它还使得提交“块”或特定代码(使用 git add -i 或 git gui

此外,git固有的工作方式意味着,正如您所说,“更改当然会保存为‘未签入’。”。。提交时,更改是本地的,然后使用单独的命令将其推送到远程计算机。。您可以在每次保存时提交,然后根据需要将它们重新设置为单个提交。

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

此外, "e" Text Editor 有一个有趣的特性,它可视化了撤销历史,并带有分支。有一个 blog-post on it

持续自动保存的工作不是版本系统的任务,而是编辑器的任务。当您在版本系统中看到一个新版本时,它应该表示对其他版本的有意义的更改,而不是每个半类型字。

您可以使用分布式版本控制系统,如 bazaar git , Mercurial . 然后您可以在本地提交。

我见过一些用于各种DVC的基于inotify的插件,但是这些插件只能是非常智能的。实际上,理想的做法是将存储库存储在一个“写时拷贝”文件系统上,以便将这些频繁的细粒度(且不可变)文件版本保存在DVC之外。

正如其他人所说,我更愿意做出许多小承诺。使用DVCS,您不必担心主干或主分支断开,只需在完成后再推。。编辑文件时不必担心有毒修订。

在Linux上,我使用 ext3cow 存储我的HG/Git存储库。这给了我你描述的那种功能。遗憾的是,我不知道有任何类似的东西可以移植到Linux之外。也许某个疯狂的团队会用Python开发出一个。

我认为你真的需要从文件系统而不是DVCS中获取这些信息。

每一个

你是说什么 Subversion autoversioning ?

免责声明:我不是说自动版本控制对于开发来说是一个好主意,也不是说我个人会这么做,但这项技术是存在的。

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

我认为Eclipse在每次保存时都会这样做,或者曾经这样做过。当我的代码在试图识别一个bug时被黑客攻击成碎片时,它救了我几次。

这里有一种不同的方法。 几乎每天我都会遇到这样的情况:有些东西停止工作了,我不知道为什么。我倒带几分钟,检查做了哪些更改以及对哪些文件进行了更改。因此,我同意continouos版本控制的必要性。

同时,您确实不想每天将成千上万的小更改签入存储库。

好的,这就是你要做的。两者都用,但不要混用。您的源代码管理应该被整个团队使用,并且您应该不时地进行检查。同时,您运行一些本地个人文件版本软件,保存每一个小更改,并使您能够轻松地实际使用信息。

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

http://new.livestream.com/jetbrains/jetbrainsday1/videos/29348962

像 Dan mentioned ,IBM Visual Age IDE保留了您保存的源代码文件的每个版本。然而,这种方法并不局限于IDE;这个 DEC VMS 操作系统采用了与之类似的方法 versioned file system

这两种方法都不完全符合我们今天所知道的版本控制,因为两者都缺乏分支(或者,就这一点而言,任何专门为方便多人处理同一源文件而设计的特性)。但是,它们都用于防止人为错误的备份,这对我来说是版本控制最有用的方面。

有着几年以上的Java编程经验,我仍然记得(怀旧地)视觉时代给开发过程带来的新方法。VisualAge对源代码采用非文件方式。代码存储在关系数据库中。您通常使用显示单个方法的视图。你也有一个完整的文件视图,但是你不会经常使用它。

合理的 ClearCase 有一个 动态视图

正如你所预料的那样,用这种方式工作是有代价的,就像 Si 我的回答 above ,这不是一个建议。。。

http://www.vestasys.org/