SVN and D'Oh.

[swestrup]

Today is a day when I'm going to have to spend a certain amount of time fixing some coding mistakes I made yesterday. I was clearly too tired when I was programming. I found a bug in my algorithm, in that it wasn't compatible with the overall processing structure of the program I was working on.

Rather than fix my algorithm, I spent several hours reconfiguring how the program handled its data. Some of that work was a useful bit of refactoring. Most was just messing around in modules that were best left untouched.

This morning I can see that there is a trivial rewrite of my algorithm which is perfectly compatible with the code's old way of doing things. So, I am going to move a copy of the current program aside, revert it to the previous commit in the repository, and then cherry pick amongst the diffs to see what changes should and should not get propagated.

I can't help but think that looking through diffs by hand was precisely sort of thing that repositories like SVN were intended to eliminate. The problem is that its often a bad idea to commit things that are only half-changed, so one tries to do an entire refactoring in one pass, and THEN commit.

Now, one can create a new branch, refactor with intermediate commits, and then merge the whole branch when one has it working, but this is a problem in that

• creating a new branch is a hassle, as is merging it back in, and
• usually you don't need it.

The problem is that you only find out you needed a private branch when its too late. It starts to make me think that there should be two levels of commit. The 'normal' level just commits to a private branch by default, creating one on the fly if need be. The second level is for when you have things working.

Comments

[sps.livejournal.com]

It turns out that you just need a time-enabled filesystem for your development directory :(.

[swestrup]

Yeah, that had occurred to me to.

[cpirate.livejournal.com]

Creating a new branch in Subversion is actually pretty easy. I mean, there's a couple of steps involved, but there's nothing that can really go wrong, you could script it in about 5 minutes. The problem is merging, which is still a giant pain, even with svnmerge. One place I worked mandated that all changes to the shared branches were first made on a private branch, which were then code reviewed before being merged into the mainline branch. It was just about as nice as you say, except they were using Clearcase, which is much easier to merge than Subversion (and they still had to write a bunch of scripts and tools to make it go smoothly).

What you're describing turns out to be one of the major advantages of distributed version control systems. With a distributed system, once you check out of a repository, you've automatically made your own private branch. Then, you can just check in as you please on your local system, and when you're happy with it you send it back to the server. If you want to play with this sort of thing now, you could look into either svk or git-svn; they both add a distributed VCS interface on top of a Subversion repository.

[swestrup]

Actually, I'm planning to look into svk shortly, as I'm likely to be collaborating on a small project to port PmWiki to using svk as a storage backend.