What are good source control check-in strategies for large tasks?

Question

The general rule is to keep check-ins small and check-in often. But sometimes the task requires large changes to the underlying framework. Then checking in before compeleting the task will break the project until you check in the finished work.

So what strategies do people use to reduce the risk of losing work, or deciding something you are doing is the wrong approach, then changing your mind after removing the code and trying another approach?

When I can, I'll check-in half done work commented out, or if it compiles and nothing is using new files I'll check them in. The larger the change the more likely I am to branch the project and then merge back when I have everything working again. Another option if the source control system allows is shelf sets, which are basically small branches. So when I finish for the day or come to a decision point, I'll shelve my changes, and then if something catastrophic happens, or I want to come back to that point, I can.

Answer 1

I use git, so my answer is "branch". Branch, and commit piece-meal as you complete the various bits.

Push your commits upstream as you're happy, so your colleagues can review the changes without disrupting trunk.

When everyone's happy with the code, merge and you're done!

(What I tend to do for relatively long-running branches is periodically merge trunk (master, in git terminology) into my branch, so the two branches don't diverge too radically.)

Answer 2

I think the answer is going to vary based on what sort of version control system you're using: centralised (e.g. subversion) or distributed (e.g. git). I don't have any real world experience with using a distributed source control system so my answer is based around what we do with subversion.

If there's a large change in progress which will break our trunk build over a period of time, or that will really disrupt the rest of the team in some other way, then we'll create a branch. I would say though that you should do as much as you can to avoid having to do that - most changes can sit side-by-side with the rest of the code with little effort. For example, you could trigger code paths into the new code (with simple if statements or you could inject the new versions based on config settings if you're using a DI framework). Then when you've finished you just change the the config to the new version, test everything, delete the unused code, test again and finally delete the config setting. You can't always do that but because of the overhead of maintaining a branch I think you should always check if that is possible.

If you do branch I think the mistake that I often see people make is not keeping their branch up-to-date with the trunk. You should be constantly merging changes from trunk into your branch while it exists so that when you've finished the reverse merge of everything back again is fairly trivial.

Answer 3

In out team we use subversion, and we normally commit small changes directly to the trunk. For larger tasks, the developer working on it typically creates a private branch, which is merged into the trunk once it is done. Then the private branch is deleted. Naturally, while the private branch exist its owner should check into it often.

We try to avoid having long-lived branches and trunk-to-branch merges, because that requires careful bookkeeping. Instead we have relatively short-lived branches that are only merged back to the trunk once, and get deleted soon after.

And we have a rule that nothing can be committed or merged to the trunk until at least one other person looks through the changes and approves them.

Answer 4

Just like the usual comment from SQL server people "it depends"

If you can, i would suggest you create a branch on the code so you can continue to apply small checkins of your work. Once completed, perform a merge backinto the main trunk.

Yes there is some chance of reowrk duplication of effort doing this. but at least you will maintian a trail of work you can rollback it it proves to be a dead end.