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 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

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

Statement Functions

At a small suggestion in #python, I wrote up a simple module that allows the use of many python statements in places requiring statements. This post serves as the announcement and documentation. You can find the release here . The pattern is the statement's keyword appended with a single underscore, so the first, of course, is print_. The example writes 'some+text' to an IOString for a URL query string. This mostly follows what it seems the print function will be in py3k. print_("some", "text", outfile=query_iostring, sep="+", end="") An obvious second choice was to wrap if statements. They take a condition value, and expect a truth value or callback an an optional else value or callback. Values and callbacks are named if_true, cb_true, if_false, and cb_false. if_(raw_input("Continue?")=="Y", cb_true=play_game, cb_false=quit) Of course, often your else might be an error case, so raising an exception could be useful

How To Teach Software Development

How To Teach Software Development Introduction Developers Quality Control Motivation Execution Businesses Students Schools Education is broken. Education about software development is even more broken. It is a sad observation of the industry from my eyes. I come to see good developers from what should be great educations as survivors, more than anything. Do they get a headstart from their education or do they overcome it? This is the first part in a series on software education. I want to open a discussion here. Please comment if you have thoughts. Blog about it, yourself. Write about how you disagree with me. Write more if you don't. We have a troubled industry. We care enough to do something about it. We hark on the bad developers the way people used to point at freak shows, but we only hurt ourselves but not improving the situation. We have to deal with their bad code. We are the twenty percent and we can't talk to the eighty percent, by definition, so we need to impro