Tips on upgrading CVS to git/hg?

We still use CVS, I use git and hg for my personal use though I'm still a novice at both, but I realize they're much more modern and better, faster, distributed, etc.

It's just everyone is so accustomed to CVS that I feel a whole slew of issues could arise if I were to be the one that recommended and actually did the upgrading/porting/transitioning of our current CVS server to git or hg.

Has anyone actually done this, recently? Could you offer any insight or tips in terms of influencing people to use git/hg, and just generic tips on the actual updating/transit开发者_如何转开发ioning if it were to take place? Are there common issues I should be aware of just in general?

I've just come across this question, and I've worked somewhere that tried to make this transition. It didn't work.

I don't say this to discourage anyone, but to highlight issues that people may come across.

The problems were numerous, but basically they all came down to the fact that people didn't see the problems with CVS. Amazing I know, but it had been there for so long. They'd become used to the idiosyncrasies and were now blind to the issues it was causing them. Bring in something new and they couldn't understand why things needed to be done in a different way.

One of the biggest ones was the notion of an atomic commit. People couldn't get past the fact that revisions were now a state of the whole project tree, rather than a state of a file. So checking in a change in file A whilst there were unfinished changes in file B suddenly became a platform for a rant against the version control system.

• Waaaaaaa! Why do I have to check all the files in?
• Waaaaaaa! Why haven't I got the changes I just pulled?
• Waaaaaaa! What do you mean I have to merge? Why do I always have to merge?
• Waaaaaaa! Why can't it just use a normal revision number?

When you're stumbling at that level, you can forget trying to introduce "advanced" concepts like committing more frequently than when you want to release code, or sharing changes between users.

The death blow was the fact that they'd taken a huge project, with hundreds of developers, and about 70 sub-projects, and put it in one centralised repository. This meant that this central repo was getting 1-2 hundred commits a day. Everybody was always pushing every commit to it (because cvs commit == commit; push right?). It also got large automated build and test reports committed into it. Put it all together and it got to the stage that you couldn't do a pull;merge;(no testing);push without needing to re-pull;merge because you were out of date. Someone had pushed something whilst you were waiting for that big pull to finish.

... and because people weren't testing their merges, breakages happened.

• Waaaaaaa! Damn thing merged it wrong!

Oh, and one guy merged about 10 branches together because he knew he had to merge, but he didn't understand what to merge or why.

The result.... They bought Perforce.

Reason: It came with a support contract, so there was someone to [blame / fix it] when it went wrong.

So:

• Educate people about the problems CVS is causing them. Normally it's down to not being able to identify which versions of files work together without tagging, which requires everyone to stop work. I'm sure you can find more.
• Educate people why DVCSs work the way they do. Show them what the power means they can do. Make them want it.
• Make sure they know what not to do!
• Don't just change systems and make everyone learn on the job. It just builds resentment and all they do is try to do what worked on the old system. It's not pretty.
• Don't put every project into one single repo. Centralised VCSs handle it far better than DVCSs and you'll lose every time.

If you can, bring it in slow on a project with a small number of developers. Educate them; set it up right; make them evangelists for the rest of the company. Word will spread and everyone will want this new wunder-tool, because "Why does Bob's team get new tools when we're stuck working with CVS? Do you realise all the problems we have because of it?"

Perhaps this StackOverflow question (and its answers) would be of help:

• Difference between GIT and CVS

Not sure if your looking for a general guide on migration or a full on comparison of the two services, but here is the former.

EDIT

Since SVN was mentioned here is a great guide I've used in a few SVN to Git migrations.

EDIT

I came across this great site, Why Git is Better than X, I thought I'd add it to this answer for other people thinking of switching to Git for version control.

I'm going through this at the moment, so I'm going to add my 2 cents (late to the game).

I'm in charge of leading our team off of CVS onto either Subversion, Mercurial, or Git. Your team's expertise, your project(s), and your release methodologies will probably change what answer you give. For disclosure, my team works on a series of smaller Java projects and use the Netbeans IDE and Maven to develop and release software.

Subversion

Yeah, sorry, it's a little off-topic, but it's still a definite upgrade from CVS. It'll result in atomic project commits, a wide existing user-base, and some good community tools. It's probably the easiest transition with the least training necessary, but you definitely don't have the power of DVCS. I recommend the cvs2svn tool.

Mercurial

Mercurial has great documentation, even for some of the weirder use-cases. It's easy to spin up a repository. Easy to install (just use Python, setup-tools, and 'easy_install mercurial'). Easy to convert to, and the developers who hate command line get the great TortoiseHg tool out of the box.

I found the cvs2hg tool far more accurate in converting than the built-in 'hg convert' extension, but ymmv.

For teaching everyone hg, try Joel's site: HgInit. There's plenty of books and online tutorials, but getting everyone used to pushing and pulling (and how it relates to your release process) is going to be the craziest part. I personally find this push / pull model of DVCS preferable, but others may disagree. It's practically like forcing everyone to branch every piece they're working on.

When deciding whether to go with subrepo's or just meshing the entire thing into one big repository, opt for the single repository. Dealing with multiple subrepo's proved to be a bit of a pain over just having one repository with inter-mixed history. (Your list of projects and how they interact will affect this decision greatly) Your IDE and GUI tools will help overcome some of that weirdness. After conversion go through each branch and know what to expect. Swapping to a branch no longer means you'll get a few changed files. It means everything that wasn't branched doesn't exist.

Git

I really ended up being surprised at how much I liked this tool. Our IDE's integration was better, the tool was faster than hg (in my experience), and it was easier to set up stuff like ssh repositories.

Installation and conversion and setup was a bear. In the end I decided this part was worth more than the effort required. According to this question, the 'git cvsimport' tool is broken on larger CVS projects. Also, my go-to conversion tool: cvs2svn sorely needs help improving the Git functionality. After I figured all that blob/dump-file-then-import-to-bare-git-repo business, I found that it forgot to pick up all of my branches from CVS. Maybe I just never understood the tools well enough, but the safest way off of CVS to Git seems to be through SVN.

Also, there's plenty of good arguments against DVCS, such as the issue of every developer walking around with the entire repository. If you ever push some bad jojo up and it gets pulled, it's gonna be a huge pain removing it.

For hosting an http repostiory, take a look at scm-manager and RhodeCode. RhodeCode's harder to setup, but has far more functionality. Both tools are difficult to use with subrepos, so be prepared for that.

As for convincing your boss. I did it through coining the term 'CVS-surgery'. Just like anything else, keep track of all the time you're wasting going back through CVS and fixing commit / rollback errors. Then present your case as "You'd have X hours of my time for free right now if we'd just convert to this tool". I found rolling back to an untagged commit in CVS, file-level commits, and the difficulty involved in finding what branches changes were taking place in the biggest issues with CVS.