Personally, I update my local versions daily.

In the scenario you describe, I would go the extra mile by

• Creating a branch for the new, lengthy feature.
• Merge often from the mainline to this new branch.

This way,

• You can check-in daily to preserve your code on the server
• You don’t have to worry about breaking the build by checking-in.
• You can use the repository to undo some work or diff when necessary with earlier check-ins.
• You are certain to be working on the latest codebase and detect possible conflicting code changes early on.

The drawbacks as I see them are

• Merging from main has to be done manually (or scripted)
• It takes more “administration”

Yes, it is a good idea to update often. You update often to avoid difficult merge conflicts and this is the basics of Software Configuration Management (SCM) knowledge with the problem of divergent changes.

This is regardless if it is centralized or distributed; the longer time you diverge from an upstream source (meaning if it is a trunk, branch, or other repository in the DVCS case) the higher the chance of merge conflicts. Yes, nasty surprises from your team may come when updating, but postponing the nasty surprise is even worser (the longer you wait, the less people remember why a set of changes were made).

For updating to work this also means that you and other programmers working on code should never knowingly commit or push upstream code that breaks the build. This is usually why programmers branch (or diverge from upstream in SCM terms), to shield your team members and other stakeholders from having broken code if such a situation inevitably should arise.

The mantra you can use to remember is this: “update, update, update, commit”. Always make sure your changes works with others before committing. This is also to make sure checking out code for the first time works as well.

The 3rd bullet point in the question is simply wrong:

• You are working on a new feature which will surely take several days
  to complete, and you won’t be able to commit before that because it
  would break the build.

If you know you are going to be working on something you cannot commit for some time, that is the textbook example for using branches.

Do not put yourself in the situation where you have a lot of pending changes. If you know you will not be able to commit in your project’s main branch for some time, then work on another branch. And there, commit often.

If you are already in the situation described in the question, then switch to a branch right now, commit your changes and continue working in that branch.

Normally in CVCS it is a good idea to update often. But if you are working on a branch then the question of “update often or not” becomes “merge often or not”. And the answer is yes anyway. Just make sure to commit all pending changes (in the branch) before merging from another branch, to your option to roll back the merge safely if you have to.

I think you should commit more often. If you are going to work for a long time like few days, you should branch your code and work in your branch rather than working directly in the trunk. I know it’s convenient to start working without branches, but it’s not really flexible as you cannot be sure that your update/commit would break your code or not, which ends up to the situation that you will hold your update/commit until you’ve done your job. “Feature branching” is better in the way that you can always commit your code, and just merge back later when you finish.

In the branching strategy, the update is replaced with merging from trunk. From my experience, you don’t need to merge from trunk that often, as the code in something like five days time span would not change much and it’s easier to resolve the conflict once only when you’ve finished.

I actually find it more convenient to use a distributed version control locally. That is, I use git as subversion client. This has the advantages that:

• The local changes are saved before updating, so if I make mistake in the merge, I can always go back and do it again.
• When doing bigger changes, I can save the parts that are finished. That makes it easier to review the remaining changes in progress.
• When I fix a bug during some bigger work, I can commit just that fix, temporarily commit the rest and “dcommit” the fix to subversion while keeping the other work in progress local.

If you are adding a new feature, could you create a new single source file (and a matching external interface header file)?

I am concerned that a “new feature” is having widespread implications? Object orientation may no longer be the buzzword it once was, but there is merit in that paradigm.

That way you could create the framework (external interface, plus stub functions) and commit that then there should be minimal third party effects, whilst you finish the rest of your development?

In the situation you describe I feel it is better to have more smaller source files than fewer, bigger files.

How is it different for a centralised version control than for a distributed one?

In both case you’ll have to check in in a place whose content will have moved compared to what you have started. I don’t see any difference in the frequency of merge from the central repository to you working place (and your project branch is your working place).

I tend to be for the merge often way (at least once a day, I may also merge at some other convenient time for me, or when I know someone has checked in something which impact what I’m working on). It’s far easier to absorb small changes and if you have a problem, people are more helpful when you ask them about what they have just checked in than about what they have checked in one week ago.

BTW, I don’t know what you call “break the build”. I tend to work in relatively small increment, so that I keep a compilable state, even if it breaks some features. And I run the tests so that I know that the merge hasn’t broken something which should have work. Again, it is easier to fix a problem when it is detected early.

It depends on how good you are at “unupdating” when someone else breaks the build. On the one hand, you want to update in as small chunks as possible. Personally, I update almost every time I notice updates are available. On the other hand, if the build breaks and it’s going to take a day for someone else to fix it, you still want to be able to work on your new feature in the mean time.

I’ve worked with version control systems that are very difficult to back up once an update is done. On those, I tend to update only just before I need to check in. With better version control systems, there’s little reason not to update several times per day.