Version control is one of those vital tools for developers that everyone has to use but very few people actually enjoy or understand.
So, itâ€™s with no surprise that I noted a few months ago that the version control software on which Iâ€™ve relied for several years for my personal projects, Component Softwareâ€™s CS-RCS, has not been built on in years, and cannot now be downloaded from its source site. [Hence no link from this blog]
Iâ€™ve used git before a few times in professional projects while I was working at Amazon, but relatively reluctantly â€“ it has incredibly baroque and meaningless command-line options, and gives the impression that it was written by people who expected their users to be just as proficient with the ins and outs of version control as they are.
While I think itâ€™s a great idea for developers to build software they would use themselves, I think itâ€™s important to make sure that the software you build is also accessible by people who arenâ€™t the same level of expertise as yourself. After all, if your users were as capable as the developer, they would already have built the solution for themselves, so your greater user-base comes from accommodating novices to experts with simple points of entry and levels of improved mastery.
git, along with many other open source, community-supported tools, doesnâ€™t really accommodate the novice.
As such, it means that most people who use it rely on â€ścookbooksâ€ť of sets of instructions. â€śIf you want to do X, type commands Y and Zâ€ť â€“ without an emphasis on understanding why youâ€™re doing this.
This leads inexorably to a feeling that youâ€™re setting yourself up for a later fall, when you decide you want to do an advanced task, but discover that a decision youâ€™ve made early on has prevented you from doing the advanced task in the way you want.
Thatâ€™s why Iâ€™ve been reluctant to switch to git.
But itâ€™s clear that git is the way forward in the tools Iâ€™m most familiar with â€“ Visual Studio and its surrounding set of developer applications.
Itâ€™s one of those decisions Iâ€™ve made some time ago, but not enacted until now, because I had no idea how to start â€“ properly. Every git repository Iâ€™ve worked with so far has either been set up by someone else, or set up by me, based on a cookbook, for a new project, and in a git environment thatâ€™s managed by someone else. I donâ€™t even know if those terms, repository and environment, are the right terms for the things I mean.
There are a number of advanced things I want to do from the very first â€“ particularly, I want to bring my code from the old version control system, along with its history where possible, into the new system.
And I have a feeling that this requires I understand the decisions I make when setting this up.
So, it was with much excitement that I saw a link to this arrive in my email:
Next thing is Iâ€™m going to watch this, and see how Iâ€™m supposed to work with git. Iâ€™ll let you know how it goes.