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.