连续版本控制

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

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

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

-亚当

1> dbr..：

---

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

我会说DVCS现在基本上已经这样做了,不是因为它们是分散的,而是因为提交速度要快得多...使用git我比SVN提交的频率更高.它也使得提交"块"或特定提交变得简单代码(使用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"文本编辑器有一个有趣的功能,它通过分支可视化撤消历史记录.有一个博客文章,上面有截图.

---

"似乎持续/自动提交只会是噪音......" - 同意了!没有任何有用的信息可以从数百个微不足道的,破碎的提交中收集到.Adam,您可能应该寻找Dropbox而不是backup-vcs组合的备份解决方案.

---

我不同意"不断提交"始终是总噪音.对于正常软件开发过程中的典型源控制结构,这可能是噪声.但是,除了典型的软件开发周期之外,还有更多的用例.尽量不要如此快速地解雇解决方案,因为它不适用于您自己的工作流程.在没有理解的情况下解雇是聪明人之间常见的谬误.这也是一种傲慢和缺乏同情心.所以在解雇别人的想法之前要小心谨慎.

2> Svante..：

---

持续自动保存的工作不是版本系统的任务,而是编辑器的任务.当您在版本系统中看到新版本时,它应该代表其他版本的有意义的更改,而不是每个半角化的单词.

3> Luke..：

---

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

4> linjunhalida..：

---

你可以使用分销版本控制系统,如bazaar,git,Mercurial.然后你可以在本地提交.