Skip to content

Revert unsound optimization in merge_branches

See github issue 8 - Exporting an RCS archive with commitids does not coalesce changesets by commitid.

First commit reverts 13968875. This commit would mean candidate commits would only be considered part of a clique if they were within a time threshold of each other, regardless of whether they have the sams commitids.

Note you still have to be a candidate commit to be considered. I could imagine a situation where peeling a different commit would lead to more files with the same commitid as the current leader becoming candidates.

When I run make check, I get a small diff. I'm not sure if this is good or bad. As it involves a commitid it may be understandable that the behaviour has changed:

cvsconvert: processing t9605.testrepo/module
== Reductions ==
  README,v
--- reductions/README,v.reduced 2017-03-18 23:06:33.000113900 +0000
+++ -   2017-03-19 12:47:19.136634100 +0000
@@ -6,10 +6,9 @@


 1.1
-date   2016.02.28.19.42.53;    author esr;     state Exp;
+date   2017.03.18.23.04.38;    author loz;     state Exp;
 branches;
 next   ;
-commitid       10056D34DBD13DD1D34;


 desc
  added-imported.txt,v
  imported-anonymously.txt,v
  imported-modified.txt,v
  imported-modified-imported.txt,v
  imported-once.txt,v
  imported-twice.txt,v
No diff output is good news.

Second commit is just some whitespace fixup.

Merge request reports