logo标签列表

持续版本控制

version-controlcontinuous-integrationcollaboration
9
我还没有见过一种连续的版本控制系统 - 一种可以在您开发代码时保存更改而不是等待官方检查的系统。当然，这些更改将被保存为“未检入”，但它们将被备份和供他人查看，直到您进行官方检入之前。
我还没有见过这种系统，想知道它是否存在以及类似的系统，以及它可能或不可能是一个好主意的原因。
现在，程序员认为源代码控制是整合代码包，但为什么不将这些包变得更小并持续集成呢？
-Adam
16个回答
13
现在程序员认为源代码控制是集成代码包，但为什么不把这些包变得更小，并进行持续集成呢？
我会说DVCS现在已经基本上实现了这一点，不是因为他们是分散式的，而是因为提交速度更快。使用Git时，我比使用SVN更频繁地提交。它还可以轻松地提交“块”或特定的代码（使用git add -i或git gui），并且通常更专注于跟踪代码行，而不是完整文件（如“传统”的VCS，如Subversion）。
此外，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

我不确定为什么要这样做... 我发现使用版本控制系统中最有用的一件事就是查看我所做的更改差异（自上次提交以来）。似乎经常性/自动提交只会产生噪音。

此外，"e" 文本编辑器 有一个有趣的功能，它可以可视化撤销历史记录并生成分支。 这里有一个博客文章附有截图。

2
“看起来，持续/自动提交只会产生噪音…” - 同意！从数百个微小、破碎的提交中你无法获得任何有用的信息。Adam，你应该考虑寻找像Dropbox这样的备份解决方案，而不是备份-vcs组合。 - Ricket
2
我不同意“常量提交”总是完全无用的说法。对于正常软件开发流程中的典型源代码控制结构，这可能是噪音。然而，除了典型的软件开发周期之外，还有许多其他用例。尝试不要因为一个解决方案在你自己的工作流中行不通就轻易地将其排除。不理解就排斥是聪明人常见的谬论。这也是一种傲慢和缺乏同理心的表现。所以，在排除别人的想法之前，请小心谨慎。 - JD Long
11

常规自动保存的工作不应该由版本系统来完成，而是应该由编辑器来处理。当您在版本系统中看到一个新版本时，它应该代表与其他版本有意义的更改，而不是每个打字都保存。

取决于你如何处理版本控制。每次保存时生成版本正是Visual Age所做的。你会为你认为重要的版本命名... - Dan
我认为这是正在使用的编辑器的“撤销/重做”系统的任务。我同意Svante的看法，它应该是版本控制系统的不同功能层，表示对代码进行了某种“原子”更改。 - thomasrutter
它应该代表与其他版本有意义的变化，而不是每个半打字的单词。你能解释一下为什么这样做是正确的吗？你没有支持你的说法，这是一个非常有趣的观点。为什么不把这个任务交给版本控制系统呢？ - Adam Davis
请阅读我的回答链接（关于使用WebDAV进行SVN自动版本控制），这解释了为什么有些人可能需要它。然而，那些人可能不是开发人员 :) - si618
6

Eclipse有一个名为“本地历史记录”的功能，可以做到这一点。它会在保存之间保留源文件的副本。它甚至会帮助您跟踪已删除的文件夹。这个功能曾经帮了我很多次忙。您可以将本地历史记录视为仅在本地机器上发生的低级版本控制。当然，缺点是当您在不同的机器上工作时，您将拥有不同的本地历史记录。

5
你可以使用分布式版本控制系统，例如bazaar, git和Mercurial。然后你可以在本地提交。
+1 这个是答案。Git 允许你提交所有这些小片段，并且在主要内容提交之前，你可以从你的存储库与他人分享。 - eglasius
4
我见过一些基于inotify的各种DVCS插件，但是它们只能做到这样而已。实际上，理想的做法是将存储库存储在写时复制文件系统上，以便这些频繁的、细粒度的（和不可变的）文件版本保持在DVCS之外。
像其他人所说，我更喜欢进行许多小的提交。使用DVCS，您不必担心打破主干或主分支，只需在完成后推送即可...编辑文件时不用担心有毒修订。
在Linux上，我使用ext3cow来存储我的HG/Git存储库。这为我提供了您描述的功能。遗憾的是，我不知道是否有类似于Python的便携式解决方案。
这个问题以前已经出现过几次（虽然每次都是在不同的上下文中），因此显然需要类似于ext3cow（但是便携式）的东西。然而，我不希望在DVCS本身中包含那种膨胀的内容，特别是对于庞大的树。
我认为您真正需要从文件系统而不是DVCS中寻求此功能。
3
你是指类似于Subversion自动版本控制这样的东西吗？
免责声明：我并不是在说自动版本控制对开发来说是一个好主意，或者我个人会这样做，但是这项技术是存在的。
3

您不希望检查每个更改。您希望检查可以一起使用的原子更改集。您不希望向方法添加参数并保存，然后将其检入（并运行CI构建），然后由于尚未更新对该方法的调用而导致构建中断。

如前所述，在实际签入之间签入的任何内容都必须沿着试验或其他分支进行，而不是主分支。一些版本控制系统具有此类用法的功能，您不必完全签入某个文件，但要让版本控制系统知道并存储它。 - Adam Davis
2
这里提供一种不同的方法。 几乎每天我都会遇到某些停止工作的情况，但我不知道原因。我会倒回几分钟，检查做了哪些更改和对哪些文件进行了更改。所以我同意需要持续版本控制。
同时，确实不希望每天将数千个小更改提交到代码库中。
好的，这就是你要做的。你同时使用两者，但不混合使用。整个团队应该使用源代码控制，并且你应该定期向其签入。同时，你可以运行一些本地个人文件版本软件，它会保存每个小更改并使你可以轻松使用信息。
就这样。我使用History Explorer，因为我参与了其中的开发，但也有其他选择。
2
2
你可以使用像Git这样的分布式版本控制系统提交每一行或字符。通常情况下，当使用DVCS时，尽可能频繁地提交更改是个好主意，这样可方便使用git bisect等工具来查找问题。如果你想要实现所描述的效果，你可以编写脚本使你选择的编辑器在每次保存时自动提交...不过我认为这样做有些过头了。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接