On 8/1/05, Branko Èibej <brane@xbc.nu> wrote:> That said, I'll reiterate that Subversion is a version control tool, not> a CM tool. It has (most) of the features you need to build a CM system,> but it is not a CM system by itself.
The question becomes what features are the heart and sole of a versioncontrol system, and when does a particular feature make a VCS into aCM system.
Let's take a look at SCCS again. I used SCCS for years even though ithad no ability to create tags or do more than a single one deep branchstructure. TCCS, PCMS, BitKeeper, and Sablime were all strong CMsystems built on top of SCCS. So, it seems that SCCS had more thanenough features to handle basic version control.
However, SCCS was quickly replaced by RCS because RCS had the conceptof tags (names in RCS parlance) and had the ability to offer infinitedepth branching. CVS started off as a bunch of Perl "CM" shell scriptsthat wrapped around the basic RCS commands but quickly grew into aversion control tool in its own right because it plugged in many ofmissing version control features not found in basic RCS itself.
Then again, when I first started programming (back when I wasconsidered a User Interface guru because I knew the ins and outs ofthe curses library), we simply did version control by saving copies ofour files with suffixes marking the "version" number of our files. Ifwe needed to branch, we would simply copy the whole structure toanother directory. I wrote a bunch of shell scripts to do stuff asmerging, checking in and out files, and branching. Who needs any ofthe "CM" features found in SCCS when you have the Unix "diff", "cp",and "mv" commands?
So let's look at the history of Version Control Systems:
* Pre-SCCS: Shell scripts around "cp", "diff", and "mv"* SCCS: Added the idea of archives, built in logging, branching, and diffing* RCS: Expanded branching and built in the concept of tags* CVS: Concept of a single source archive (instead of dozens of sourcearchive directories), workspaces, and establishing developmentworkflow (checkout, work, update, commit).
In each one, we were able to build a complete development system bysimply writing our own wrappers around an existing system. Eachsucceeding generation brought in more features that were originallywritten in our wrapper scripts because these features became to beunderstood as part and parcel of a basic version control system.
So what is a basic VCS feature?
Maybe we can draw a parallel example with the automobile industry. Incars, features are divided into three groups: Basic features (youexpect your car to have brakes), comfort features (sunroof, high endmaterials, heated seats), high end features (GPS system, high endsound system, multizone ac/heating system).
Over the years, features once associated with the high end, move downto the comfort level and into the basic level. For example, when I wasa kid, only Cadillacs had electric windows. Today, even the most basiceconomy car comes with them.
The same thing happens with VCS features. What once was considered ahigh-end, but unnecessary feature has turned into an expected minimumrequirement. Subversion has upped the ante with its atomic commits andthe use of being able to work with well established protocols thatinclude built in security. In a few years, almost all version controlsystems will sport these must-have features.
So, it seems rather strange that Subversion doesn't understand thebuilt in concepts of branches and tags. Instead, these items aremerely emulated via pseudo-directories. After all, tags and brancheshave been implemented as part of version control systems since RCSback in 1985.
Can you version control without true tags and branches? Well, I use todo version control on a system that didn't have a concept of of asource archive (just as a Russian friend of mine use to drive a carthat didn't have the concept of "brakes"). All I had to do was spendlots of time attempting to implement the non-existent concept and thenfixing the errors and training users to understand my front end.
Today, we now spend time implementing on top of Subversion the conceptof tags and branches. We parse the output of "svn log", we writehooks, we use directories, we train users in the "correct way" to dosomething, and we spend time fixing mistakes.
There's a lot of great stuff in Subversion. The atomic commits, theflexibility of the client, the ease of installation, the open sourcenature which means I don't have to track licenses, the ability to workthrough standard Internet protocols all make Subversion an excellenttool. I understand Subversion is still a young tool, and new featuresare being added all the time. I also have a small list I'd like tosee:
* Tags and branches implemented as true meta-data types* Merging that is clean and simple (needs true branching first in order to work)* The ability to query files by various properties. * Remove old file versions. I would like to version a set of 700mb CDimages, but that would quickly over whelm my archive storage and mySysAdmin's ability to do backups. It would be possible if I couldremove the old versions of files that we no longer need, but that'sonly possible via a dump and load.* Remove the entire history of a file. Sometimes, a file thatshouldn't be in the archive is accidentally added to the archive. Ifthis file contains proprietary information, it must be scrubbed fromthe archive. Unfortunately, you can't remove it in Subversion.* A new type of property that is a cross between a file property and arevision property. I'd like to attach a property on a revision of aparticular file. For example, to mark if that file had beenpeer-reviewed or tested by QA or whatever else I might want.
Some of these features I consider a necessity. Others are merely niceto have. However, I don't believe any of these features are considered"CM" features, but merely tools used in order to build a CM system. ACM system is more than just archiving tools. CM is the method used inthe development of the product. You build your CM system upon theversion control system and other various tools you have.
--David Weintraubqazwart@gmail.com
Received on Mon Aug 1 21:18:45 2005