我还没有看到一个连续的版本控制系统——它会在你开发代码时保存代码中的更改，而不是等待正式签入。当然，更改会保存为“未签入”，但它们会在您实际进行正式签入之前，将其保存起来以供备份，并供其他人查看。
我还没有看到这个，想知道它或类似的东西是否存在，以及它可能是一个好主意或可能不是一个好主意的原因。
现在程序员将源代码控制视为集成代码包，但为什么不将这些包更小并不断集成呢？
-亚当
Adam Davis
问问题
2201 次
16 回答
13
现在程序员将源代码控制视为集成代码包，但为什么不将这些包更小并不断集成呢？
我会说 DVCS 现在基本上已经在这样做了，不是因为它们是去中心化的，而是因为提交要快得多。使用 git 我提交的频率比使用 SVN 多得多。这也使得提交“块”或特定文件变得简单代码（使用git add -ior git gui），并且通常更专注于跟踪代码行，而不是完整的文件（作为“传统”VCS，如 Subversion）
此外，正如您所说，git 固有的工作方式意味着“更改当然会保存为'未签入'”。当您提交时，更改是本地的，然后您将它们推送到远程机器上命令..您可以在每次保存时提交，然后根据需要将它们重新设置为单个提交。
至于执行“连续版本控制”的工具，您可以使用 shell 脚本非常简单地做到这一点，例如..
while [ 1 ]; do
git add -a && git commit -m "Autocommit at $(date)";
sleep 10;
done
[CACM] 监视特定目录，并将所有更改提交到独立的 Git 存储库。
要使用，只需：
cacm --repo dir_of_git_repo --watch dir_to_watch
我不确定您为什么要这样做。我发现使用 VCS 最有用的事情之一是我更改的内容的差异（自上次提交以来）。似乎有恒定/自动提交只是噪音..
于 2009-03-27T05:07:06.733 回答
11
持续自动保存的工作不是版本系统的任务，而是编辑器的任务。当您在版本系统中看到一个新版本时，它应该代表与其他版本相比的有意义的变化，而不是每个半字词。
于 2009-03-27T04:39:04.027 回答
6
Eclipse 有一个称为“本地历史”的功能，可以做到这一点。它将在保存之间保留源文件的副本。它甚至会为您跟踪已删除的文件夹。它多次救了我的屁股。您可以将本地历史视为仅在本地计算机上发生的低级版本控制。当然，不利的一面是，当您在不同的机器上工作时，您将拥有不同的本地历史。
于 2009-03-27T04:38:20.937 回答
4
我已经看到了一些用于各种 DVCS 的基于 inotify 的插件，但是这些插件只能如此聪明。确实，理想的做法是将存储库存储在写时复制文件系统上，以便将这些频繁的粒度（和不可变）版本的文件保存在 DVCS 之外。
正如其他人所说，我更愿意做出许多小承诺。使用 DVCS，您不必担心破坏主干或主分支，只需在完成后推送 .. 编辑文件时无需担心有毒修订。
在 Linux 上，我使用ext3cow来存储我的 HG/Git 存储库。这给了我你描述的那种功能。遗憾的是，我不知道有任何类似的东西可以在 Linux 之外移植。也许一些疯狂的团队会用 Python 想出一个。
这个问题之前已经出现过好几次了（尽管每次都在不同的背景下），所以肯定需要像 ext3cow （但可移植的）这样的东西。然而，我不希望 DVCS 本身出现这种膨胀，尤其是在大树上。
我认为您确实需要从文件系统而不是 DVCS 提出此要求。
于 2009-03-27T05:26:05.037 回答
3
你的意思是像Subversion 自动版本控制？
免责声明：我并不是说自动版本控制对开发来说是一个好主意，或者我个人会这样做，但这项技术是存在的。
于 2009-03-27T04:25:22.577 回答
3
您不想检查每个更改。您想要签入可以一起工作的原子更改集。您不想将参数添加到方法并保存，将其签入（并运行 CI 构建），然后让构建中断，因为您尚未更新对该方法的调用。
于 2009-03-27T04:29:18.637 回答
2
如果您愿意，您可以使用 git 之类的 DVCS 提交每一行或字符。一般来说，我认为在使用 DVCS 时尽可能多地提交是一个好主意，以便使用 git bisect 等工具轻松查找问题。如果您想要您描述的效果，您可以编写您选择的编辑器以在每次保存时提交...实际上，尽管我认为这有点多。
于 2009-03-27T04:24:52.063 回答
2
有些人会为此设置一个开发分支，并让开发人员在工作时提交他们的更改，然后再将其合并到质量保证级别的分支中。您甚至可以让开发人员在他/她自己的分支中进行重大更改，然后再将这些更改提交并合并到主开发分支中。因此，分支可以解决这个问题。
于 2009-03-27T04:26:30.077 回答
2
我认为 Eclipse 会，或者曾经在每次保存时都会做这样的事情。当我的代码在试图识别错误时最终被破解成碎片时，它救了我几次。
于 2009-03-27T04:27:45.660 回答
2
这是一种不同的方法。几乎每天我都会遇到一些事情停止工作的情况，我不知道为什么。我倒带几分钟并检查已进行了哪些更改以及对哪些文件进行了更改。所以我同意持续版本控制的需要。
同时，您确实不想每天将成千上万的小更改签入到您的存储库中。
好的，这就是你要做的。您同时使用它们，但不要混合使用它们。整个团队都应该使用您的源代码控制，并且您时不时地检查一下。同时你运行一些本地的个人文件版本软件，可以保存每一个小改动，方便你实际使用这些信息。
就是这样。我使用History Explorer是因为我帮助开发了它，但也有其他的。
于 2009-11-08T05:50:25.417 回答
2
您可能对 JetBrains 开发的持续版本控制系统感兴趣。它尚未公开，但我在马尔默 JetBrainsDay 的主题演讲中展示了它的一些功能：http: //new.livestream.com/jetbrains/jetbrainsday1/videos/29348962
于 2013-09-09T06:50:05.923 回答
1
拥有超过几年的 Java 编程经验，我仍然记得（怀念）Visual Age 为开发过程带来的新颖方法。Visual Age 对源代码采用非文件方法。代码存储在关系数据库中。您通常会处理显示单个方法的视图。你也有一个完整的文件视图，但你不会用那么多。
关于版本控制，它会在每次保存时生成一个版本。您可以使用版本号/名称显式检查方法、类/接口、包或整个项目。它还允许在方法级别对您的源进行更细粒度的控制。当我开始使用 Eclipse 时，虽然它继承了 Visual Age 的许多特性，并且今天具有将代码的所有“保存”保存在本地的历史特性，但我不禁感到我退了一步。
于 2009-03-27T05:18:29.767 回答
0
维斯塔怎么样？
于 2010-01-05T14:07:34.797 回答