I’m starting to get my hands dirty with CakePHP and as I’m getting started, I find myself pondering the use of source control. Not whether to use source control, mind you (because, well, duh), but how to use it optimally in the context of a framework or even a product that can be extended with custom code. Ideally, I’d like to version any and all code that I write or modify, but none of the framework code that is left unmodified. I’m not sure that I’ve ever spent much time on that question. As best I can remember, I’ve always just committed everything.

I’m wondering what strategies others employ with respect to source control when custom code is mixed with product or framework code. Are there any best practices?

Last night I gave a Subversion presentation for the Refresh Baltimore group. The presentation ended up being a bit more of an informal dialog due to time constraints, but that was actually great. I rather enjoy talking with people rather than at them, when appropriate. The audience seemed to be largely front end developers, but many were very new to source control in general and, of course, Subversion in particular.

After the meeting, I thought I’d write a bit about how I use source control within my workflow. It’s the personal experience that folks in the group – myself included – seemed most interested in. The terminology I’ll use will be Subversion-centric since that’s my tool of choice (for the moment), but the philosophies, methodologies and processes should be comfortably analogous to other versioning tools.

Continue Reading »

There’s been a lot of ambient (and not so ambient) noise in the geeky corners where I often linger about Git. There seems to be some sort of mass exodus underway as folks indicate that they have, or are planning to, move away from Subversion for their source control needs and I have to admit that I’m feeling a little ignorant.

I haven’t used Git (yet?), but I’ve been doing some reading and I still don’t quite understand the infatuation. Don’t get me wrong, it looks like there are some nice features, but at what cost?

The key difference between the two systems seems to be the model itself. Where Subversion offers a centralized model, Git provides a decentralized model. At the risk of over simplification, this means that Git offers each developer their very own, fully autonomous copy of the entire repository. With Subversion, each developer has their own working copy, but commits changes to a single, central repository.

The arguments in favor of the decentralized approach, as I understand them, include:

Speed

Okay, I like speed. Since each developer has a local copy of the entire repository, fundamental actions like diff, commit, etc. are all local. That’s always going to be faster. Fast is good.

That said, server interaction with Subversion isn’t exactly excessive. Developers work in local working directories and only interact with the server in short bursts. I’ve never found myself thinking, “Great Scott, this is unbearably slow.” For me, at least, this seems like a fix for something that isn’t broken.

Smaller Space Requirement

A Subversion working directory contains two copies of the entire code base. One that is actually being worked on and another tucked away in the .svn directory. I remember reading somewhere that the Mozilla repository required ~12Gb of storage in Subversion and ~420Mb in Git.

This is a substantial difference, to be sure, but there’s a phrase that everyone in technology hears on a daily basis: storage is cheap. That can’t be a compelling argument for one problem and not for another, so I don’t think this difference is one that’s going to precipitate a switch all by itself.

Line Ending Conversion

This is an important factor for mixed environment teams. Evidently early versions of Git made no changes and more recent version handle the conversion automatically. That decisioning is manual with Subversion, but is spectacularly easy to do by making a simple change to ~/.subversion/config for each file extension impacted to specify the line ending desired:

*.sh = svn:eol-style=LF;

Other Concerns

In addition to the fact that none of the arguments presented in favor of Git are particularly compelling to me, at least not the way I understand them, I have a few other concerns about the decentralized model. Actually, they probably all roll up to a single concern – accountability.

Every project I’ve worked on requires some level of immediate or semi-immediate accountability. A project manager who needs to ensure that an appropriate amount of progress has been made against the project plan, a boss who needs to spot review code or maybe a continuous integration process that needs regular repository updates so that its not just rebuilding the same old thing.

It seems like the decentralization of the repository would hamper those efforts. Sure, it can be done, but it would have to be done with process.

I also wonder if, in a team environment, having too many people doing too much of their own thing for intervals that stretch too long would make effective merges all but impossible. It seems like it would.

Am I missing something? Are there additional benefits? Is there anything else I haven’t even mentioned that I should be considering? I’d love to hear from other source control users who have moved to Git from Subversion.