Assuming that:Your team is using centralized version control.You are working on a larger feature which will take several days to complete, and you won't be able to commit before that because it would break the build.Your team members commit something every day that might change some of files you're working on.Since this is centralized version control, you will have to update your local checkout at some point: at least once right before committing the new feature. If you update only once right before your commit, then there might be a lot of conflicts due to the many other changes by your teammates, which could be a world of pain to resolve all at once.Or, you could update often, and even if there are a few conflicts to resolve day by day, it should be easier to do, little by little.Would you stay it's always a good idea to update often?
In centralized version control, is it always good to update often?
svn;version control;cvcs
Personally, I update my local versions daily. In the scenario you describe, I would go the extra mile byCreating 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 serverYou 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 areMerging from main has to be done manually (or scripted)It takes more administration