Best practices for using git with CVS

Question

What are your best practices and tips for using git to interface with a CVS repository?

I'd be tempted to ask the same question for SourceSafe, but I really don't want to ride out the (totally on-target) derision. — T.E.D., Feb 27 '09 at 15:17

score 22 · Accepted Answer · edited May 23 '17 at 12:18

22

I wrote up an answer to a similar question here.

This works suprisingly well when you're forced to continue to push changes into a central CVS repository.

edited May 23 '17 at 12:18

Community

1
1

answered Mar 02 '09 at 19:12

Brian Phillips

12,693
3
29
26

score 11 · Answer 2 · edited Dec 16 '11 at 17:28

11

I've only worked with Git-CVS interactions to demo Git for a friend, but it was very straightforward.

You need to install a current copy of cvsps. Git cvsimport uses this to access CVS history.

We found that, for a large project, inital set-up was much faster by taking a full copy of the CVS repo onto your computer, and doing the git cvsimport locally:

$ rsync rsync://yourprojecthost.com/cvsroot/yourproject/*  
$ mkdir myproject.git  
$ cd myproject.git  
$ git cvsimport -p -x -v -d :local:/path/to/cvsroot/yourproject

Note that the -x after -p is very important. This passes -x to cvsps. For more information please see the cvsps man page.

edited Dec 16 '11 at 17:28

JonMR

586
3
18

answered Feb 27 '09 at 17:12

Paul

16,255
3
33
25

1

I think there's an erroneous / in step 3. – Peter Burns Mar 01 '09 at 03:22
2

@PeterBurns: That there is... It should be `git cvsimport -p -x -v -d :local:/path/to/cvsroot yourproject` – Archenoth Jun 04 '14 at 15:39

score 8 · Answer 3 · answered Jul 02 '10 at 13:59

8

I wrote up the details of my own workflow for remote CVS, local Git

answered Jul 02 '10 at 13:59

Kristopher Johnson

81,409
55
245
302

1

you "don't trust" `cvsimport` for unspecified reasons (there are also other tools to do this), so you promote throwing out all previous revision information? That's a terrible solution. – Brad Mace May 13 '14 at 20:31
What's so terrible about it? If I'm pushing my changes back into CVS, then no revision history is being "thrown out". And if I do want to see revision history, I can always use CVS commands to do that. – Kristopher Johnson May 14 '14 at 14:53
What benefit do you get by adding `CVS` to `.gitignore`, instead of committing it to git? Doesn't it make your git repository incomplete? See http://stackoverflow.com/a/37585092/1122270 and http://stackoverflow.com/q/37585385/1122270 for what I mean. – cnst Jun 05 '16 at 21:56

score 1 · Answer 4 · answered Jun 16 '09 at 10:53

Slightly meta-answer. If you are forced to use git 'guerilla style', i.e. your company is stuck using cvs for the version control and you use git on your workstation to make life easier, you might consider doing something like this;

CVS=realCvsPath
# commit to the git first
if ($ARGV[0] && $ARGV[0] eq "commit")
{
system 'git commit -a';
}

# execute the appropriate cvs program
# ===================================
exec "$CVS", @ARGV

Calling this file 'cvs' and including it the path before the real CVS command. Otherwise you can have git commits older than the cvs ones, which isn't that useful...

score 1 · Answer 5 · answered Jun 02 '16 at 07:16

If the upstream is 100% in CVS (e.g., OpenBSD, or many of its subprojects like mdocml or ports-readmes), and especially if it's as rusty as the OpenBSD CVS tree is (e.g., occasionally even having history rewrite), I find it quite useful to simply commit the underlying CVS/{Entries,Repository,Root} files directly into my git repository.

This makes it very easy to not have to have multiple independent workspaces, make it possible to checkout with git on any machine, and then cvs up in place, or cvs diff to generate correct CVS patches for mailing to the git-less maintainers upstream.

Best practices for using git with CVS

5 Answers5

Linked

Related