Version control systems (VCS) are important in a developer’s life. It’s one way we remain sane.
Long ago I used Projector. Actually before that I didn’t really use anything except making periodic clones and perhaps putting them into StuffIt archives and backing them up to 3.5″ floppy disks. But once I started using Projector and the joys of ‘ckid’ resources, life was never the same. 🙂
For a short time there was Visual SourceSafe, but I actually never used Microsoft’s version of it. Metrowerks had made a Mac client for it and I used that, because I worked for Metrowerks at the time. But oh… it was… terrible. I think the only thing I miss from it is Robin Mair‘s PageController GUI widget (revolutionary at the time, and looked damn cool), but otherwise VSS was called “Visual Source Suck” for a reason. Still, it was better than what had come before.
But then we moved on to CVS, which wasn’t horribly bad but was pretty bad. The simple fact you couldn’t rename things was a big problem.
Then then along came Subversion and everyone was happy, because finally we had a CVS that didn’t suck! And that it was, based pretty much around the same concepts and paradigms and CVS, but without much of the suck. And for the most part, that’s what I have used for VCS for the past I don’t know how many years.
Now there’s tons of other stuff out there, then and now, but my developer path never crossed with Perforce or any of the other things out there.
I’ve known about them for a while, but to me it seemed like just another attempt to reinvent the wheel. What did they really bring to the table? Was there really something that was significant enough of an advantage to switch? I never like switching to these things in the beginning because they’re always immature. I mean, when we first switched to svn it lacked some important functionality; it was far enough along to finally start using it on a daily basis but still not 100% there. I don’t need immature tools that then hamper my work in a day.
Not a day goes by when I don’t have some growing interaction with them, especially git due to GitHub. I find a lot of iOS developers using git and GitHub, maybe because Xcode seems to have a built-in preference for it now. I talk with more people using git. I have a little time right now, so I opted to start reading up on git.
I guess the timing is right, because suddenly it makes sense to me. I see where it could be potentially advantageous. I still haven’t actually used it yet, just been reading, but two things happened.
1. On another project, the svn repository is scheduled to be moved from one server machine to another. Work is still being actively performed on this repository. If they did things right, there shouldn’t be any problem nor revisions missed. However, we are anticipating things won’t be done smoothly and revisions risk being lost (better to plan for the worst). The solution? Just don’t commit anything from “now” until we know the server transition completes. This is… not good for numerous reasons.
But it occurred to me that with git, you’d still be able to incrementally work on your code, deal with daily life matters such as realizing you need to roll back, or just ensuring some sort of trail and history of your work. Whatever, all the advantages and reasons for why we use VCS. Then just be sure to do a few extra or special tags or commits regarding the server transition, and then see the state of things after the server move. And if anything was lost, no big deal.
Sure you could still find a way to manage this with svn, that’s more elegant than just “don’t commit”. But still there’s so much extra work and overhead to make it work, at least, compared to a git solution. Or at least, as I perceive a git solution to be.
2. On yet another project, an iOS project, I was in the midst of a lot of work that wasn’t ready to share with anyone. But someone needed a one-off build because we just added their device’s UDID to the provisioning profile. The build machine had problems, I wasn’t in a position to build, but a build had to be made. Thankfully everything just managed to work out, but at that moment when it all came down it would have been disruptive to do the build.
Likely what I would have had to do is hit the VPN, hit the network, checkout a totally new working copy of the project (non-trivial if you have a large project and a slow network; thankfully not the case here but I’ve experienced such projects), then do that as a build. So it’s possible to do, of course. But when I thought about a git solution, it’d be so easy to stash my work away, switch to the master branch, build, then get back to my work.
Now I git it (lame pun).
Now I see some advantage to the tool over existing tools.
I’m going to start playing with it.
Create a dummy repository and just tinker a bit. That “another project” above? It’s hosted in svn and has to stay that way, but I’m going to use “git-svn” to make things go. Thus, it’s all git to me, use git locally for my own work, but then still pipe it back to svn. Hsoi Enterprises code is in svn, and I may start out with it in “git svn” so the code still gets backed up and maintained on another server (gotta slowly break myself of the client-server mode of thinking), but I’m sure if I end up liking git I’ll use it alone tho I may still push to a remote for redundant backups.
The other thing will be seeing how I can integrate back with various GitHub projects. I’ve downloaded numerous Cocoa Touch classes from there, but many had to be modified for some reason or other. Will be curious to see how that all will work out.
It’s always fun to explore new things and find new ways to work better, work smarter, and overcome the little things that get in your way on a daily basis.