Best practices for using git with CVS

Question

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

Gerrard

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. – Fascinator

Answer 1

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.

Aleman

Answer 2

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.

Abstergent

I think there's an erroneous / in step 3. – Chemist

@PeterBurns: That there is... It should be git cvsimport -p -x -v -d :local:/path/to/cvsroot yourproject – Fleer

Answer 3

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

Mort

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. – Howard

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. – Mort

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 https://mcmap.net/q/12535/-best-practices-for-using-git-with-cvs and https://mcmap.net/q/22412/-what-39-s-the-best-practice-of-going-git-when-upstream-is-100-cvs/1122270 for what I mean. – Unterwalden

Answer 4

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...

Transformer

Answer 5

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.

Unterwalden