Havoc Pennington refers to some of his thoughts on version control in reaction to my last two posts on version control.

What he describes is very user-interface-oriented, from the perspective of bug and patch tracking as much as version control. It makes for an interesting overlap. Here's a kind of use case he gives:

1. The version control system keeps track of how to submit patches (mailing list, bugzilla, etc.) and has a "submit patch" command. (Prereq: the system has a concept of a patch you're working on for submission)
2. The version control system tracks submitted patches for the maintainer and supports easy review and acceptance/rejection of them.
3. Easy way to have a conversation about any patch (as we do now in bugzilla typically)
4. Allow the maintainer to easily hack on the patch, merge their changes with it, and then bounce the patch back to the submitter for more work - I often want to just fix the nitpicks instead of writing them down, then give someone the patch back to fix the big stuff.
5. Often you want to commit a number of times before you submit a patch officially (sometimes people will make a CVS branch for this). A nice feature would be to avoid the need to do this manually; just have the developer tools automatically "commit" every time you save from the editor, or even make the whole undo buffer persistent. Much more plausible with monotone than with CVS.

I can imagine doing this entirely within version control:

1. The version control system makes branching really easy. You start editing your checkout, and then there's a kind of "commit as branch" command. If it's a distributed system then there isn't really anything like a "checkout" (which is fine), but something more like "upload as branch".

2. Perhaps simply by filename convention, tracking is part of the version control system. So if you wanted to submit the patch for review, maybe you'd put request-review.txt in the system, with a note of explanation (what the branch accomplishes or fixes).

   The entire repository, with all branches, should be well indexed. It should include workflow-related concepts. This could be as simple as text tags indicating status that are manually edited.

   Thinking a little more -- tag the branch "for-review" (this is not like Subversion "tags"; more like setting a Subversion property). Add a property "author" that has your information. Another property lists people who are interested in being notified about changes to the branch. Another rule notifies maintainer(s) that something has been submitted. And an indexer displays what branches are in what states (for-review, in-review, rejected, accepted, etc).

3. The conversation takes place in more text files. Maybe the VC frontend handles the formatting. Or not, whatever.

   In addition to indexing there's notification. You can register your interest in a branch. Maybe an email gateway for these conversations, where the conversation is appended to that discussion file. It's like the Talk: pages in Wikipedia.

4. Good merging tools make it easy to bring together branches.

   When you want to change a patch but submit back to the author for further changes, you just edit their branch. Non-authoritative branches (like those that are submitted by non-maintainers) are editable by everyone. You could even simply add comments inline to the code about issues you see with the changes.

   I think the ability for maintainers to edit non-trunk (and non-official-branch) code is a really important way to communicate with contributors. And for contributors to communicate with each other; this shouldn't be a wheel-and-spoke system centered around one integrator.

5. Autocommit is a separate issue, I think. It would be fine if an editor did this, but it's not something that screams out to me.

   History is more easily available if everything is a branch, not a patch, and branches have history and you can continue development on them without being merged into the trunk.

This doesn't really address issue trackers. Issue trackers are lists of problems without solutions, and source control typically holds solutions. If the version control (or maybe just the tools built around it) was really powerful, then potentially it could be a backend for issue tracking, where "issues" are special files or directories. But the workflow for issues is typically much more automated and structured than for generic "source".