Posts Tagged ‘cvs’

There are quite a number of tools to convert a CVS repository to a Git repository out there. However, most of them don’t seem to be able to copy over the branches properly. A work around is to convert it to Mercurial first, then convert it to Git.

In this example I’m using a repository called RedDog.

First, we need to get Mercurial on the system.

yum install mercurial

Next we need to add the convert extension to the .hrc file. This might be a global file, or might be in your home directory, can’t quite remember.

[extensions]
hgext.convert=

Check out from CVS and convert to Mercurial.

cvs checkout RedDog
hg convert RedDog

This will create a Mercurial repository called RedDog-hg. Now we need to get hold of Fast Export.

git clone git://repo.or.cz/fast-export.git

Once we have the software we can initialise a new Git repository that we’re going to use and then CD into the folder.

git init RedDog-git
cd RedDog-git

Run the Fast Export tool, specifying the location of the Mercurial repository.

../fast-export/hg-fast-export.sh -r ../RedDog-hg

This will migrate everything into your new Git repository. If you run an ls -a you should see the .git folder, which you may want to rename to RedDog.git (something.git locations are actually just .git directories).

You may optionally also want to do a check out into that folder.

git checkout HEAD

However, you don’t have to – you can begin using it remotely without doing a local checkout.

If you’re using version control (you are using version control, right?), the question sometimes comes up as to how often you should commit.

I’m a commit fanatic, I like to commit as soon as soon as I can, no matter how small the change. Other people prefer to wait a little and make large commits all at once. However often you choose to commit, you should make sure it falls within the constraint of being atomic.

This means that each commit is one single, complete change. That is to say that you shouldn’t commit multiple changes at once, nor should you commit a change that is only half done. This is scope in this for different approaches of course “one single, complete change” could be part of a several step refactor as long as the changes stand on their own, so could committing the refactor at once if it is all part of the same unit of work. But the important thing either way is to try and stick to atomic commits.

Think of it like an ACID transaction. Presumably you’re system works before you make the commit and it should work after too. It should contain just one feature so that if you want to roll that specific feature back, you can roll back that one commit without rolling anything else back.

With Git, where people may want to take out of sequence commits, this becomes especially important. People may want to take one of your changes, but not the other, so making sure two changes are in two separate commits is very important. Generally, if your descriptive commit comment (you are writing descriptive comments, right?) contains the word and, you probably need to re-think your commit.

This will give you a list of all the commits made between a specific date period. Just alter the dates accordingly.

cvs diff -N -c -D 2011-03-21 -D 2011-02-28 > /tmp/diff.txt

Quick command for listing locally modified CVS files.

cvs -Q status | grep -i locally