Red Mercury Labs

Proposal for Local Commit in Subversion

I would be able to use Subversion to compare these local versions, so “svn diff” would show me the difference between the latest locally committed version and my working copy. I could specify a specific local revision to “svn diff” and get the differences with that revision, all the way back to the head revision that I started with when I disconnected in the first place. For example, “svn diff myfile.c -r541.23″ would compare my working copy of myfile.c with the 24th locally committed version of myfile.c. Existing commands would still work normally, for example “svn diff myfile.c -r541″ would compare myfile.c with version 541, the latest version I got from the actual repository. However, “svn diff myfile.c” could automatically compare with my latest locally committed revision, or alternatively, a “–local” flag could be added in cases like this to indicate when we want to pay attention to local commits.

Even if I’m not disconnected from the repository, these local commits allow me to work incrementally and implement huge, earth-shattering changes, one small step at a time, without bothering anybody else who is using the main repository until I’m done. While working on these large scale changes, I still get the advantage of versioning in small increments by doing local commits.

Once I am ready to commit these local changes to the repository, I would do a “svn commit” like normal. Subversion would automatically do a sequence of commits, starting from my first local revision and continuing through each locally committed revision up to and including my local working copy, applying the commit comments that I had supplied with each local commit. My local incremental changes and comments would then be commited to the main repository and be given real revision numbers by the repository - the local “541.23″ version numbers would go away, but the sequence of revisions would still be preserved. After the commit to the repository, the versions that had been locally committed now appear as individual revisions in the central repository, as if I had been committing directly to the repository all along. All of these commits would be atomic. Multiple local commits on multiple files could be committed in one atomic operation.

I have only been heavily using Subversion for a short time, but I believe adding “local commit” would fit very nicely into the way Subversion currently works. Whether it would be technically challenging to add it, I don’t know, but that is less important than the way the idea of local commits would interact with today’s Subversion. I think local commits could be added in a way that would not change the way Subversion is used at all, and it may even be possible to add it in a way that works well with existing tools that interact with Subversion.

With “local commit” support, Subversion would go a long way towards solving the types of problems that projects like Bazaar-NG are trying to solve. There are a handful of “distributed” version control solutions in the works, including Bazaar-NG, that are trying to create solutions where there is no central repository. Allowing full-featured disconnected work is a major advantage of such systems. However, the advantage of having a central repository can’t be ignored - it defines a central place for all revisions to be integrated. With distributed systems, it is easy to imagine small clusters of developers in sync with each other, but wildly out of sync from cluster to cluster. Subversion plus local commit allows full incremental commits while disconnected, and loses nothing when the actual commit to the central repository is done.

So… will it happen? I suppose it’s my itch, so in the tradition of open source, I should scratch it. But if I’m lucky, someone hotshot with lots of Subversion development experience will have the same itch after reading this and implement it in 10 minutes… if you do, let me know