Version-Control

KDE has moved its source from CVS to Subversion, so I updated my working habits and immediately tried to use the new checkout as if only the command name had changed. That worked just long enough to preserve my bad assumptions.

The first practical difference I noticed was that directories and renames are represented deliberately. CVS encouraged me to think mainly in files, with directory changes handled through conventions and patience. Subversion versions the directory tree, making a move an operation the repository can describe rather than a delete and unrelated addition that humans must recognize.

Atomic commits are an even larger improvement. A change touching C++ sources, a header, and build files becomes one repository revision. Someone updating sees the complete change, not an awkward interval in which half of it has arrived. That matters in KDE, where a small API adjustment can cross several files and leave the tree temporarily unbuildable if treated as independent events.

My naive migration plan included copying old CVS administrative knowledge forward. Better to check out cleanly, inspect svn status, and learn the new meanings. Subversion uses a local administrative area to track the working copy, which makes common comparisons possible without contacting the server. It also means I should stop treating those metadata directories as mysterious litter.

$ svn status
M      widget.cpp
A      widgettest.cpp

The output is plain enough to become a pre-commit habit. I review the diff, update, build, test, and then commit one coherent change with a useful message. The tool cannot make the change coherent on my behalf, sadly.

Repository-wide revision numbers also give discussions a compact reference point. They do not replace a descriptive message, but they make it easier to state exactly which tree was built or tested.

No revision control migration fixes project communication. Large commits can still be incomprehensible, and an atomic mistake remains a mistake. But Subversion’s model fits the shape of a large C++ desktop better than pretending directories have no history.

The KDE move is therefore more than administrative churn. It gives contributors a clearer representation of the work they are already doing. I expect some scraped knees while scripts and muscle memory catch up, but preserving relationships between files is worth relearning a few commands.

The Linux kernel suddenly needs a new revision control system, and Linus has started writing one. That sentence sounds like the opening of either an excellent engineering story or a very efficient disaster. I downloaded Git to understand what was actually being built.

My naive attempt was to look for a familiar source-control interface. This first version doesn’t have one. It makes more sense as a handful of low-level programs over a content-addressed object store, plus an index used to assemble the next tree.

A file’s contents become a blob identified by its SHA-1 name. A tree names blobs and other trees. A commit object can point to a tree, identify a parent, and carry metadata. At this stage those raw objects are the useful thing to inspect; convenient names and comfortable workflows haven’t arrived yet.

The index is the interesting bit between the working directory and a tree object. update-cache records paths and their current object names in the index. write-tree turns that prepared index into a tree. It won’t quietly infer a polished commit operation from whatever happens to be in my directory.

I added a small file with update-cache, wrote the tree, and used cat-file to inspect what had been stored. The blob held content; the tree supplied the filename and mode. Changing one file produced a new blob and tree while unchanged blobs kept the same names. That reuse falls straight out of immutable, content-named objects.

I am not ready to entrust ordinary work to it. The commands are young, rough, and obviously aimed at solving the kernel project’s immediate emergency. Anyone claiming the user experience is finished has perhaps enjoyed too much fsck.

Still, the mechanism is compelling. commit-tree can wrap a prepared tree in a commit object, but the machinery remains exposed. It’s a very C-like start: small primitives, explicit input, and an operator who’s expected to pay attention.

For now I’m experimenting in a disposable directory and looking at .dircache/objects and the index rather than pretending this is a finished tool. Two days in, the raw storage model is already worth watching.