I didn’t even notice, but I did the same thing because I had a topic in the queue that was really itching to get out there. Then I started reading through my feeds and I am not the only one on this quality kick. Too awesome! :D

http://ferventcoder.com/archive/2008/06/11/develop-for-maintenance.aspx

My own version control and light backup strategy in this particular situation was to create patch files. Had I expected to take longer on this I would have broken out some distributed version control layered on top of our primary version control or perhaps cut a single-developer experimental branch (which we try to avoid doing because it let people break our rules about not breaking the build, as all branches must have build automation and the build must never break for any of the reasons I noted earlier.)

I’ve been using version control systems for a good fifteen years now and I still have yet to see good justification for treating version control as a backup solution and/or allowing people to make non-atomic and/or breaking commits against the repo. After fifteen years of conflation with backup strategies and work decomposition problems, it gets a little tiring. ;)

I keep things simple for my developers: Commit frequently. Commits must be atomic and never break the build in any of the possible ways. Decompose work and coordinate and collaborate with others to achieve this. For comfort beyond the limits of work decomposition, talk to IT about backup and/or layer on personal versioning (via patches, dvcs, whatever.)

That I haven’t needed to alter the above in fifteen years says something, IMHO.

RE: Checkins: Sometimes you do have multi-day refactorings. It shouldn’t be regular thing, though. Like you alluded to, you should avoid situations where your work spans more than one day before you can commit.

RE: Branches: That’s kind of the point of branches, right? Make sure you merge them back in ASAP expect in a prior-release branch (i.e. the release_1_1 branch for ongoing maintenance of the currently-shipping 1.1 release where Trunk is the soon-to-be-released 1.2 current codebase)

Frequent checkins are a must, but not the kind you described in #5. If your developers cannot check in good-to-go code on a frequent basis, you have a work decomposition problem.

As for checking in on a branch, remember that your version control system is not your backup solution.