The Lonesome Cowboy Configuration System

Lccs is a minimal front-end program for RCS, written in Java, and intended to run without change on any system that supports RCS version 5 or greater. Really, it's a personal toy that fills the gaps in RCS usability as I see them, but it's intended to be useful for groups of a few programmers.

There is now a so-called Beta version that you can download. It's supposed to be fully functional, so far as I intend to implement any function.

However, what's here is badly out of date. Contact me if you want the version with which I'm actually working.

To get the whole package, download lccs125.zip. This package includes the regular expression package "pat" written by Steven Brandt, an old Beta version. You can download the current version from his web site, but it's not compatible with this release of Lccs, so you'll still need the old one that comes bundled.

You can read the documentation here; it's also bundled with the program, of course.

Put the file lccs125.zip in a directory that's on your classpath. Unzip it. (It was made with InfoZip; here's where to get the unzip program if you don't have one that will work. When using an unzip program other than InfoZip, remember to specify that the directory structure is to be preserved.) This will give you four files:

lccs.htm

This documentation, in which you will find the rest of the installation instructions.

lccs.zip

The Lccs package, in an uncompressed zip file, including the pat package.

copyrght.htm

The copyright statement for the pat package.

demo.zip

A small demo of how Lccs works.

I take it that it's obvious that a project of any seriousness at all, with two or more programmers, needs to be serious about source control. But--

Source control for one person?
Configuration management for one person??

In a limited sense, anyway. (And if I'm flogging a dead horse here, because everybody know all this, please skip ahead.) Anybody who has programmed intensively has probably learned that protecting yourself from system crashes (whether by hitting the Save operation occasionally or by having a crash-recovering editor) just isn't enough. Too often you need the version from an hour or two ago, before you started the set of changes that loused it all up. Saving foo.1, foo.2, ... is easy, but it's not enough either.

So you are really better off having RCS or something, and checking in your work at intervals, with even a comment on what's in the current version if you can spare the time from furious coding. Saves disk space, which doesn't matter, and filename space, which does. And with luck and the right RCS command, you can even go back to the state of the whole several-file system as of 2 hours ago or whatever.

That is, you can go back if you're lucky: if you're working on a very small number of files in a very small number of directories, or you're meticulous about entering multiple clumsy commands to save everything at the same time and keeping records of what you've done, or you're just plain lucky in getting back a valid saved state. The purpose of Lccs is to replace luck with something other than hard work and major interruptions of your train of thought.

And have you ever wanted to explore some sidetrack without its leaving a trail of ultimately irrelevant versions on the main line of your archives? Or to explore a sidetrack independent of the ongoing Serious Development?

And of course, there's the matter of going back to some version more than a couple of hours or a couple of days old, and needing to do something to it. This is the one they always talk about in writing up source control systems. I mention it as a reminder that you don't have to be a big production shop to need this, and you don't necessarily know in advance whether you really will need it. (Therefore, providing for it in advance must be easy, or you won't always do it when necessary.)

All of this led me to want a system that makes it easy to handle lots of files in multiple directories, automatically add new source files to the system as they get created, mark a state of the whole system with a label to which a set of comments is permanently attached, and maintain branches of the whole system. CVS, of course, does this, but it gives me a strong sense of wanting more administration that I want to put into it. In return for the admin, it's good at handling much larger groups, but I don't need that. So, in the best Not Implemented Here tradition, here's my system.

General Description

• You have all the source directories for your project in one tree, the working tree. The RCS archives are in a parallel tree, the archive tree, which can be anywhere. It could even be a sub-tree of the working tree, though that's probably a bad idea.
• There's a list of all the files that you want to keep archived. It's legitimate to edit this, with suitable care, but you may never need to do it.
  • For each directory, you can specify a list of wild-card expressions. When any new file matches one of these, the system will ask whether to add the file to the list, or mark it as one that you don't want archived.
  • You can also have global wild-card expressions: files fitting them are candidates for inclusion in the archives when they appear in any directory you're archiving.
