In my time as a software professional I have seen many systems for maintaining and tracking changes to code in progress. Whether this is the archaic and I hope no one ever really uses this on a real project practice of passing along zip files of changed code with comment mark-up to indicate where changes were made, or to full featured source control solutions, like subversion, team foundation server, or git, every project at some point or another will have to make a decision on how to handle these files.
I could spend time dealing with the importance of choosing any source control solution, but that's not what this post is about. Instead I'd like to take a moment to describe some of my experience with source control solutions.
In general there are two sorts of source control mechanisms, one is like that used with Microsoft's Team Foundation system (and before it Visual Source safe an incremental check out/check in system, and the other is a check out the code base, and commit/update to get/add the latest changes to the current working version. There are pluses and minuses to both schemes. The incremental check out/check in system really feels like a pull system. While you can download the latest tree from a base directory, to make changes, and have them be saved with out the IDE screaming about read only or protected files, you have to make a point to check out in essence pulling on TFS to make the file ready for editing. Team Foundation Server (TFS) allows you to do this in an exclusive mode, essentially locking out any other attempts to check out and change the file by other users, or a less prohibitive more shared lock.
I've only had the privilege of working on a single project with TFS thus far, and that project relies on the exclusive kind of check out system most of the time. This means that if a developer needs to make a small change to a file that you are working on, he will have to communicate that need to you, so that you can then do a hand shake of releasing the locked edit, so that the change can be checked in. It can be a real pain at times when you want to try a quick fix and the IDE prevents you at times from trying something simply because it's marked as 'read-only'. It provides a benefit in that it limits the number of files you might accidentally touch which can be a blessing at times. It also means that anyone trying to check in another fix may not be able to do so while it is held checked out, and as has happened to me a few times, sometimes files in a project may get checked out by the IDE automatically even if you did not intend it so.
The other form of version control management is the style for which Subversion has become known. It is in essence a more push style of architecture, where by, you can check out an entire source control tree (much like getting latest for any particular folder), and then have significant freedom to make changes, erase a file and refresh/revert it from the last commit, or even make a series of changes and check them in one after another. The draw back of this system, is that because anyone can edit, there is the possibility of files getting more and more out of sync from the base or trunk as it is called in subversion. This can present problems when during a commit a major conflict arises trying to reconcile differences between the two files. In my experience though, if used judiciously and kept up to date and committed as often as necessary, these conflicts can be minimized fairly easily. Subversion also has the bonus in that it is portable to other operating system types, and is not dependent on the windows/.Net stack as much to function.
There may be other tools that fit your needs better, Wiki's can be edited inline from a browser and keep good version tracking of each meta page, content management systems like Share Point can allow you to track updates to your requirements, contacts, or serve as a portal for storing key documentation for a production. Whichever tool your team chooses for source control, it is critical that your entire team is on board with its function, and regular use to help avoid major headaches between builds. The value of source control is manifest in how it allows teams to track branches of in progress development code, tag certain releases for easy comparison later, and giving a history with comments about the update and logs of the files that have changed. This logging function can be of great value when trying to track down how a particular strain of bad code may have made its way into your product.
Then some source control systems allow you to track the progress of development from requirement, to deployment. Team Foundation Server has these features out of the box, while open source tools like Subversion require other components, for example TRAC, to help track the progress of development. I hope that whatever your team chooses to use, that you will find the source control to be a great asset, that helps facilitate your development needs.
No comments:
Post a Comment