Examining The Limitations Of Current Version Control Systems

Since the late 1980s there was one open source code version control system, the Concurrent Versions System [CVS] developed by the Dutch computer scientist Dick Grune. Despite some flaws in CVS it remained the leading version control system purely due to a lack of alternatives.

This was until 2000 when CollabNet Inc contacted Karl Fogel, the author of Open Source Development with CVS, to collaborate on a programme that would match the same development features as CVS but without duplicating the flaws.

Interest spread rapidly and a community of active developers evolved mainly due to widespread frustration with the existing flaws and limitations of CVS. On 31st August 2001 the developers of Subversion stopped using CVS to host Subversions source code. Subversion was self-hosting and more importantly it was free.

So what is Subversion? Effectively it is a system which manages files and directories, allowing users to make changes to data whilst keeping a retrievable record of data changed; alledgedly the same as CVS however focussing on the development of the weaknesses prevalent in the aforementioned system. I decided to put it to the test.

These alledged weaknesses of CVS included: the inability to version the moving or renaming of files and directories, no versioning of symbolic links, limited support for Unicode text-files, no atomic commit and expensive branch operations.

One of the major improvements I found had been developed was the three-dimensional file system which allows multiple revisions to be made to the same file whilst maintaining a compact file size.

Previously where files were revised often the file size was high and moving large files around the system was impractical. Now each file-system has its own root which manages the data of each revision, meaning that revisions do not require additional storage space.

I found other benefits of Subversion are that it tracks changes to entire directories as opposed to individual files. File histories are started from fresh each time a new file or directory is created even if it shares a name with another file or directory.

The atomic commits feature is usefeful and enables developers to construct changes, sending all modifications to the repository in bite-size fragments, preventing problems previously occurring when only a portion of a set of changes were successfully sent to the repository.

I found that properties are versioned just as file contents, enabling me to create and store property values over time and there is a choice of network layers simplifying the implementation of new network mechanisms.

I also found the data handling is more consistent due to the usage of a binary differencing algorithm when dealing with file differences, which works identically whether dealing with binary or text. Branching and tagging has been made more effective and the system itself has been made more compatible with other applications and languages.

Subversion is not without its own problems. I found the file directory and rename operations caused some confusion to the system as it makes a copy of the new name and a delete of the old name whilst maintaining the same history. This can cause confusion when files are moved and modified in the same commit.

Also it lacks some administration and management features and stores additional copies of data on the local machine, potentially causing problems for big projects. However the system is free where its predecessor was a proprietary system, so can be downloaded, modified and distributed under free software licence.

The home of Subversion is on the website Tigris and although the open-source community does not provide binary I found that these can be downloaded from volunteers and CallobNet.

Seed Newsvine

Bookmark this article in your preferred program

Comments

Add Comment

Popular Articles in this cathegory

This article is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License.