9

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?

janos
  • 1,829
  • 13
  • 30
  • 16
    If you are not branching, then you are not taking advantage of one of the biggest benefits of a **version** control system. – gahooa Sep 03 '12 at 19:11
  • Does your CVCS provide a convenient view of potential update conflicts without modifying your local files? TortoiseSVN has such functionality. – rwong Sep 04 '12 at 00:48
  • discussed before: [How often should I/do you make commits?](http://programmers.stackexchange.com/q/74764/31260) and [git / other VCS - how often to commit?](http://programmers.stackexchange.com/q/110595/31260) – gnat Sep 04 '12 at 08:10
  • @gnat the question is how often to update, not commit – janos Sep 04 '12 at 08:15
  • @janos well your question says "team members commit something every day" - to me it sounds really the same. Someone commits <=> someone updates – gnat Sep 04 '12 at 08:22
  • ...also, discussed here: [What are good source control check-in strategies for large tasks?](http://programmers.stackexchange.com/q/15730/31260) – gnat Sep 04 '12 at 08:26
  • 2
    The question is very specifically about how often to "update". And it is already part of the assumptions that your teammates do in fact commit often. Which is surely a good thing, but in any case not the subject here. – janos Sep 04 '12 at 08:34
  • It's not an answer to *this* question, but another option is to consider using [git-svn](http://www.kernel.org/pub/software/scm/git/docs/git-svn.html) or [hgsubversion](http://mercurial.selenic.com/wiki/HgSubversion) to avoid this problem entirely. – Mark Booth Sep 04 '12 at 09:29

8 Answers8

24

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"
Lieven Keersmaekers
  • 554
  • 3
  • 7
  • 2
    You are right in that it is always a good thing to work on feature branches instead of the trunk. The problem is that most CVCS do a poor job at merging, so most programmers I know on CVCS stick to a single branch most of the time. The question is, can you tell them that in general it is always good to update often? – janos Sep 03 '12 at 20:02
  • 6
    Coming from Sourcesafe *(where we didn't merge at all)* to TFS, git and mercurial *(where we do merge often)*, my personal experience is that merging often creates far less problems than waiting for a big bang merge. I agree that it requires a mindshift from fellow programmers. I'm sounding as a broken record at my workplace but everyone should **commit often and update often.** – Lieven Keersmaekers Sep 04 '12 at 06:41
6

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.

Spoike
  • 14,765
  • 4
  • 43
  • 58
4

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.

janos
  • 1,829
  • 13
  • 30
2

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.

tia
  • 965
  • 5
  • 9
1

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.
Jan Hudec
  • 18,250
  • 1
  • 39
  • 62
0

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.

Andrew
  • 2,018
  • 2
  • 16
  • 27
0

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.

AProgrammer
  • 10,404
  • 1
  • 30
  • 45
  • 2
    In distributed version you can commit your pending changes locally. That way if a merge results in too many conflicts and you prefer to postpone it and roll back, you can. In centralized version control you cannot commit locally, and if you want to roll back an update, you cannot. So the centralized version nuance is important, because the update operation is more risky than a merge. – janos Sep 03 '12 at 19:04
  • 3
    @janos, In my experience, the harder the merge, the more you want to do it now as waiting will never make it easier. I usually skim through the diffs before applying them and I sometimes makes a manual back up if they seem complex. What I've also done was using a mercurial repository to version control the changes I couldn't check in in the official system. I didn't found the benefits warranted the cost in my situation, but it may be different for yours. – AProgrammer Sep 03 '12 at 19:16
  • the update operation in CVCS is less safe because you cannot roll it back the way you can roll back a merge in DVCS. This is why the CVCS part is significant, and the question would make little sense in a DVCS. – janos Sep 03 '12 at 19:32
  • Waiting can't decrease the difficulty nor the risk, so you are arguing for more frequent updates. – AProgrammer Sep 03 '12 at 19:40
  • Yes, I always thought it's good to update often. I want to validate that by looking for bad stuff I might not think of myself. For example if you have a large pending refactor, then maybe you don't want even small conflicts blowing up in your face. I don't know. I just want to make sure I can continue to say "update often" without making an ass of myself. – janos Sep 03 '12 at 19:55
  • @janos, even if I've personal experience with DVCS, I've only worked with CVCS. My ascertainment is that people who delay merges tend to spend more time doing their final merge than me doing all my small one. – AProgrammer Sep 03 '12 at 20:08
  • @janos you can roll back with a CVCS as long as you are properly branching to begin with – jk. Sep 04 '12 at 07:29
  • @jk you can only roll back to something that was committed. You cannot roll back to a "pending changes" state. – janos Sep 04 '12 at 07:35
  • yes which is why you want to be working in a branch so you can commit before merging – jk. Sep 04 '12 at 08:58
0

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479