cvs2git: non-deterministic conversion (force push) if multi-branch commits in CVS

[mirabilos]

Originally reported in Debian.

Package: cvs2svn Version: 2.4.0-4 Severity: important

I regularily convert some CVS repositories of mine to push-only git mirrors. Today I noticed a problem for the second time: a push was rejected because it needs a force.

I’m attaching:

• the diff between “git log” output of the previous conversion and the next one

• the current ,v file of where I think the problem is

• a previous ,v file which I think matches the before state

Console output of pushing to my local mirror:

To /git/jupp

• 901e728...a5dddf3 joe-2_8-msdos -> joe-2_8-msdos (forced update)
• 0d0c308...77c5cb7 jupprc-for-joe-3_7 -> jupprc-for-joe-3_7 (forced update) 87ad7f7..ff21092 master -> master
• 901e728...1486d94 joe-2_8jupp3 -> joe-2_8jupp3 (forced update)
• [new branch] jupprc-for-joe-4_4 -> jupprc-for-joe-4_4

The remote mirror then rejected it. I did commit the jupprc file in several branches simultaneously, but, of course, the “second” part of the timestamp differs (this happens when your CVS server is a Pentium 233 MMX ☺).

-- System Information: Debian Release: buster/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64

Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init)

Versions of packages cvs2svn depends on: ii python 2.7.13-2 ii rcs 5.9.4-3 ii subversion 1.9.6-1+b1

Versions of packages cvs2svn recommends: ii mime-support 3.60

Versions of packages cvs2svn suggests: pn bzr ii cvs 2:1.12.13+real-23 ii git [git-core] 1:2.14.0-1

-- no debconf information

#871734.zip

[mhagger]

cvs2svn/cvs2git does not support incremental conversion. The fact that it "usually" works can be misleading. No information is remembered from one conversion attempt to the next, and since cvs2svn has to rely on a lot of heuristics to infer which CVS file-wise commits should be considered part of the same Subversion/Git repository-wide commit, those decisions might be made differently from one run to the next.

If you can find some trivial and easy-to-fix reason that the outputs are different, it might be worth fixing to make this work more often. (In that case, feel free to reopen this issue and include a more detailed analysis of the problem.) But making it work all the time by design would be a very significant undertaking that I definitely don't plan to work on.

[mirabilos]

Michael Haggerty dixit:

No information is remembered from one conversion attempt to the next,

This is not about keeping state but about deterministic conversion, so, if it did a heuristic/decision one way, it should always do it that way.

If you can find some trivial and easy-to-fix reason that the outputs

In the stated case of…

I did commit the jupprc file in several branches simultaneously

… I’d suggest introducing a stable ordering (timestamp including seconds, then ASCIIbetically from pathnames in the repository).

bye, //mirabilos --

you introduced a merge commit │ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahhhhhh