Copyright © 2013 Keith Packard, Bart Massey and Eric Raymond
You may want to look at https://gitlab.com/esr/cvs-fast-export,
which contains Eric Raymond's currently-maintained version of
cvs-fast-export. Probably this GitHub repo should be backed off
to before Eric's changes, when it was the latest known version
This is the former canonical repo for
git cvs-fast-export, formerly
parsecvs. This tool does what
its new name implies: exports
cvs repositories in a format
This tool is currently being maintained by Eric Raymond, who
has rewritten parts of it to support current
git in a more
Below are a bunch of stale notes and old versions of README material, preserved for historical reasons. You might just want to ignore them.
Note: The standalone code currently finally did not run
properly in at least some instances. It is suspected that
this was due to changes in
libgit that hadn't been tracked
parsecvs code. Fortunately, Eric Raymond's changes to
git fast-import mooted that problem.
parsecvs formerly required a copy of libgit
and its header files to be on your system. For my Debian
system, that meant pulling the Git source and building
it. The Makefile variable GITDIR should be aimed at an
appropriate location if you ever try to build old code.
This is the current canonical repo for
parsecvs. It merges
three different Git repos:
- The latest copy I could find of Keith Packard's original repo.
- Kristian Hogsberg's repo from freedesktop.org. This was a fast-forward merge.
- Ivan Zakharyaschev's repo from gitorious.org. This had two merge conflicts, which I hope I resolved in sensible ways.
I will commit (no pun intended) to maintaining this version as the "one true branch" on github going forward. I will not actively look for patches, but if people send them to me I will look at getting them in. Further, if it breaks for me, I will fix it and push my patches here.
I was in on the original design of
parsecvs, and have gotten
a lot of use out of it over the years. Hopefully it will
remain useful for years to come.
Here is the original
parsecvs README. Much of this
information is out-of-date as of 2013, but I preserve it in
case it might be useful.
Parsecvs firstname.lastname@example.org April, 2006 This directory contains code which can directly read RCS ,v files and generate a git-style rev-list structure from them. Revision lists can be merged together to produce a composite revision history for an arbitrary collection of files. Optional behaviors are controlled by editing the source and recompiling. If arguments are supplied, `parsecvs` assumes they're all ,v files and reads them in. If no arguments are supplied, `parsecvs` reads filenames from stdin, one per line. Working features: Attic support. Files found in the Attic are not dealt with specially at all; they should be renamed in the output, and the terminal revision noted so that they don't appear in later revision. I think fixing this will be reasonably straightforward. Disjoint branch resolution. Branches occurring in a subset of the files are not correctly resolved; instead, an entirely disjoint history will be created containing the branch revisions and all parents back to the root. I'm not sure how to fix this; it seems to implicitly assume there will be only a single place to attach as branch parent, which may not be the case. In any case, the right revision will have a superset of the revisions present in the original branch parent; perhaps that will suffice. Connection to git. As mentioned above, the code doesn't actually connect to git yet, so while it can generate lovely graphs, it won't do anything useful. I think this is reasonably straight forward as well; we've got a revision history containing the necessary version of every file at each point in time. This could either be done by emitting git commands and sending them to a shell, or by linking against a git library and doing everything internally. Author translation. Just as git cvsimport does. Missing features: Reasonable command line syntax. The current lack of command line parsing should be fixed to align with the usual git tools. Testing. I'm sure there are plenty of additional bugs to be found; I've tested with valgrind and eliminated memory leaks and other errors.