• You can keep binary files in the archive as well as text files. Naturally, these can take up an ungodly amount of room, since a whole copy is checked in each time, rather than a set of differences. But disk space is cheap these days, right?
• You can execute the Checkin command from any directory in the working tree; the program will check in all the files.
  • You can give a one-line description that will be attached to each of the files that actually gets checked in. This is inferior to raw RCS because of problems with Java. Some day it may be fixed.
  • You can attach a label to every file in your system (regardless of whether it has been changed recently) to mark the current state of the whole thing.
    • You give the label a multi-line description, which is carried forever by the system.
    • The system can generate a new unique label using a pattern you specify.
    • The system can refresh your memory by showing a list of existing labels, selected by a regular expression match.
• You don't use environment variables to tell where things are. Even if the Java gurus hadn't inexplicably dropped getenv() from the spec, this wouldn't be a hot idea. Instead, the system finds the working tree root starting from the current directory, and finds the archives from data kept there.
• You can check out any version that you've previously tagged, putting it in a new source tree. This is a play version of the code, from which you can't check things in.
• You can check out any tagged version, putting it in a new source tree, and create a new branch for every archived file that exists at that level. Checkins from this new tree go on the end of that branch.
  • As with version labels, branch names are documented with a permanent multi-line comment.
  • As with version labels, new branch names can be created automatically, and existing ones can be listed.
• You can fetch files into your current branch from any other branch or version.
• You can merge any other version into the version in a checked-out working tree.
  • The system will automatically determine common ancestors by default.
  • You can specify ancestry. By clever use of the feature, you can back out changes made a long time ago, just as with rcsmerge.
• You get to comply with the following system requirements:
  • A system with a working Java compatible with version 1.0.x. Of course, 1.1 run-time is fully compatible, right? I'll gladly accept bug reports based on Java incompatibilities, but they're more likely to be posted in the documentation than fixed.
  • RCS version 5 or better. Version 5.7 is highly recommended because of its fake symbolic link feature. (Lccs can set up a text file named RCS in which is the path of the corresponding archive directory; then you can use direct RCS commands.)
  • A file system in which filenames are either case-dependent or case-independent. The system compensates for this, or tries to.
  • A file system that either does or does not accept awful names like veryLongName.java,v. If it can't accept very long names, that's your problem; but it won't defeat Lccs, which will use an RCS directory in the archives and avoid ,v names.

All of the features are now implemented.

This system is not going to try what CVS specializes in: a bunch of people checking in on the same branch. For very small groups my design should be enough.

Lonesome Cowboy?

A columnist (a genuine expert who really should know better) applied the term to the standards-scoffers who programmed Windows® 3 with no parameter checking, so that any program error could crash the system. Cowboys? Shucks, ah wouldn't let that kinda greenhorn carry mah saddle.

My friends will recall that in response to some idiot's published comments about the cowboy programmers at Autodesk®, I wore a cowboy hat to work for my last six months there. But really, you know, some of us are cowboys. If the media have made hacker mean a criminal, why don't we turn the tables by accepting the honorable name of cowboy?

I don't need no stinkin manager to tell me I need a definitive trail of the versions I've shipped, and the interim ones as well. I don't need no stinkin administrators to make it harder to access this stuff, as long as the working group is small. (And, of course, I'm profoundly in the debt of many expert admins who have saved uncounted months of my time by maintaining those systems which necessarily were too big to hack in one's spare time.) I don't need no stinkin software maturity model to know that I need to track bugs; and when that system is in place, it won't fall apart in the ways that the experts know will always happen: all the programmers shoving their bug reports off on someone else just before the deadline when Management gets its database reports. (This allegedly is what forces the organization onwards to the glories of Level 3.)

The news is not all bad. More and more, the experts are noticing that the waterfall model is nonsense for anything that hasn't been done a hundred times before, and not always useful the rest of the time. The cowboys always knew this. The bad news: don't you have the feeling that the frontier has closed, and the cowboys really are on the way out? As in sports, there's now room for a few superstars, but on the whole, maybe the next generation of programmers will be a lot more like salarymen. For what will happen then, consult Joe Hill.

End of manifesto. If this tool is useful to anybody, fine. It's intended as freeware, and I expect to release source if I ever get it into a shape in which it won't be too embarrassing.
 

Document: http://www.dandrake.com/lccs/index.html