Is git with cvs faster than cvs alone?

Question

My team works on a project in cvs containing about 20,000 Java files. Because of the number of files, it takes a while to do a cvs update. I typically keep about 5 copies of the entire tree checked out, to make it easy to check in different requests without worrying about which files were modified for each. It's a real pain to keep all 5 trees up to date and in sync with each other.

I've read that it's fairly easy to use git locally with a remote cvs server, and that git is fast. Will git significantly speed up the updating of my local trees?

I realize the lower bound is the time to do one cvs update. But I'm thinking that once the first tree is up to date, it might possible to quickly sync the other 4 with the first, rather than to do 4 more cvs update commands. Do I understand git correctly?

Epochal

Answer 1

I use Git as a Subversion client on a large project (on the order of 10k files). Git is fast, really fast. It's so fast that I only keep one working clone, and switch between feature branches within that same clone. Like you, when I used Subversion I would have two or three similar checkouts and would switch between them regularly as I had multiple things in progress simultaneously. It got to be pretty confusing sometimes. With Git's features like lightweight branches, the stash, and "git add -p", I find that I no longer need multiple checkouts. I can do everything in one directory, and not worry as much about losing changes that I either forgot about or accidentally overwrote.

I haven't used Git with CVS, but if its integration is anything like git-svn then it's going to be no problem.

Consignee

The integration of git as a CVS client is poor compared to SVN (at least it used to be, the projects I follwed that used CVS have migrated away from it, so I don't have recent experience). There is a CVS server running as a frontend to a git repository in the sources, but I've always considered that just the demented output of a sick mind, so...). – Rowden

Answer 2

We do something similar at work. We basically use the master branch in git as a single, updated CVS version of the code; we don't do any development there, just CVS updates. Then, all of our development projects happen on feature branches that we rebase. When we do CVS updates on the master branch we commit those changes to master and then rebase our other development branches against master.

It's not ideal -- it makes sharing branches with other people difficult. But, we can manage several development projects at once and do branches, merges, and diffs against them easily. And, we only interact with CVS on the one master branch, as needed.

Duomo

Sounds pretty good. Is the rebase step faster than the cvs up? – Epochal

Yeah, it's a ton faster because it's all local. It basically generates diffs from your branch and applies them to the new head of the branch. – Duomo

@CraigP.Motlin, such operations in git tend to be almost instantaneous. Checking out the current version from CVS is slow (perhaps slower than native CVS). Whay is a true bear is the first checkout (either CVS or SVN), it thas to suck down all the revisions. That can easily take literally days for a largeish repository. The process is rather fragile, in that it loses connection to the server and has to be restarted (and whan it hasn't finished, nothing is checked out; don't panic, continue). Once you have one copy of the CVS repository cloned, you can just copy the directory around. – Rowden