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
of parsecvs.
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
suitable for git fast-import.
This tool is currently being maintained by Eric Raymond, who
has rewritten parts of it to support current git in a more
sensible way.
Below are a bunch of stale notes and old versions of README material, preserved for historical reasons. You might just want to ignore them.
Bart Massey
[email protected]
2013-01-14
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
in the parsecvs code. Fortunately, Eric Raymond's changes to
support git fast-import mooted that problem.
Note: Building 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.
Bart Massey
[email protected]
2011-02-15
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
[email protected]
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.