Dave's Source Manager

This is a long overdue post to describe an experimental source code manager I'm making for my personal use called Dave's Source Manager (dsm). This domain (code.driusan.net) is primarily used to test serving repositories. It will eventually also be used as an upstream for pushing code, but at the moment is mostly for distributing.

Why an experimental SCM? Why not just use git? Even Plan 9 has git9 now!

Flipping the question around: why stop at git? Why not try other ideas?

The fundamental experiment with dsm is: what happens if you combine a distributed bug tracker with a distributed source code manager?

It turns out, the answer is it solves some of my biggest problems with git.

An attempt to fix a bug in dsm can be attached to a bug as a patch (an attempt to fix a bug in dsm is known as a "try"). Unlike with git branches, patches are not ossified at this point. (Though they are stored in the object store for history purposes.) They can be reviewed, edited, or applied to different branches (called "forks" in dsm) You can even apply the patches from multiple different bugs to a work tree to use them together. This means, for the most part, there is no rebasing necessary while doing development. Unless significant changes stop the patch from applying cleanly, you can always apply the patch to any fork. When there are conflicts, applying a patch is the equivalent of squashing all your changes into a git commit and re-basing it, there is no need for commands such as git rerere.

Another change that falls out of combining the bug tracking and source management is that the workflow is flipped on its head.

In git, you hack away at something, and then, when you're happy with it, describe what you did in a commit message. In dsm, you describe what problem you're trying to solve, try to do it, and then when you're satisfied commit the change. Since a commit is associated with a bug (or rather, a try), there is no need to describe the change at commit time. The bug provides context for why a change was done. (Although a snapshot of the bug description at commit time is stored with the commit for logging/history purposes.) Usings bugs instead of commit messages for context solves xkcd 1296. It also means that features such as git notes are unnecessary, since you can continue to comment on bugs after a solution to them has been committed. The snapshot used in the commit will not change, but further context can be added. It means that (this is theoretical, since I'm the only user) asking people to clean up their pull request description so you can squash it into a commit is unnecessary. If you didn't understand the bug or patch you'd have commented before committing it. When you're satisfied, the comments or thread where you tried to get clarification remain part of the commit's history for the context.

Finally, having a distributed bug tracker as part of your SCM replaces the need for keeping an untracked TODO file or similar for things you you intend to do. When you're hacking away and you encounted a problem, you can create a bug in your local checkout without interupting what you were working on. It is a more lightweight process than a centralized third party bug tracker.

So why an experimental SCM? Why not?