Wanted: Simple, Intuitive Version Control

CVS, CVS-NT, CS-RCS, Code Co-Op, QVCS, Visual Source Safe, FreeVCS, JediVCS and others have all been scrutinized by yours truly, and I’m finding them all lacking in one thing: Simplicity.

I want version control that is as easy as installing a windows executable, pointing at a database (preferably SQL server, since I’ve got several sitting around here), giving it a project name and a project root.

That’s all. That’s all the setup I want to do. I’ve already got OS-based access control working. I don’t want to mess with setting up a web server, or protocols, or repository directory permissions or environment variables or servers and clients or logins.

I want simple.

The “setup” program will create any database structure it needs using the database server and login I provide it. It will offer me a chance to populate it with data from the files in the project directory I specify, but will be perfectly happy not to as well. If I choose not to populate it now, it’ll ask about populating it later – after I’ve left work for the day. I understand I’ll be giving up its functionality until it’s populated. That’s fine. It will establish the “client” program on my machine, detecting my windows logon name and not asking me for info I could detect anyway.

The “server” program will watch the folders under the project root I specify for changes to files (by date/time, size, etc) in as near-real time as possible. When a change is detected, the changed data between the old version and the new version is saved, along with the timestamp of the save operation, and if at all possible – why not? – the author of the change. The “server” has no interface. It can run on the same machine as any of the clients, because they’re all updating the same sql database anyway – redundancy doesn’t hurt.

The “client” program will be a system-tray icon based program will sit on my screen and be silent. It can change its icon to reflect that it’s got info to show me. No popups, no noise, no flashing. Such info (when I choose to look at it) should consist of every changed file since the last time I dismissed that file from the list last time — NOT to include updates based on the initial population. If I choose, I can look at the details of any file in the “recently updated” list – the changed data, the time it changed etc, and I can add a comment to the file — but I don’t have to. Changes can live just fine in the database without explicit owners. Every developer on the project would be running this client app and they’d only have to comment on their own updates, ignoring any others. Files they purposely “ignore” would be noted as ignored by that developer.

The client program will also have a configuration menu, so I could change my logon name if I wanted to, and customze the icon’s appearance, database server, etc.

The client program will also have an optional “explorer” interface I can open – it may even be an external program so it’s not sitting in memory waiting to be used. The purpose of this interface is so I can walk through the file system with the option of seeing notes and history about any file I choose — and also the method through which older revisions are restored — either over the current file, or as a renamed file in the same directory.

There’s no obligatory concept of locking, there’s no checkin/checkout, there’s no mandatory comment system. It’s simple. Unobtrusive. Out of the way. Easy.

Now, IF I wanted to lock a file and thus require checkin and checkout, that’s easy too. I just specify a “lock” flag in the file’s information via the client program. That sets a read-only flag on the actual file. Now any developer who opens the file and becomes aware of the read only setting can use their client icon to navigate to and unlock the file for their use – such unlock/ownership information would be stored in the database. The read only setting on the file STAYS on the file. When the developer wants to save the new file again, they can use the client program to temporarily remove the readonly flag, and re-set it x seconds later. That’d get tedious, but I don’t really intend for locking to be used too much here. If any other developer wants to access the same file while it’s checked out, the client program will tell them who’s got it checked out.

If some bonehead developer goes on vacation without unlocking the file – any other user can force check it in. At this point the file as it exists is saved as a flagged revision (so the vacationing developer can return to it) and the new developer can get on with their work, adhering to the checkin/checkout rules about the file.

All of this is possible with a very simple UI for the developer. Why doesn’t it exist? PS, if you go ahead and create this model, I hereby copyright this idea. Talk to me about getting rights to it — I’ll give them to you free, if you give me some free copies of the program.