The cvs_sync branch is an experimental facility to help users work with ["MonotoneAndCVS"]

For the newest rewrite see CvsSync.

You may want to not stress cvssync to the full extent. It definitely has problems when the time jumps (no I mean not summer vs. winter time) because then the simplistic and easy to use map which sorts revisions by time (to construct changesets) does not sort correctly concerning heritage . And it stresses the CVS server with the initial pull [--since is much much nicer to the server, a full log over the project's lifetime and constructing diffs between old revisions of a file is a killer].

Try cvs_takeover (an unmodified tree saves you worries elsewhere! *) and continue to work from there. Merging, updating, committing etc. really work nice and the server is not charged that much this way. Most people (including me) do not need full history.

Also, sorry, cvssync does not handle side branches, yet. I yet failed to find a decent command which gives me the exact branch-off-point of the branch (revision number inspection seems the way to go).

Oh, and -ko saves you much headache when you have to resync with the cvs server.

If anything goes terribly wrong the most efficient way to resync is:

• check the module with CVS out into an empty directory
• change into that directory
• monotone --db foo.db --branch foobranch cvs_takeover [foomodule]
• monotone merge

*) cvssync inserts empty dummy files as the initial state which give a MD5 sum error on update and also a warning if it gets to know the correct content lateron.