Thu 28 Jun 2007
Version Control: From Where We Began to CVS and Subversion
Posted by Dan H under SlickEdit Products
[6] Comments
I came to work here at SlickEdit during the early nineties. I was just out of college and had a lot to learn. A lot of things have changed since then. We changed the name of the company, switched offices a number of times, released twelve versions of SlickEdit (some of them were called “Visual SlickEdit”). Shortly after I got here in 1993 we received an early version of Microsoft Visual C++ (I thought it was the first version, but Wikipedia says 1992, I can only guess that the one we had was not the first version). Visual C++was a big deal for development on Windows… And we were flooded with requests to replace the editor inside the Visual C++ application. To be fair, these request really only lasted for fourteen years or so. When they stop I will write another blog about it (or more appropriately maybe one of the members of the SlickEdit Tools for Visual Studio team will).
Right around this time we started work to add version control support to Visual SlickEdit 1.1. At the time most of the version control systems we had requests to support were very file oriented. You checked a file out, it was locked, you worked on it, and checked it back in. Some of the companies that made these products were actually here in “The Triangle” area of central North Carolina, which was convenient, and almost all of these companies were willing to give you a free copy of their product for support purposes, or do a product swap. In no particular order, these players were Source Safe, TLIB, and PVCS on Windows, and RCS or SCCS on UNIX. Briefly there was a product for Windows called “Microsoft Delta”. It is really hard to find information about at this point. Apparently it was not well received, and Microsoft purchased One Tree, the company that produced Source Safe. (This is not one of those anti-Microsoft rants, just a history lesson). Supporting these products proved challenging because it was tough to create a general purpose framework for all of them, and we felt creating individual support for each one would eventually prove even more problematic. So we put in place a system with configurable command lines that had “parse in parts” and we were off.
A few years down the road, we started getting requests to support a product called ClearCase. It was more directory oriented than file oriented, and actually had its own file system (for its UNIX versions). It was huge compared to these other systems. It also changed hands (or in some cases companies changed names) a few times. We managed to come up with a set of command lines that worked alright for ClearCase, and looked ahead.
Around 1995 Microsoft released a spec for dealing with source control systems known as the “SCC Interface”. It was very file oriented. It supported the concept of a project, but most of the operations that were supported dealt with a single file (checkout, checkin, etc). We started support for this in Visual SlickEdit v4.0. It solved some problems, and created some new ones. Overall it was a good thing. Unfortunately, it kind of disappeared. The interface itself is still in use today, but if you wanted to find a copy of the specs for it, it might prove challenging.
In the late nineties, we had a lot of requests to support a version control system called CVS. It had actually been around for at least ten years at the time. CVS is a very directory oriented system, and I initially had a very hard time wrapping my head around it. We finally had to break our mold and support one system differently, with much customized support. We first shipped the support for CVS with v9 in 2003, but we had been using it internally for some time.
Shortly thereafter, something called “Subversion” happened. It works the same as CVS in many regards, so adding support for it was not that difficult. It is taking some time to “settle down” though, given a combination of changes in Subversion itself and the amount that the interface has been used/tested.
So what does the future hold? I hope to spread something more like our current CVS and Subversion interface to more systems. I hope to do it in a robust manner that does not cause more problems than it solves. Also, I hope not to spend too much time writing features that serve no practical purpose. I hope to revamp our version control integration in a fashion that says “I learned a few things along the way”.
June 28th, 2007 at 10:08 am
Hi Dan,
Not to give you more agony about adding yet another source control system in existence, but ‘git’ is gaining popularity very fast, especially in the open-source world. CVS is dying, and a lot of projects are migrating toward Subversion as a CVS replacement. But many are also considering migrating toward git.
Now, git is neither file-based nor directory-based, but it is content-based. So, it tracks changes such as a function moving from one file to another, because it takes the content of the entire tree as one snapshot, and treats it as one. We’ve been using it experimentally, and personally I love the way it works and it’s darn fast! But it does have a little steep initial learning curve.
There is also a system called Mercurial. I don’t know much about it, but apparently it is Python-based, and the Mozilla project uses it.
July 5th, 2007 at 1:31 am
Yeah, svn/cvs are pretty standard now, usually svn is the preferred version. The new version control systems in town tend to be distributed version control systems – you don’t need an internet connection to have full functionality. Often times there is a central repo, but it’s pretty handy to be able to make quick branches (each working copy can be considered a branch). You also have a full project history, so if the central server explodes, you’re ok.
The above post mentions git and mercurial, which are both good examples of this newer VCS paradigm. Other notables are darcs and monotone.
July 10th, 2007 at 12:05 pm
Hi,
Interesting post. I have used the ClearCase SCC interface since 2003 and it is excellent. You can do almost everything from inside the SlickEdit. And in fact I noticed checkout was faster than from the CC exporer.
I recently came across the e editor (http://www.e-texteditor.com/) which has built in Version control, now I work somewhere without ClearCase this seems like a really great idea. Almost enough not to notice it doesn’t colour my programs – or print
Check it out, another new paradigm.
Dave
July 10th, 2007 at 12:11 pm
Dave – you should check out SlickEdit’s Backup History feature. It is not version control, but is intended for what happens in between version control checkins. Everytime you save a file, the editor keeps a copy (using deltas, so it does not take too much space). The number of backups for each file is configurable.
To see this go to Tools>Options>File Options and look at the Backup tab.
August 22nd, 2007 at 1:09 pm
Anyone know where one can find the “SCC Interface”. I found a reference on it on a Microsoft Site, but it stated that is was only shared with OEM registered customer????
December 22nd, 2007 at 6:29 am
It would be critical for my use if you supported the likes of Mercurial.
Sean