1

We are using CVS as source repository. The server is far away from local working place and very slow. The repository size is also large (2GB approx.) and it takes us almost 12 hours to do a fresh checkout.

We'd like to setup a GIT server as a proxy to CVS so that we can working with GIT server in day time and let it sync with CVS server during night. Is there any good practice for this?

Basic requrements are:

  1. Branch support
  2. Syncing between GIT and CVS should be bi-direction, and commits to GIT by different users should be synced to CVS one-to-one with corresponding user

Thanks. BTW, I've read this thread How to export revision history from mercurial or git to cvs? but it does not help much.

Community
  • 1
  • 1
stid.smth
  • 1,525
  • 2
  • 11
  • 11
  • 1
    Are you sure decommissioning your CVS repository isn't an option? Once you are using a client with some notion of "changesets" (not how `git` works, but close enough), file renames, and merge tracking I don't think you're going to want to tolerate CVS any longer. At the very least, `cvs2svn` could give you a _better_ SVN repository out of your existing CVS data than CVS can give you now. – sarnold Jun 27 '11 at 01:38
  • 1
    Any reason you need to keep CVS around? – Abe Voelker Jun 27 '11 at 01:42
  • We ended up migrating our CVS repository to subversion and from subversion to git as that gave the best results for us in terms of keeping history and branches. We then worked with that for a while and decided that it had grown too big to be useful (lots of legacy jars and images) so we trimmed out the development branches and made the old repository read/only (in case you had to go and look something up) again while keeping history. It has worked very nicely. – Thorbjørn Ravn Andersen Mar 18 '14 at 09:30

1 Answers1

1

You can set up a git repo that exists on the end that the CVS repo is. You don't need to import all the history. It's not going to be worth the pain. You should be able to push and pull to and from the remote git repo. Then just commit from the remote git repo into the cvs one. This should avoid a lot of the transmission delays as git does a wonderful job on just shipping new files and having that compressed.

Eventually everyone will see the remote git repo as the one giving true value and you'll be able to drop the cvs ball-and-chain.

Hope this helps.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141