这是我的第一个问题，我还没有在其他地方看到它得到解决。我在一家研究机构工作，所以我们希望能够说出哪个代码版本产生了一组特定的结果。我的问题是我的分析是否正确，如下图所示(请注意，版本节点 ID 仅用于说明目的，并不对应于 SVN、Git 或 Hg 中的实际版本 ID。带有字母的版本号表示未提交的代码状态在 SVN 中，整数版本 ID 代表 SVN 中的提交状态，Git/Hg 框中的所有版本 ID 代表提交代码状态):
示例场景:
假设有两个工作副本“A”和“B”，从修订版 1 开始。
“A”修改函数
foo()中的默认值，生成结果，并 checkin 版本 (repo ver2)。“B”不修改
foo()，而是修改代码的其他部分，使用旧的默认值生成结果，并尝试 checkin 使用过的版本1b.它失败是因为需要更新，但是在 merge 版本 2 和 1b 的过程中，SVN 将丢失版本 1b 在foo()中使用不同默认值的事实。这不会被检测为冲突，因为“A”和“B”没有更改代码的相同部分。版本 3 与版本 1b 不同，因此无法保证可复制性。
我无法使用 TortoiseSVN 在我的本地驱动器中模拟这种情况(我无法创建工作副本，因为 SVN Checkout 错误 — “无法打开 ra_local session 到 URL”)。我确实知道 Git 和 Hg 都会正确处理这种情况并在历史记录中显示版本 1b(如果它已提交并且未使用 rebase 功能)。 (我相信当不涉及任何分支时，rebase 本质上是 SVN 中的正常行为。)
这个分析是否正确？
最佳答案
您的分析原则上是正确的，尽管我反对“版本 1b”命名。版本 1b 在 SVN 领域中永远不存在，因为 1b 是提交前工作目录的状态。
您的工作流程有一个基本问题:当您想要可靠地识别结果时，您将首先必须获取一个标识符，然后生成结果。 checkin ，然后生成。如果这会带来可靠性问题，请 checkin 分支，生成结果，然后 merge 。分支 merge 方法类似于 git 或 hg 等分布式 VCS 软件的工作方式，其中本地存储库是隐式分支，推送是隐式 merge 。
关于git - Subversion 中遗漏版本的可能性(研究环境)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8839778/