[rabidgnat]

Backwards-compatibility efforts like these are great. Some CVS/SVN users are (un?)surprisingly stubborn about trying new things, and they can halt upgrade efforts with their complaints. My company is converting our repositories from CVS to git as we speak, and the number within our ranks who prefer CVS is surprising. Without support for older programs like CVS, we wouldn't have the momentum to upgrade

Kudos to Github for providing one less excuse to holdouts!

[umjames]

I'd like to know how that transition is going for you. Are you having the expected difficulty of explaining a DVCS workflow? Any difficulties converting CVS modules to git repositories?

At work, I'm stuck on CVS. I'd love to use git, but the people I work with don't really know how to use any version control system properly. My commits are the only ones with commit messages. They don't use tags and haven't heard of branches.

I mentioned git to my boss, but he was hesitant because he couldn't get it running on his Windows 7 box at home (we don't use Windows 7 at work, mostly WinXP). I did a quick Google search and found that the problem is with a changed DLL in Windows 7, and that putting the old version of that DLL in git's bin directory should work, but I don't think my boss tried that.

[rabidgnat]

It's going pretty well, but we're cheating: we give the other devs both the CVS and the git checkout commands, and let them use what they want. The early adopters tend to be those who already use it outside of work.

I agree that the tools on Windows aren't stable: I've had to help debug at least 3 or 4 git installs of TortoiseGit-esque tools. I personally just use it from the command line.

Moving forward, we'll train people to use git when they go offsite with other developers, or if they're curious. Part of our job involves spending days away from an Internet connection, so they'll suddenly be sink-or-swim and probably never turn back :)