As a system admin, the chances are you collaborate with multiple people across the company, therefore you will probably know the stress of constantly transferring files and version controlling the changes. Version control tools are a great way to enable collaboration, maintain versions, and track changes across the team.
Perhaps the greatest benefit of using version control tools is that you have the capacity to deal with an unlimited number of people, working on the same code base, without having to make sure that files are delivered back and forth. Below are some of the most popular and most preferred open-source version control systems and tools available for making your setup easier.
Version control systems are indispensable if you're working on a multi-person project, and they're pretty damn useful even if you're just working solo. Keeping a full history of the changes you've made gives you a basic backup and enables you to revert back to an earlier version if you screw something up.
But with so many options available, from the rather dated CVS onwards, which one is best? What about distributed versus centralised? Read on as we look at three of the big names - Bazaar, Subversion and Git - to give you an idea of which one might best suit you and your project, whether that's large-scale software, small-scale coding, keeping track of config files or anything else that might spring to mind.
CVS may very well be where version control systems started. Released initially in 1986, Google still hosts the original Usenet post that announced CVS. CVS is basically the standard here, and is used just about everywhere – however the base for codes is not as feature rich as other solutions such as SVN.
One good thing about CVS is that it is not too difficult to learn. It comes with a simple system that ensures revisions and files are kept updated. Given the other options, CVS may be regarded as an older form of technology, as it has been around for some time, it is still incredibly useful for system admins who want to backup and share files.
SVN - Subversion
SVN, or Subversion as it is sometimes called, is generally the version control system that has the widest adoption. Most forms of open-source projects will use Subversion because many other large products such as Ruby, Python Apache, and more use it too. Google Code even uses SVN as a way of exclusively distributing code.
Because it is so popular, many different clients for Subversion are available. If you use Windows, then Tortoise SVN may be a great browser for editing, viewing and modifying Subversion code bases. If you’re using a MAC, however, then Versions could be your ideal client.
Subversion was designed as a successor to the very popular CVS, fixing some of its most notable problems or irritations in the process. It works on a client-server model, as CVS does. Your central repository can be local (accessed via file://) or remote (accessed via http:// or https://, or via the custom svn:// or svn+ssh:// protocol).
Unlike with Bazaar, you always have to set up a central repository (whether locally or remotely) before you start; so the process of getting your files under version control is slightly more effort. Once they're in there, you have to check them back out again to get a working copy
In terms of the change/check/commit cycle (change the file, check for conflicts, commit the change), the commands and basic operation are much the same as with any other version control system. To some extent, once you've got started with one system you have a head start on all the others, as many of the commands are similar.
If you encounter a conflict within Subversion, you have to explicitly mark the conflict as 'resolved' before you can commit the file. This can occasionally seem like a nuisance, but it does reduce the chances of a conflict being accidentally committed. (Although you can of course just remove the flag without actually resolving the conflict!)
Repositories can be branched and tagged, as they can in other systems, and it is relatively simple to merge a branch back in with the trunk. However, merging multiple branches, or cross-merging between branches, can be difficult; this is something that distributed systems handle far better than client-server systems.
You can also merge and separate whole repositories - the admin tools available for SVN include svndumpfilter, which enables you to filter out particular projects. In general, however, Subversion isn't designed for the same level of branch management flexibility as distributed systems are. There's no integral command to take a patch file and merge that into your tree; you have to use the standalone tool patch, which can cause problems with deleted or merged files.
Subversion has a system of properties whereby you can attach versioned metadata to your files. You can set pretty much any human-readable label you like to be a property: it's a neat way of maintaining extra data about your files.
$ svn propset test "test property value" myfile.txt $ svn proplist myfile.txt Properties on 'myfile.txt' test $ svn propget test myfile.txt test property value
There are some special properties, beginning with an svn: prefix, that do particular things, for example you can set the svn:ignore property on specific files and they will thereafter be ignored.
You can also, as with Bazaar and Git, set hooks: scripts to be run when particular things happen. These are useful for jobs such as checking that code will build correctly before a commit is allowed, removing trailing whitespace, changing tabs to spaces (or vice versa), and sending emails to your fellow developers after you've made a commit. (And, of course, anything else you can think of and have the ability to write a script for!)
Git is considered to be a newer, and faster emerging star when it comes to version control systems. First developed by the creator of Linux kernel, Linus Torvalds, Git has begun to take the community for web development and system administration by storm, offering a largely different form of control. Here, there is no singular centralized code base that the code can be pulled from, and different branches are responsible for hosting different areas of the code. Other version control systems, such as CVS and SVN, use a centralized control, so that only one master copy of software is used.
As a fast and efficient system, many system administrators and open-source projects use Git to power their repositories. However it is worth noting that Git is not as easy to learn as SVN or CVS is, which means that beginners may need to steer clear if they’re not willing to invest time to learn the tool.
Git, like Bazaar, is another distributed version control option, initially created by Linus Torvalds for Linux kernel development.
One of the core features of Git is its support for non-linear development processes: the idea that changes will be repeatedly merged as they are passed around reviewers (as happens with the Linux kernel development process). In practice, this means that it's very easy to merge branches, and even to merge entirely unrelated, independent branches or trees that have no common ancestor.
This also means that it's possible to merge unversioned code or files into an existing versioned tree: something which neither Subversion nor Bazaar can handle straightforwardly. Git is also designed to be fast, to deal with large projects quickly.
Git's distributed nature means that, like Bazaar, each working copy carries its own repository around with it (in the .git subdirectory), rather than the repository living in a central location as with SVN. Again, this means that it's easy to get a new project under version control - in the project directory, execute git init; git add .; git commit - but it also means that backing up is slightly more complicated. Again, if you want to you can set up your own version of a locally centralised repository.
This is yet another form of version control system, similar to Git. It was designed initially as a source for larger development programs, often outside of the scope of most system admins, independent web developers and designers. However, this doesn’t mean that smaller teams and individuals can’t use it. Mercurial is a very fast and efficient application. The creators designed the software with performance as the core feature.
Aside from being very scalable, and incredibly fast, Mercurial is a far simpler system to use than things such as Git, which one of the reasons why certain system admins and developers use it. There aren’t quite many things to learn, and the functions are less complicated, and more comparable to other CVS systems. Mercurial also comes alongside a web-interface and various extensive documentation that can help you to understand it better.
Similar to Git and Mercurial, Bazaar is distributed version control system, which also provides a great, friendly user experience. Bazaar is unique that it can be deployed either with a central code base or as a distributed code base. It is the most versatile version control system that supports various different forms of workflow, from centralized to decentralized, and with a number of different variations acknowledged throughout. . One of the greatest features of Bazaar is that you can access a very detailed level of control in its setup. Bazaar can be used to fit in with almost any scenario and this is incredibly useful for most projects and admins because it is so easy to adapt and deal with. It can also be easily embedded into projects that already exist. At the same time, Bazaar boasts a large community that helps with the maintenance of third-party tools and plugins.
Bazaar can be used with either a distributed workflow style, with small task branches for each new feature and developers using a local mirror branch to send changes back to the shared server; or with a more standard centralised version control style where developers regularly commit directly to the shared server. It also works well for personal single-user projects. The declared aim of the Bazaar team is that the software should fit the way you work, rather than you having to mould your working style to the software.
One nice feature of Bazaar, especially when you're working on your own, is that (unlike with Subversion) you don't have to create a repository, import your files, and then check out a working copy. You just work from within your project directory and Bazaar does its tracked changing from there.
Of course, one downside to this is that it's more complicated to back the repositories up: you need to either keep all your projects as subdirectories of one main directory, or make sure that all of your directories are being backed up. (Which is not, of course, such a bad idea anyway.) It does also mean that a slip with rm -rf will take out your repository.
This makes it much easier to start a project: instead of having to import your code and then check it out again, you can just initialise a new project from within your directory. You can also use a separate repository directory and check out a branch from that repository, if you prefer to work in that slightly more centralised way. Repositories are easy to set up, using the init-repo command.
The distributed nature of Bazaar enables you to work and commit changes without a net connection. You can do this with centralised version control by having a local repository; but that can cause problems when you want to merge back in with the main repository.
The way that Bazaar operates makes this localised version control easy: you download from a main project with the bzr branch command, which then creates a local branch on your own machine for you. You can work from this branch, or create further sub-branches as you like, and commit as often as you like.
You can merge changes from the parent with bzr merge, and then when you're happy with your code, you can create a patch to send upstream with the bzr send -o patchname.patch command. Whoever owns the parent branch can merge the patch in or not as they prefer (using the same commands as when merging a branch). While in theory Bazaar enables you to operate without a central project tree, most projects will maintain a central tree and merge changes into that.
Bazaar's merge algorithm supports merging multiple branches, and will locate the most recent common ancester. It can also weave branches together, and can deal with some fairly complicated setups. However, it does require that the branches being used have some common ancestor (unlike Git, which will merge entirely unrelated trees).
Bazaar also supports cherrypicking, which is when you merge some changes from a branch (say up to version 104, or versions 105-7) but not all of them. You can also temporarily shelve changes that you're working on (take them out of your working tree, to return it to an earlier state, perhaps to make it easier apply a large upgrade/update from the parent branch), and then unshelve them when you want them back.
This is useful when you're working on multiple patches, or when you want to assess other people's patches. As with Subversion, hooks (scripts run before or after particular actions) are available.
Usefully for larger projects, Bazaar can be linked in with bugtracking solutions. By using the --fixes notation, you can associate a bug number in a particular bugtracking system (there's support for Bugzilla, Launchpad, Trac, and Roundup, among others). So this:
bzr commit --fixes project:23400 -m "Stores user birthdates properly"
will add a link in the log to bug 23,400 in the Bugzilla tracker for Project. (There's support for easy configuration for Bugzilla and Trac.)