Fog Creek Software
Discussion Board

Concurrent changes to files under SCM control

Should I be wary of concurrent changes made to files under SCM control?

Software Configuration Management (SCM) programs allow editing the same file by more than one developer at the same time.  When the file is checked back into the archive, a merge must be done so that the both sets of changes are saved.  I’ve always avoided concurrent changes to a file to avoid needing to merge.  Documentation on ClearCase (an SCM tool) looks to me like the concurrent changing of a file is not just tolerated, but perhaps encouraged.

Should I encourage concurrent changes to files?
What success or failures have you had with merging files back into the SCM archive?

Glade Warner
Friday, October 18, 2002

Having a source files open by multiple developers is common.  The key to success is having a capable "merge" tool.  Do not fear concurrent changes and trust your tools.  Personally, I don't like Clear Case because it forces you into branching and merging for every group of check outs (so you are forced into merging with every checkin).  But, if that's your tool, and its what your company uses, then you'd better get used to it.

Nat Ersoz
Friday, October 18, 2002

Generally, better to avoid it where practical. Should not be the norm. If you find you've routinely got > 1 developer actively editing a particular piece of code at the same time, you may want to reevaluate how much code you put in a single file. Our practice here is to keep the individual files relatively small, at least in terms of functionality covered, reducing the likelihood two of our guys would be working on the same piece at once.

I personally do not trust any sort of automated merging, and unless the diffs are very independent and relatively simple, even manually scanning in a diff tool and doing the merge "by hand" is normally an unnecessary extra risk I would not see as worth it compared to just working it out among the developers who's going to edit when.

I wouldn't agonize over it, if you really have to do it sometime, then do it; you should just not make it a common practice. And take what the SCM vendors say with a grain of salt -- their purpose in life it to sell you their stuff, not sit with you and resolve a merge and then through the night with your folks doing testing needed to wring out any oddball new bugs there might be.

IMO, in the ideal world, nobody would ever have to branch or merge - we could  all keep nice, clean, linear code lines. We can't of course, but staying as close to that as circumstances permit will normally simplify your life and reduce your risks.

Friday, October 18, 2002

Oh - one thing I forgot. We do have a fairly small shop, which means merge situations don't tend to arise as often as would probably happen in larger shops.  Well, they don't for us, anyway. So adjust/discard what I said earlier as appropriate to your team size also.

Friday, October 18, 2002

It depends, of course.

What you want to strive for is to have developers working on well-defined orthogonal tasks, and to have code that reflects functional orthogonality in its physical layout.  If both of these things are the case, you will have very few problems with merging.

But closer to reality, you'll have some guys monkeying with overlapping functionality, and some guys doing things they weren't asked to do ("I just did a little clean-up in those files"), and your source code will have lots of loosely related things intertwined so that there may be significant conflicts when attempting a merge.

The point is that there is no substitute for good management and a good code base.  Concurrent development will be easy if you have those things, and possibly a nightmare if they are weak or non-existent.


Robert Anderson
Friday, October 18, 2002

It can be done, but it's not the best approach to SW development.

I currently work in an environment where we do concurrent development using ClearCase.  I don't trust the automatic merge tool for anything other than a trivial merge of a single branch.  Manual merging can be a bit slow and tedious, but it's a lot faster than finding the bugs caused by a bad automatic merge.

When I worked in an environment where each developer was responsible for a particular component or process the whole development process was easier and the code quality was a lot better.

Friday, October 18, 2002

I use Perforce and have NO problems merging concurrently changed files. If your changes overlap someone else's changes, then you must resolve the problem manually.

Zwarm Monkey
Friday, October 18, 2002

I always disallowed concurrent checkout on my projects assuming merging would bring nightmares. 3 years ago started current job where it was normal practice. I was shocked to discover how well it works. I don't think I've ever seen problem where the auto merger left things non-functioning. Less than 10% of the merges require manual intervention. This is with M$ VSS.

I think the key is well structured software and responsible developers. Fortunately we have both. If you have code cowboys or spaghetti code I wouldn't try it.

Friday, October 18, 2002

I do fear concurrent changes and try to organise myself to have exclusive access to anything I'm working on.

It's not the tools I fear, its the human error.

Friday, October 18, 2002

Don't knock it until you've tried it.

No really.  Try it.

Ooops, did I use a cliche on the first line of this note?  Sorry to be trite, but you actually should try it.

Seriously, concurrent editing with merge provided by the SCM tool is something that works surprisingly well.  Once you've actually tried doing it this way, it's amazingly hard to go back.  I remember being a person who refused to trust merge tools.  Now I can't imagine living without one.

Still, people have very, very strong preferences about this particular issue.  Reasoning has little effect on either camp.  I'd be surprised if my advice above causes even one person to experiment with the edit-merge-commit paradigm, much less switch.

We've designed SourceGear Vault (our upcoming SCM tool) to allow the user to choose their preferred style.  This approach seems to work well in our own dogfooding, but I'll be interested to see if it seems as effective to our customers.

Religious battles like this one are an obstacle to building insanely great products.  There is something to be said for letting developers work the way they want to work, if it gets people off the battlefield and back to coding.  :-)

Eric W. Sink
Saturday, October 19, 2002

>> I remember being a person who refused to trust merge tools.  Now I can't imagine living without one.

Yup. It goes against everything I know to be true:  "don't send a machine out to do a man's job".  But, now merging has become a machine's job.  Tough to get used to, but it works.  You should see merging in the hands of our real perfoce expert - very scary, yet beautious... After being around our SCM guy for the last year, I now know the true bar to set all SCM guys by.

I let the machine do the merge, and then review the results (diff's) afterward (using SlickEdit's diffzilla!).  Its less error prone than me coaching the (perforce) tool or doing it by hand.

Nat Ersoz
Sunday, October 20, 2002

The problem with concurrent changes to files is not whether they'll be successfully merged or not by source control, but whether the human monkeys in the system realise its happened and why.

I prefer, for my own sake of maintaining sanity, the concept of owning files and modules.  This doesn't stop multiple checkouts, but checking in should be managed.  The simplest way of managing them is to have the rule that you should check out, and possibly merge, before you check in, and test that result before checking in.

If that process is going to take any appreciable amount of time then those files should be locked until its complete.  This scratches my itch of paranoia and reduces the likelyhood of the build dying because two or more checked in  syntactically valid, but practically broken code in consequence.

Simon P. Lucy
Sunday, October 20, 2002

To me it's a social problem.  When I'm in someone else's code, and I'm not working close with her, I usually just want to open up an accessor or something.  Otherwise I send her a quick email describing what I intend.

It's not the merge that matters, but the fact you may be introducing errors in someone else's code.

Sunday, October 20, 2002

In my experience, the vast majority of problems with concurrent checkins come down to developers just plain not understanding how to manually resolve merge conflicts. Standard operating procedure at my last job was to blame the code loss on bugs in VSS :)

If your checkin conflicts with that of another developer, I think it's good practice to ask them to check you haven't accidentally removed any of their changes  after you've checked in.

Actually, it would be nice if the version control software automatically emailed you every time this happened (ie someone else does a checkin that was merged with yours).

Andrew Reid
Sunday, October 20, 2002

You can generally set watches on files which inform you when they've been changed.

Simon P. Lucy
Monday, October 21, 2002

*  Recent Topics

*  Fog Creek Home