The Lonesome Cowboy Configuration System

NOW!!! with binary files!!

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 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 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:

This documentation, in which you will find the rest of the installation instructions.
The Lccs package, in an uncompressed zip file, including the pat package.
The copyright statement for the pat package.
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

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?

There's a derogatory term "cowboy programmer" that means a guy (it's always guys, you know) who programs the way he feels like it, disregards all rules and good practices, and won't cooperate with other programmers, much less the really smart people in marketing and management: the kind of programmer whose imminent extinction through better automatic-programming technology has been predicted continuously for the last 25 years or so.

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.

Date last modified: February 19, 2003.
Built February 19, 2003
Dan Drake's Home Page
Mail to
Copyright (C) 1998 Daniel Drake. A royalty-free license to reproduce this document in whole or in part is hereby granted provided (i) all additions, omissions, and other changes are clearly marked; (ii) the work is not reproduced as, or as part of, a work for which payment is charged; (iii) this notice is reproduced without change. Quotations for critical or polemical purposes, with proper attribution, are permitted in any case, being obviously fair use.