Skip to main content

How To Git Away From CVS

James went along with the idea of moving away from CVS quicker than I thought and we put the plan into action last week. I put in the time to the project and started off with the default CVS replacement: Subversion. I really was looking forward to using it at work, until a friend made a subtle suggestion to look closer at the git project, which Linus Torvalds is heading as the version control system of choice for some little thing he's writing called Linux. Needless to say, I was skeptical, given the track record of the developer.

Quicker than I realized, I was falling head over heals for the examples of git use I was seeing. I cooked up a latest stable for OS X, as the installer I found was 130MB from the 1MB source tarball. Universal binaries on a project that generates about 145 distinct executables is a real bitch. I whipped up a little script to name git and toss into $PATH, while keeping all the git-* executables and other files tucked away in /usr/local/git/. I've cleaned that up and released it for anyone else interested in a clean git install on OS X. I may be releasing more git related work in a the near future, if you read on.

For Development Sanity This Means...


As a team grows out of a few developers and reaches nearly a handful, you need to start thinking more about development processes. Fixing a bug quick while in the middle of a half-finished change is a real problem, especially if you've commited already. Multiple developers working on separate projects can also be difficult to manage, if you don't think about things. These were among our concerns. Also among these concerns was the benefit of making the switch before bringing anyone else on board.

We had seven CVS modules and I developed a script that imported each of them to a new git repository and them merged them in the same layout as we had by checking out all our modules into the same directory. Keeping them together was a good move, and we kept our whole history.

Branching was one of the core driving motivators and I was thrown back when I found branching not doing what I expected in git. Branches in git are local, and although you may often push or pull between branches named the same on different repositories, they are not really related. I got to work on developing a set of branching tools, and I'm very happy with what I did in a small amount of time. The functionality is pretty complete. We can create, share, merge, and switch branches easily. I've even implemented automatic stashing and restoring of working copy changes that haven't been commited when switching between branches!

For Released Work This Means...


The tools are proving fun to work on when some issue comes up where they could be improved. They began life as a set of shell scripts, but they will very likely evolve into Python scripts to facilitate their future improvement. They are also very likely to leave the repository which they themselves are in control of. That was a headache to get proper.

When they are converted to Python I am going to release them. I really want to actually publish the git repository, but I need to figure out how to do that and if we can do it securely from work somehow. It would be nice to do that, such that the repository is always up to date with what we have. I'll probably mirror them to http://repo.or.cz/.

I've also placed the git binaries for OS X in two bzip2 compressed tarballs. git-1.5.3-osx-intel.tar.bz2 is everything you really need, placing only a single git executable into the path. You can grab git-1.5.3-remote-osx-intel.tar.bz2 to expose the tools needed to access your local repository remotely, via ssh.

For SocialServe This Means...


The three current of us are now branching for our development happily. We've done hot fixes in the middle of larger branches, without disrupting our work. We've pulled bug fixes from the master branch into our own things, shared branches, merged them into the production line, and are generally having a really good experience.

I think that, in the end, this really means more productivity. I'm able to be more flexable with my project, because I don't need to keep every commit in a state that can be pushed into production if James suddenly needs to fix something unrelated. Branch based development is great, and our scripts help manage them very well. I can't wait to release them.

Comments

Stan Seibert said…
As a relatively new git user, I was most pleasantly surprised by git-bisect for tracking down which revision broke something. It is probably more useful when dealing with other people's source trees, where you aren't as familiar with the code base.

It is also nice when working by yourself to be able to quickly run "git init; git add . ; git-commit" to add version tracking to any directory.

git-svn is also good enough now, that I use it to interact with all svn repositories as well. Being able to git-svn import a project so you can git-bisect their revision history is amazingly handy.

Popular posts from this blog

Respect and Code Reviews

Code Reviews in a development team only function best, or possible at all, when everyone approaches them with respect. That’s something I’ve usually taken for granted because I’ve had the opportunity to work with amazing developers who shine not just in their technical skills but in their interpersonal skills on a team. That isn’t always the case, so I’m going to put into words something that often exists just in assumptions.
You have to respect your code. This is first only because the nature and intent of code reviews are to safeguard the quality of your code, so even having code reviews demonstrates a baseline of respect for that code. But, maybe not everyone on the team has the same level of respect or entered a team with existing review traditions that they aren’t acquainted with.
There can be culture shock when you enter a team that’s really heavy on code reviews, but also if you enter a team or interact with a colleague who doesn’t share that level of respect for the process or…

CARDIAC: The Cardboard Computer

I am just so excited about this.


CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer. 
One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC?

It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on. The only re…

How To Care If BSD, MIT, or GPL Licenses Are Used

The two recent posts about some individuals' choice of GPL versus others' preference for BSD and MIT style licensing has caused a lot of debate and response. I've seen everything as an interesting combination of very important topics being taken far too seriously and far too personally. All involved need to take a few steps back.

For the uninitiated and as a clarifier for the initiated, we're dealing with (basically) three categories of licensing when someone releases software (and/or its code):
Closed Source. Easiest to explain, because you just get nothing.GPL. If you get the software, you get the source code, you get to change it, and anything you combine it with must be under the same terms.MIT and BSD. If you get the software, you might get the source code, you get to change it, and you have no obligations about anything else you combine it with.The situation gets stickier when we look at those combinations and the transitions between them.

Use GPL code with Closed S…