Related
I recently joined the IT department of a big insurance company. Although the department's title is "IT", a lot of code gets written here; Java, JSP, JavaScript, COBOL and even some C++ from what I've heard. All the programs that allow insurers, brokers and the rest of the tie-wearing, white-collar workers to issue new contracts and deal with clients runs on the code produced by this department. I've been told that the department is pretty good by the parent company's standards and that we've even received an internal award or two. We're 17 people in the department, split in smaller groups of 2 or 3. As you might've guessed from the COBOL part further up, the average age is over 40 years (as a point of reference I'm 29 yo).
Right now, there is no version control system in place (there exists a general backup scheme though). When needed, files are passed around through shared folders. Usually there's one person in every group responsible for copying the "final" version of the files back to the production server. I find this absurd and even a bit dangerous.
How may I try to convince management that we should implement a VCS scheme in our department? I've never deployed a VCS myself but every other place I've worked at had one. I think I'll hit a "we've been OK until now, why bother" wall from the first step, coupled with the age of most of my co-workers that will feel this step is an unnecessary hurdle.
I know the basic advantages of VCS (traceability, granular backups, accountability etc). I'm looking to back my case with realistic cases and examples of real added value over the implementation costs, not just a "but-but-but, we must have a VCS you fools!" :-)
You don't necessarily need their permission.
Install svn on your machine, start using it, and then start convincing your fellow team members to use it too.
Then watch and see what happens.
Edits
The basic idea of this is that it's easier to show than to tell.
It's a great idea to support your ideas with a working implementation/solution.
Of course, if you succeed, and they want the system used department/company wide, you must be prepared to support the transition, know how the software is to be installed and used.
Going ahead and using something accepted in the industry is faster than having discussions on what system should be used.
There is a good change that this will get you noticed. You may also get your peers respect and support.
As suggested, the same approach can be made on other areas:
issue/bug tracking systems
quality tools
time tracking
continuous integration
a wiki for knowledge base, HOWTO's, guidelines, tutorials, presentations, screencasts
different IDEs and tools
build tools
automated deployment
various scripts that would save your team time
.. any item that will visibly add quality to your work, but doesn't (yet) disrupt existing methodologies and practices.
Joel Spolsky has an excellent article: Getting Things Done When You're Only a Grunt
Quote
Nobody on your team wants to use
source control? Create your own CVS
repository, on your own hard drive if
necessary. Even without cooperation,
you can check your code in
independently from everybody else's.
Then when they have problems that
source control can solve (someone
accidentally types rm * ~ instead of
rm *~), they'll come to you for help.
Eventually, people will realize that
they can have their own checkouts,
too.
Management? I will put bold the expressions and words you should use:
Your should display some examples how a VCS will prevent losing money to the company if some error/bugs or disaster happens. It will be faster to solve all problems, so maintaning the systens won't be so lazy and people become more productive.
You should also mention that implementing a VCS has no costs.
VCS will also give advantages for backup all the existing code. So, all the code will be safe.
My opinion on how to go about doing this, is that you should try to convince your fellow developers first. The way I see it, there are two ways this might go about:
You give the right arguments to the other developers (possibly only the head developers will suffice), they like the idea, and the suggest it to management. Management is easy to convince at that point, so everyone is happy.
You give the right arguments to management, who get all excited (great!) and mandate that version control has to be installed and used by everyone. Here's the thing: If at this point the other developers are not sold to the idea already, then (a) they might be hostile to an idea that management is forcing upon them, and (b) they might not like you for being the cause of it all.
So what are good arguments to convince fellow developers? As someone who uses subversion (which is the one I recommend in this case, by the way) even for his solo projects, here's a few advantages I can think of:
Using version control forces people to think of code modification in terms of a series of small, self-contained changes. This is an extremely beneficial way of working: where otherwise people would be inclined to make lots of changes all over the place, leaving the code in a mess, version control kinda forces them to change the code in bite-size, easy-to-swallow bits, keeping the code compiling at all times, easing the cost of integration with other modules, etc.
Version control makes it very easy to see what has changed in the code each time. This might sound trivial, but when you start modifying code it's easy to lose track after a while. But with VC it's all an "svn diff" (or equivalent) away, always.
Version control makes it very easy to see who has changed the code each time. So that, for example, when something breaks, you know who to blame. (It's not an accident that the subversion command which shows who last changed each line is called "svn blame".)
Version control makes it very easy to see why a piece of code was changed. Commit messages, if used properly, essentially provide continual documentation of the ongoing development process. Documentation that otherwise wouldn't be written.
Version control makes it very easy to track down regressions and see where they appeared. In the easy case, you just track down commit messages and spot the culprit. In the average case, you have to consult the diffs too. In the hard case, you have to do regression testing of previous versions using what amounts to binary search, which is still better than the no-VC case, where you simply have no clue.
This list is not exhaustive, of course, but these are the main benefits that come to mind right now. Obviously, as others have already mentioned, it's easier to show all this to your colleagues than to describe it to them, and setting it up for yourself first (but importing everyone's code, mind) sounds like a great idea.
As Joel points out on one of his articles, start using your own one man version control system and market its benefit on every opportunity you get. Show them the benefits of traceability, granular backups etc from your single instance. People will start realizing its benefits irrespective of their age.
I agree with the answer that are referring to the Joel Guerrilla article.
Install/Use some thing with a low overhead. Hg (Mercurial) is easy in a mixed eniroment and is good because you can bail out and use something else in an easy way.
You must share your things without making a fuzz about it. When someone needs your code, export it and use the "standard" corporate method (shared folder or whatever)
When you get code, always import it into a repos, if you think it is a new commit of a repos you already have, try to get it into that one.
Sooner or later you will have a code for several project and hopefully some commits on some repos. Then you can expose those with the mercurials webserver interface (hg serve -p XXXX).
When the times comes when someone don't know why something suddenly don't works as it should be and is trying to figure out why becase it was working last monday ... and you know that you have that code in a repos step up and ask if you can be of any assistance. Get the falty code, commit it into your repos and expose with hg serve. Look at it in the browser.
My point is that you must prove with real cases to your colleges that this stuff has a value.
If the haven't figured it out by themselves after some many years you have a mountain to climb but it can be done. You must be patience though. It could very well take a year to convert one man (old dog). If you have any younger coworkers try to do this together, the more code you can get hold on the better.
I would point out the hazards of not having one - lost code, developers over writing each other changes, ability to rollback problems, etc.
Also since Subversion and some others are free, point out there is no real cost to purchase, jsut the time to implement.
The biggest issue you will have as the new guy is that you will be seen as rockign the boat, if they had no issues to date they will be hard to convince. Perhaps start using it locally jsut for yourself and maybe they will like what they see and start to adopt it.
I would try small steps, maybe ask the others if they ever used one, point out the benefits, when an issue arises that a system would have prevented or aided in point it out delicately.
From a purely business perspective, and depending on the size and nature of your parent company an IT auditor may consider your lack of a VCS a finding (i.e. something that needs fixing). I believe you could improve your pitch to management by telling them that any CVS is a great way of showing that your department respects its resources and works in a structured way and efficient way, something auditors always like to see.
I don't know how your corporate culture works but I'd be careful about rolling out your own CVS since if it does see use it suddenly becomes your responsibility when things go wrong, even if you were not at fault. To cover your ass (and keep the aforementioned auditors even happier) I'd roll the system out with a full set of written procedures for its use and maintenance.
Finally while I myself am a big fan of initiative at any level of the enterprise don't expect people to remember to say thanks when they figure out how great it is. Some might, but for the most part you're doing this to make your own life easier and for your own karma.
Remember, there are plenty of version control systems that are absolutely free. And the amount of time spent installing and maintaining a version control system should be somewhere near 0 (they shouldn't require any maintenance). There isn't even a space penalty for most systems, as they can compress things internally.
You have listed some advantages, and there are others. But more importantly, I can't think of a single disadvantage.
I would also recommend starting with implementing VCS (Version Control System) for yourself first. I'd recommend using one of distributed VCS (Git, Mercurial, Bazaar) rather than centralized Subversion, because it would be easier to create central repository (or repositories) by cloning than moving your Subversion repository to central place. Distributed SCM can be also used in a smaller group to exchange ideas.
A few advantages of (modern) version control systems:
You can always revert (go back) to last working version of your code (provided that you follow some sane version control conventions, like at least tagging only tested code). With code shared via folders it might turn out that no one version works, backup copies were deleted to save space, and recovering code from backup is tedious / was never tested.
You can switch between working on some new feature (some experimental work), and working on urgent fix in currently deployed version (maintenace work) thanks to branches (and stash / shelve for uncommitted work).
If you follow good practices for version control (small and often commits, changes being about one single thing, writing good commit message describing change and whys of change) you would have much, much easier finding bugs, be it by bisecting history to find which change introduced bug, or by using version control system to look up who was responsible for given area of code (annotate / blame).
Start talking to the other developers about problems thay have had in the past as a way to get to know the system and how it evolved (sneaky, sneaky, sneaky, but hey this information will probably come in handy at some poitn even aside from the version control issue). You are bound to sooner or later find some wonderful examples of things that have already happened which would have been far less painful if you had version control. Use these examples when you present the idea to management.
I agree with the idea that you can probably start using your own version control and eventually will be able to help thm out of a fix, but I'd bet money they have been in some of those fixes already and if they already remember how painful the problme was before, it will help sell the new idea.
Look for another job.
Seriously.
There are way better jobs out there that don't require you to teach the existing staff.
Ones where you could go into work and just, y'know, work.
Also, keep in mind that 30 isn't far off. That's the age at which most people
stop suffering fools gladly.
Just a heads up.
EDIT
It's been suggested that quitting a bad job is for quitters.
Maybe so, but keep in mind that you're supposed to
put your employer to the Joel test before you accept the job, not after.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
What arguments can be used against using zip files of source code as a form of version control?
In general each developer is working on their own program and has a responsibility for it. But there are times of course when other developers are involved in work on that program.
Each developer has their own naming convention for zip files ranging from appending the date, a number after the program name or even appending _old / _oldold _newversion etc… When there is collaboration on development of some code. It has to be checked who has the ‘latest’ version of the code – and where it resides, usually the correct version is identified.
There is no easy existing method to diff source trees and during development unwanted changes occasionally slip into code.
The zip file corresponding to software releases that have release to manufacturing are archived. This at least adds some traceability.
Also before RTM there the code is peer reviewed against the previously released version so quality assurance does exist.
Are there any formal white papers explaining the advantages of source control, making clear that the above isn’t a fully valid form of source control? Arguments exist here that since the end product (manufacturing releases) are under control and these are reviewed that there is no problem with the process. Developers do not have too much of a problem working with zip files in this way, but may not be aware of the advantages.
Creating and managing zip files is error-prone.
Real source control gives you tools to understand your code:
History browsing
Diffs between revisions
Annotation of source files to track the origin of a change
Real source control isn't difficult, there's lots of help out there.
The best argument is surely that using a version control system like Subversion or Mercurial is much, much easier and more secure than messing about with zip files. I doubt there has been much paper writing on the subject, as the use of
zip files for this purpose is fairly obviously wrong.
There are a number of SO questions on the general advantages of version control. For example How can I convince my department to implement a version control system? and https://stackoverflow.com/questions/250984/do-i-really-need-version-control
I assume you currently work at a company that practices this method of zip control, and you're looking for ammunition to help you change this practice. There are a lot of questions on StackOverflow about source control, and the community here are in near-total consensus on the benefits of proper source control and the horrors of working without it (for very good reason).
I'll add something here to benefit your battle: YOUR COMPANY IS #$#%&$## CRAZY!!! ZIP FILES??? ARE YOU ##$##% KIDDING ME???
I am assuming that this question was asked because the original poster is working in an office where the standard practice is to share zip files.
Zip files are obviously bad, for the reasons given by Ned Batchelder. The biggest reason I would suggest is that it's clunky, and difficult to merge changes, or get diffs between past revisions easily.
I would recommend you read A Visual Guide to Version Control for some good arguments about why version control systems are very useful, and a superior way of managing code.
I suspect there'll be as many white papers comparing zip files to proper source control as there'll be white papers comparing cutting one's genitals off with a rusty butter knife with buying a puppy.
Zip files work as a very basic form of version control. It's a way to separate "states" of the source. However, it's not a good form of version control because you have to do a lot of work to perform basic source control management tasks. For example:
Bob's team is working on a major feature that requires changing dozens of files. He works in his own private zip-controlled area for a while. He's created 30 new files, added features to 12 existing files, and made changes to existing behavior in 3 existing files over 4 months. How do you merge Bob's work with the main trunk that has also evolved over the last 4 months? Do you hand-diff thousands of lines of code and decide how to merge them? How do you ensure that anything that uses the 15 existing files isn't broken? How do you ensure that Bob's features or main trunk features aren't accidentally omitted?
Alice is investigating a bug in her code and realizes that one of Sam's classes has changed its behavior. Sam says he didn't make the change. How does Alice find when and why the change was made? How does Alice know who depends on the change?
A major customer has reported a bug in an older version of the program. This customer needs a fix and is important enough to warrant a patch. How do you add the code to the old zip file in a way that it also exists in the new files? Also, how do you record that there is a relationship between the two changes?
These are just three scenarios that a version control system handles well. Situation 1 is handled by development branches. Almost every version control system has a notion of branches that can be developed in parallel and merged as needed. Situation 2 is easily addressed by any source control system with a "blame" feature and less easily addressed by just searching commit logs. Situation 3 is a variant of situation 1, but when you merge branches most version control systems make a note. For example, you'd make a branch off of the old version, fix the bug, then merge that branch into the new code. Now when someone asks "Where did this change come from?" they see it was merged from the patch branch and the change was made to fix a bug.
By the way, I've been in each of these 3 situations and used both SVN and Perforce; both made finding a solution very easy.
These people already know all the arguments for SCM, there is nothing anyone can say to them that will sell them on it. These things must happen:
You install SCM on your local machine and use it. If you must, have it autogenerate these .zip files at every build, so no one outside your cube knows the difference.
Some kind of disaster occurs, like loss of work, show-stopper bug is re-introduced or some other worst-case scenario that is the real reason we all use SCM (the other features we learn to appreciate later).
You are unaffected by the disaster, and/or use your personal copy of the code in SCM to fix the problem/recover the lost work/whatever.
You are a hero and everyone wants to know how you did it.
Only by experiencing firsthand the pain of loss caused by poor SCM practices will your organization realize the benefits of SCM. You're smart enough to learn from the mistakes of others, but not everyone is. The rest of the time, you'll just be 2/3X more productive than the rest of the team and maybe, just maybe they'll wonder how.
By the way, this is how you get agile, continuous integration, unit testing, etc into the organization: lead by example.
The ZIP solution requires a pro-active step at the end of the development cycle when things tend to get dropped because no one outside the dev group notices when they doesn't happen. Sort of like that final code cleanup you always plan on doing when things slow down.
An SCM integrated into the dev environment pretty much enforces/encourages keeping a version history with a small amount of effort all the way through the process. This makes it more likely that a version history will actually be created.
On Using ZIP as a SCM
I'm not going to take as hard of a line as some of the others on the ZIP file solution. It is at least better than nothing. It is a perfectly valid way of keeping version histories, it is just a lot more labor intensive, error prone, and lacks a lot of useful features.
Know who you are selling to
Someone in the Dev Group: Focus your arguments on features like ease of troubleshooting by using change histories, safety to experiment with big code changes (because of rollback), and avoiding accidents where work is overwritten by other developers.
Non-Tech Managers/Bean-counters: There are free/low-cost tools that will reduce the labor cost of version control and give greater accountability/transparency into what each developer is doing/the source of coding mostakes.
I wrote a Version Control tool long ago for a company who did the authoring for DVD titles. Before that they had nothing, just a directory full of clips, icons, scripts etc. which anyone could hack away at, and no way to backtrack if it went wrong etc. HOWEVER these people were 'artists', not programmers, so they could not (would not???!) be trained to use a decent Version Control system. So as a bare-minimum, get-out-of-the-mud level tool I wrote a utility which zipped up the current state of the directory, gave the Zip a meaningful name (date + comment supplied by user) and stuck it in a Backups directory, and also allowed you to restore one of these backups.
So zips CAN provide minimum-level version control, and I speak as someone who endorsed that approach when it was right for the skill-level (in terms of programming, I don't want to imply that they couldn't manipulate pixels!) of the people using it.
But as a programmer, you should be thinking to use a tool which really helps you. As such you want to be able to compare differences for individual files, compare differences between complete milestone sets, and (if you are working on anything other than trivial programmes) handle branching and merging. If you want these features you need something BETTER than zip files.
I used to use ComponentSoftware RCS, and if it wasn't for its poor performance over a WAN we might still be using it: it is cheap (even free for single-developer use, in which form I used to use it at home) and simple to use. However nowadays I would suggest looking at SubVersion. It is very flexible, reasonably simple to understand, has a good set of Windows tools to make it even easier (e.g. Tortoise, Ankh), and ... best of all ... you can get it running for free.
It's not good as only creating a zip before a release means loosing a lot of power you get with version control.
Useually you should check in to the repository after you have added/removed/changed a functional aspekt. So that you can go back later when an error occurres that you think migth be because of this change. Or when you say "dammed this worked before the file format changed in someday in march." Naming revisions after changes makes it also easier to remember because you forgot what was done on 27 march 2009.
In general each developer is working
on their own program and has a
responsibility for it. But there are
times of course when other developers
are involved in work on that program.
In a normal development shop, this is not at all true. Different people work on the same source code all the time. XP makes it almost mandatory. Even if you separate the code into modules, there will still be interaction points with code that concerns at least two programmers.
Of course, it's almost impossible to collaborate without major problems if you don't use source control. But the scenario you describe is much more a way to adjust to this limitation than a sane project structure.
Having only a single person working on a module means that nothing will happen when that person is on vacation and you have a major problem when he leaves the company, gets sick for a long time, or dies.
How do you do a merge? How do you do an annotate? How do you bisect? Where are changelogs stored? Just go to wikipedia and look up "Version control" and go down the list: zip files can kind of sort of do about 2 things out of the whole page.
This is like asking "What arguments can be used against shorthand as a form of double-entry bookkeeping?". It's a completely different thing.
For arguments, there's Walter Tichy's original paper on RCS.
For missing features, among many others there's the ability to merge changes from different versions. This is especially well supported by tools like git and darcs, and to a lesser extent mercurial.
P.S. To Mercurial fans: the problem is that Mercurial delegates the merge process to external tools, and it's very difficult for the mercurial novice to know which tool to use, or to understand how they work—the mercurial model of merging seems far more powerful than others but correspondingly difficult to get a grip on.
I haven't seen an answer include Eric Sink's Source Control HOWTO, but it's a valuable reference. I haven't seen any formal white papers on version control, but I'm not sure the argument about "validity" is your strongest one. The problems you describe in your question indicate some pretty serious drawbacks with the current approach. If "the powers that be" in your environment aren't convinced by that, change the argument entirely.
If you make it a question of quality control, and point to continuous integration as a practice that encourages it, then the zip file approach to version control isn't a "not fully valid form of version control", but an obstacle to implementing continuous integration as a practice.
Your question doesn't indicate whether or not the end product "under control" is tested in any automated fashion (in addition to being reviewed). If the process you describe would prevent that from taking place as well, certainly add that to your argument too.
I think your best argument is showing a GOOD form of source control and showing how powerful it is. Don't trash what is currently being done (as someone is surely emotionally attached to that). You don't want to trash the "ZIP Source Control Method." Show the power of something like SVN. Make it very easy to explain. Show common use cases. (A solid demo would help.)
Let the source control version sell itself.
I use version control extensively. When I'm working by myself, I still use it, and find many good things about it. I know I'm 'supposed' to put in good messages etc, but find that usually the date of a commit and all the tools for checking diffs etc are enough. I often end up putting in junk messages like 'changes'.
I guess this is a weird question, but, what do others use as their log messages when they're making commits in repositories that only they are using? Is there any problem with not leaving messages?
I happen to use git, but this question is more general.
For me it depends on the nature of the fix. Sometimes, its just one word. "Backup", or "copy changes". However, if something that caused me a lot of grief, I'll document my changes a lot more extensively. If it is open source and I won't be there all that long, I document my changes very extensively. svn -diff ( and then document all my changes that way...:)
Bug fixes that are identified by a number in another system, need to be in the change log.
I'll, grant you that "Fixed bug" isn't very good in the change log, but if it a simple bug then maybe that will do.
I don't think there is a good and fast rule, but your entry should be proportional to the amount of time you spent doing the code. A copy change? spelling mistake? not that much of a message needed.
Did you spend 2 hours fixing a bug? Yep! Long commit message.
I'm a solo developer using version control as well. I recently started using an issue tracking system that monitors the messages, so mine have gotten better and at least reference an issue number when there is one. The rest of the time, I try to at least generally state what areas changed in a short sentence or two.
But every once in a while, I still get lazy (or am half asleep) and type in things like "fixed a bug".
You should put in messages as meaningful as those you would put into code that has multiple developers. There's usually little difference between someone else looking at your changes in a couple of days, and you looking at them 12 months down the track. There's a good chance, in both those situations, that the person looking will have no idea why the change was made :-)
I even go so far as to use proper change control, even for the stuff I do solo. That means every change to the code base has to have either a change request or a bug report (with full documentation).
That makes my life a lot easier when I need to understand why something was done. I've got better uses for my "wetware" than trying to remember every little change and why it was done. Far better to let the machine remember it - its memory is so much better.
And, in my opinion, if you can't be bothered doing it right, don't do it at all. Just revert to the cowboy-coder mentality and save yourself some effort.
Doing it right doesn't take that much extra effort and the rewards are substantial. It all comes down to a cost/benefit analysis.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Ok, here is something that has caused some friction at my current job and I really didn't expect it to. Organized in house software development is a new concept here and I have drawn up a first draft of some coding guidelines.
I have proposed that "commented out" code should never be checked into the repository. The reason I have stated this is that the repository maintains a full history of the files. If you are removing the functional code then remove it altogether. The repository keeps your changes so it is easy to see what was changed.
This has caused some friction in that another developer believes that taking this route is too restrictive. This developer would like to be able to comment out some code that he is working on but is incomplete. This code then would never have been checked in before and then not saved anywhere. We are going to be using TFS so I suggested that shelving the changes would be the most correct solution. It was not accepted however because he would like to be able to checkin partial changes that may or may not be deployed.
We want to eventually get to a point where we are taking full advantage of Continuous Integration and automatically deploying to a development web server. Currently there is no development version of web servers or database servers but that will all be changed soon.
Anyway, what are your thoughts? Do you believe that "commented out" code is useful to have in the repository?
I'm very interested to hear from others on this topic.
Edit:
For clarity sake, we don't use private branches. If we did then I'd say do what you want with your private branch but don't ever merge commented out code with the trunk or any shared branches.
Edit:
There is no valid reason we don't use private or per user branches. It's not a concept I disagree with. We just haven't set it up that way yet. Perhaps that is the eventual middle ground. For now we use TFS shelving.
There may be others with different experiences, but in mine checking in half-finished code is a horrible idea, period.
Here are the principles I have learned and try to follow:
Check in often - at least once, but preferably many times per day
Only check in complete functionality
If the first and second conflict (e.g. it takes more than a day to make the functionality work) then the task is too large - break it into smaller completable tasks.
This means:
Commented-out code should never be checked in since it is not functional
Commenting is not a valid archival strategy, so whether it's code yet-to-be-finished or code that's being retired, commenting and checking in doesn't make any sense.
So in summary, NO! If the code is not ready to go to the next stage (whichever that is for you: IntTest/QA/UAT/PreProd/Prod), it should not be committed to a trunk or multi-developer branch. Period.
Edit: After reading the other answers and comments, I'll add that I don't think it's necessarily a good idea to ban commented code (not sure how you'd enforce that anyway). What I will say is that you should get everyone on your team to buy in to the philosophy I described above. The team I work on embraces it wholeheartedly. As a result, source control is a frictonless team-member, one that helps us get our job done.
People who don't embrace that philosophy usually cause broken windows and are often frustrated by source control. They see it as a necessary evil at best, and something to avoid at worst; which leads to infrequent checkins, which means changesets are huge and hard to merge, which compounds frustration, makes checkins something to avoid even more, etc. This is ultimately an attitude thing, not really a process thing. It's easy to put up mental barriers against it; it's easy to find reasons why it won't work, just like it's easy to find reasons not to diet if you don't really want to. But when people do want to do it and are committed to changing their habits, the results are dramatic. The burden is on you to sell it effectively.
"Never" is rarely a good word to use in guidelines.
Your colleague has a great example of when it might be appropriate to check in code that is commented out: When it is incomplete and might break the application if checked in while active.
For the most part, commenting out dead code is unnecessary in a well-managed change-controlled system. But, not all commented code is "dead."
One case where I leave commented out code:
// This approach doesn't work
// Blah, blah, blah
when that is the obvious approach to the problem but it contains some subtle flaw. Sure, the repository would have it but the repository wouldn't warn anyone in the future not to go down that road.
Commented out code should never be checked-in for the purpose of maintaining history. That is the point of source control.
People are talking a lot of ideals here. Maybe unlike everyone else, I have to work on multiple projects with multiple interruptions with the "real world" ocassionally interrupted my workday.
Sometimes, the reality is, I have to check-in partially complete code. It's either risk losing the code or check-in incomplete code. I can't always afford to "finish" a task, no matter how small. But I will not disconnect my laptop from the network without checking-in all code.
If necessary, I will create my own working branch to commit partial changes.
I would certainly discourage, strongly, ever checking in commented-out code. I would not, however, absolutely ban it. Sometimes (if rarely) it is appropriate to check commented-out code into source control. Saying "never do that" is too restrictive.
I think we all agree with these points:
Never check dead code into source control
Never check broken (non-functioning) code into source control, at least never to trunk and only very rarely to a private branch, YMMV
If you have temporarily commented something out or broken something for debugging purposes, don't check the code in until you restore the code to its correct form
Some of are saying there are other categories, such as temporarily removed code, or an incremental but incomplete improvement that includes a small amount of commented-out code as documentation of what comes next, or a very short (ideally 1 line) snippet of commented out code showing something that should never be re-added. Commented-out code should ALWAYS be accompanied by a comment that says why it is commented out (and not just deleted) and gives the expected lifetime of the commented-out code. For example, "The following code does more harm than good, so is commented out, but needs to be replaced before release XXX."
A comment like the above is appropriate if you are delivering a hotfix to stop a customer's bleeding and you don't have the immediate opportunity to find the ultimate fix. After delivering the hotfix, the commented-out code is a reminder that you still have something that needs fixing.
When do I check in commented-out code? One example is when I am tentatively removing something that I think there's a high probability will have to be re-added in the near future, in some form. The commented-out code is there to serve as a direct reminder that this is incomplete. Sure, the old version is in source control and you could just use a FIXME comment as a flag that something more is needed. However, sometimes (if not often) code is the better comment.
Also, when a bug is fixed by removing one line (or more rarely, two lines) of code, I'll sometimes just comment out the line with a comment to never re-enable that code with a reason why. This sort of comment is clear, direct, and concise.
Rex M said: 1) Only check in complete functionality, 2) [If] the task is too large - break it into smaller completable tasks.
In response: Yes, this is the ideal. Sometimes neither option is achievable when you are working on production code and have an immediate, critical problem to fix. Sometimes to complete a task, you need to put a version of code in the field for a while. This is especially true for data gathering code changes when you're trying to find the root cause of a problem.
For the specific instance being asked about in the more general question ... as long as the developer is checking commented-out code into a private branch that no-one will see but that developer (and perhaps someone the developer is collaborating with), it does little harm. But that developer should (almost) never deliver such code into trunk or an equivalent. Trunk should always build and should always function. Delivering unfinished code to trunk is almost always a very bad idea. If you let a developer check unfinished or temporary code into a private branch, then you have to rely on the developer to not forget to scrub the code before delivering into trunk.
To clarify in response to comments to other answers, if code is commented out and checked in, my expectation that the code will function if uncommented drops with the length of time the code has been commented out. Obviously, refactoring tools will not always include comments in their refactoring. Almost always, if I put commented-out code into production, the code is there to serve as a refined comment, something more specific than prose, that something needs to be done there. It is not something that should have a long life.
Finally, if you can find commented-out code in every source file, then something is wrong. Delivering commented-out code into trunk for any reason should be a rare event. If this occurs often, then it becomes clutter and loses its value.
I think never is too strong a condition.
I tend to comment out, checkin, run the tests, have a think and then remove comments after the next release.
In general, checking in commented-out code is wrong as it creates confusion amongst those who are not the original author and need to read or amend the code. In any event, the original author often ends up confused about the code after 3 months have passed.
I espouse the belief that the code belongs to the company, or team, and that it is your responsibility to make things easy for your peers. Checking in commented-out code without also adding a comment about why it is being retained is tantamount to saying:
I don't mind if you end up all
confused over why this stuff is here.
My needs are more important that yours
which is why I have done this. I do
not feel any need to justify
to you, or anyone else, why I have
done this.
For me commented-out code is normally seen as a sign of disrespect from a less that thoughtful co-worker.
When you need to add a small feature or bug fix like NOW, within the next 3 minutes and you have to fix a file you have some half developed code on I'd say it's ok, practical needs rule over pragmatic ideals on the battlefield.
I broadly agree with the principle that commented out code shouldn't be checked in. The source control system is a shared resource, and your colleague is, to an extent, using it as his personal scratch pad. This isn't very considerate to the other users, especially if you subscribe to the idea of shared ownership of the codebase.
The next developer to see that commented-out code would have no idea that it's a work in progress. Is he free to change it? Is it dead code? He doesn't know.
If your colleague's change isn't in a state where it can be checked in, he needs to finish it, and/or learn to make smaller, incremental changes.
"Checking in partial changes that may or may not be deployed" - presumably that also means may or may not be tested? That's a slippery slope to a very ropey code base.
Another reason for checked in commented out code:
You're modifying existing code, and found a subtle bug, one that is easy to overlook, and perhaps might even look correct at first glance. Comment it out, put the fix in its place, and add comments for what is going on, and why it was modified. Check that in, so that your comments on the fix are in the repository.
This shows a fundamental difference in two schools of thought: Those who only check in working code that they are satisfied with and feel is worthy of saving, and those who check in their work so the revision control is there to backstop them against data loss.
I'd charactarize the latter as "those who like to use their revision control system as a poor-man's tape backup", but that would be tipping my hand as to which camp I'm in. :-)
My guess is that you are of the "good code" camp, and he is of the "working code" camp.
[EDIT]
From the comments, yes I guessed right.
As I said, I'm with you, but as near as I can tell this is a minority opinion, both here on stackoverflow and where I work. As such, I don't think you can really enshrine it in your development standards as the only way to operate. Not if you want the standards followed anyway. One thing a good leader knows is to never give an order they know won't be followed.
btw: Good editors will help with keeping old versions. For example, in Emacs I set kept-old-versions and kept-old-versions to 10, which has it keep around the last 10 saves of my files. You might look into that as a way to help your argument against the revision-control-as-backup crowd. However, you won't ever win the argument.
It depends. If it's being left there for purposes of illustration, maybe. It could possibly be useful during refactoring. Otherwise, and generally, no. Also, commenting out unfinished code is bound to be both failure-prone and a time sink. Better he break the code into smaller pieces and check them in when they work.
In my experience, developer switches are commented out code.
Sometimes, new back-ends are built in parallel, with the activating switchs commented out in source control.
Some bizarre feature we need once on a blue moon but no customer will ever need is often implemented that way. These things usually carry a high risk of security or data integrity bypass so we don't want them active outside of development. Requiring a developer who would use it to uncomment the code first seems to be the easiest way of getting it.
I think "Never" is too strong a rule. I'd vote to leave some personal leeway around whether people check commented code in to the repository. The ultimate goal should be coder productivity, not "a pristine repository."
To balance that laxness out, make sure everyone knows that commented out code has an expiration date. Anyone is allowed to delete the commented code if it's been around for a full week and never been active. (Replace "a week" with whatever feels right to you.) That way, you reserve the right to kill clutter when you see it, without interfering too directly with people's personal styles.
Perhaps the real question here is whether developers should be allowed to check in incomplete code?
This practice would seem to be contradictory to your stated goal of implementing continuous integration.
My view: if developers are working on their own branches, or in their own sandbox area, then they should be able to check in whatever they want. It's when they check code into a shared branch (a feature branch, or a team's branch, or of course MAIN/trunk) that the code should be as pristine as possible (no commented out code, no more FIXMEs, etc).
The idea of allowing source-control history to illustrate the "old way" of doing something rather than commenting it out and checking in the commenting-out along with an explanation is a good idea in theory.
In the real world, however, nobody ever looks at source control history on the files they are working on unless it is part of an official review process of some sort (done only periodically), or if something doesn't work, and the developer can't figure out why.
Even then, looking back more than about 3 versions basically never happens.
Partially, this is because source-control systems don't make this sort of casual review easy. Usually you have to check out an old version or diff against an old version, you just see two versions, and there's no good concise view of what changed that can give you an at-a-glance idea of what changed.
Partially, it is the combination of human nature and the needs of the team. If I have to fix something, and I can fix it in a few hours, I'm not likely to spend an hour investigating old versions of the code that haven't been "live" in a month (which, with each developer checking in often, means back many revisions), unless I happen to know that there's something in there (such as if I remember a discussion about changing something related to what I'm doing now).
If the code is deleted and checked back in, then, for all intents and purposes (except for the limited purpose of a complete roll-back) it ceases to exist. Yes, it is there for backup purposes, but without a person in the role of code librarian, it is going to get lost.
My source control tree on my current project is about 10 weeks old, on a team of only about 4 engineers, and there are about 200 committed change lists. I know that my team does not do as good of a job as it should of checking in as soon as there is something solid and ready to go. That makes it pretty rough to rely on reading the code history for every part of the code to catch every important change.
Right now, I'm working on a project in initial development mode, which is very different from a project in a maintenance mode. Many of the same tools are used in both environments, but the needs differ quite a bit. For example, often there is a task that requires two or more engineers to work somewhat closely together to build something (say a client and a server of some sort).
If I'm writing the server, I might write up the code for the draft interface that the client will use and check it in completely non-functional, so that the engineer writing the client can update. This is because we have the policy that says that the only way to send code from one engineer to another is through the source control system.
If the task is going to take long enough, it would be worth creating a branch perhaps for the two of us to work on (though that is against policy in my organization -- engineers and individual team leads don't have the necessary permissions on the source-control server). Ultimately, its a trade-off, which is why we try not to institute too many "always" or "never" policies.
I would probably respond to such a no-commented-code-ever policy by saying that it was a bit naive. Well-intentioned, perhaps, but ultimately unlikely to achieve its purpose.
Though seeing this post is going to make be go back through the code I checked in last week and remove the commented-out portion that was both never final (though it worked) and also never likely to be desired again.
I absolutely agree that commented out code shouldn't be checked into the repository, that is what source code control is for.
In my experience when a programmer checks in commented out code, it is because he/she is not sure what the right solution is and is happier leaving the alternate solution in the source in the hope that someone else will make that decision.
I find it complicates the code and makes it difficult to read.
I have no problem with checking in half finished code (so you get the benefit of source control) that isn't called by the live system. My problem is with finding sections of commented code with no explanation the dilemma was that resulted in the code being excluded.
I think checking-in commented code in a source code control system should be done with extreme caution, especially if the language tags used to comment the code are written by blocks, i.e.:
/* My commented code start here
My commented code line 1
My commented code line 2
*/
Rather than on an individual line basis, like:
// My commented code start here
// My commented code line 1
// My commented code line 2
(you get the idea)
The reason I would use extreme caution is that depending of the technology, you should be very careful about the diff/merge tool you are using. With certain source code control system and certain language, the diff/merge tool can be easily confused. The standard diff/merge of ClearCase for example is notoriously bad for merging .xml files.
If it happens that the commenting blocks lines are not merge properly, presto your code will become active in the system when it shouldn't be. If the code is incomplete and break the build, that is probably the least evil, as you will spot it immediately.
But if the code passes the build, it may become active when it shouldn't be there, and from a CM perspective, that could be a nightmare scenario. QA generally test what should be there, they don't test for code that is not supposed to be there, so your code may end up in production before you know it, and by the time it would be realized the code is there when it shouldn't, the cost in maintenance have multiplied many folds (as the "bug" will be discovered in production or by the customer, worst place or time ever).
I think commented out code is considered to be "waste".
I am assuming you are working in a team environment. If you are working on your own, and you comment out code with a 'todo' and you will come back to it then that is different. But in a team environment you can safely assume once commented out code is checked in it is there to stay and it will most likely cause more pain than satisfaction.
If you are doing peer code reviews then it might answer your question. If another developer reviews your code and says "why is there this commented out code that is trying to do 'blah'" then your code has failed the code review and you shouldn't be checking it in anyway.
Commented out code will just raise questions with other developers - therefore wasting time and energy.
You need to ask the question "why" the code is commented out. Some suggestions:
If you are commenting out code because you are "unsure of business rules" then you probably have an issue with "scope creep" - best not to dirty your code base with requirements that "would be nice to have but we don't have time to implement" - keep it clean with clear code and tests around what is actually there.
If you are commenting out code because you are "not sure if it is the best way to do it" then have your code peer reviewed! Times are changing, you will look at code you write today in 2 years and think it's horrible! But you can't go around commenting out bits that you 'know' can be done better but you just can't find a way right now. Let whoever maintains the codebase long term determine whether there is a better way - just get the code written, tested and working and move on.
If you are commenting out code because "something doesn't work" then FIX IT! A common scenario is "broken tests" or "todo's". If you have these, you will save yourseslf a lot of time by either fixing them or just getting rid of them. If they can be "broken" for a period of time, they can most likely be broken forever.
All of these potential scenarios (and ones I haven't mentioned here) are wasted time and effort. Commented out code might seem like a small issue but could be an indicator of a bigger issue in your team.
Repositories are backup of code. If I am working on code but it is not completed, why not comment it out and check it in at the end of the day. That way if my hard drive dies overnight I will not have lost any work. I can check out the code in the morning uncomment it and keep on going.
The only reason I would comment it out is because I would not want to break the overnight build.
There is clearly a tension between 1) checking in early, and 2) always maintaining the repository in a working state. If you have more than a few developers, the latter is going to take increasing precedence, because you can't have one developer crapping all over everyone else for his own personal workflow. That said, you shouldn't underestimate the value of the first guideline. Developers use all different kinds of mental fenceposts, and individualized workflows are one way that great developers squeeze out those extra Xs. As a manager your job not to try to understand all these nuances—which you will fail at unless you are a genius and all your developers are idiots—but rather enable your developers to be the best they can be through their own decision-making.
You mention in the comment that you don't use private branches. My question for you is why not? Okay, I don't know anything about TFS, so maybe there are good reasons. However after using git for a year, I've gotta say that a good DVCS totally diffuses this tension. There are cases where I find commenting out code to be useful as I'm building a replacement, but I will lose sleep over it if I'm inflicting it on others. Being able to branch locally means I can keep meaningful commits for my individual process without having to worry about (or even notify) downstream developers of temporary messes.
Just echoing the chorus. Discourage this at all costs. It makes the code harder to read and leaves folks wondering whats good/bad about that code that isnt even part the application at the present time. You can always find changes by comparing revisions. If there was some major surgery and code was commented out en-masse the dev should have noted it in the revision notes on checkin/merge.
incomplete/experimental code should be in a branch to be developed to completion. the head/trunk should be the mainline that always compiles and is whats shipping. once the experimental branch is complete it/accepted it should be merged into the head/mainline. There is even an IEEE standard (IEEE 1042) describing this if you need support documentation.
I would prefer to see possibly broken, accessible code that isn't being used yet checked in over the same code being completely unavailable. Since all version control software allows some sort of 'working copy' separate from the trunk, it's really a much better idea to use those features instead.
New, non-functional code is fine in the trunk, because it is new. It probably doesn't break anything that already works. If it does break working code, then it should just go in a branch, so that other developers can (if they need to) check that branch out, and see what's broken.
"Scar Tissue" is what I call commented-out code. In the days before the widespread use of version-control systems, Code Monkeys would leave commented out code in the file in case they needed to revert functionality.
The only time it is acceptable to check-in "scar tissue" is
If you have a private branch and
You don't have time to make the code compile without errors and
You are going on a long vacation and
You don't trust your VCS, like if you use Visual Source Safe OR.
[EDIT]
You have a subtle bug that might be reintroduced if the incorrect code isn't left in as a reminder. (good point from other answers).
There is almost no excuse for #4 because there are plenty of freely available and robust VCS systems around, Git being the best example.
Otherwise, just let the VCS be your archive and code distributor. If another developer wants to look at your code, email him the diffs and let him apply the stuff he wants directly. In any event, the merge doesn't care why or how the coding of two files diverged.
Because it is code, scar-tissue can be more distracting even than a well-written comment. By its very nature as code, you make the maintenance programmer expend mental cpu-cycles figuring out if the scar-tissue has anything to do with his changes. It doesn't matter whether the scar is a week old or 10 years old, leaving scar-tissue in code imposes a burden upon those who must decypher the code afterwords.
[EDIT]
I'd add that there are two major scenarios that need to be distinguished:
private development, either coding a personal project or checking in to a private branch
Maintenance development, where the code being checked in is intended to be put into production.
Just say "NO" to scar-tissue!
I don't know - I always comment out the original lines before I make changes - it helps me revert them back if I change my mind. And yes I do check them in.
I do however strip out any old commented code from the previous check-in.
I know I could look at the diff logs to see what's changed but it's a pain - it's nice to see the last changes right there in the code.
A nice compromise is to write a little tool that dumps your checked out/modified files to a network backup drive. That way, you can modify til your heart's content and have your work backed up, but you never have to check in experimental or unfinished code.
I think that checking in commented out code should be valid as, just because the new change passed tests it may be more helpful to see what was there before and see if the new change is really an improvement.
If I have to go back several versions to see an earlier change that now leads to a performance hit then that would be very annoying.
Sometimes the commented out code is a good history, but, put dates as to when the code was commented out. Later, someone that is working near there can just delete the commented out code as it has been proven not to be needed.
It would also be good to know who commented out that code so that if some rationale is needed then they can be asked.
I prefer to write new functionality, ensure the unit tests pass, check it in, then allow others to use it and see how it works.
If the developer has commented out some code because it is not yet complete, then the correct "source control" way to deal with this would be for that developer to keep it in a separate branch of his own, until that code is ready to check in.
With a DVCS (like git, bazaar, or mercurial) this is dead easy as it requires no changes in the central repository. Otherwise, perhaps you could talk about giving developers their own branches on the server if they are working on specific features that will take them a long enough time (ie, days).
There is nothing wrong with checking in commented out code in some situations, it's just that this is one situation where there may be a better way to do it, so the developer can track changes to his source even though it isn't ready to be checked in to the main repository.
Clearly, the developer who is checking in commented-out code should be working in a separate branch, merging in changes from the trunk branch as neccessary.
It is up to the VCS system to assist the developer in this workflow (git is one excellent VCS system that works with this very nicely).
When I'm online it seems that everyone has agreed that using the exclusive locking workflow in source control is a Bad Thing. All the new revision control systems I see appear to be built for edit and merge workflows, and many don't even support exclusive locks at all.
However, everyone I work with is of the opinion that exclusive locks are a "must have" for any source control system, and working any other way would be a nightmare. Even recent hires from other companies seem to come in with this idea.
My question isn't who is right. I'm pretty sure what answer I'd get to that. My question is, is there really still any debate over this matter? Is there an honest "pro locking" camp out there that makes a serious case? Is any work being done to advance the art of revision control based around the locking model? Or are locking fans flogging a dead horse?
EDIT:
The answers so far have done a good job of explaining why exclusive locks are a good feature to use occasionally. However, I'm talking about promoting a workflow where exclusive locks are used for everything.
If you're used to exclusive locking, then it's hard to embrace the edit-merge workflow.
Exclusive locking has its benefits, especially for binary files (images, videos, ...) which can't be merged automatically or not at all.
But: the need for exclusive locking always indicates another problem: good communication between people working on the project. Exclusive locking provides a poor replacement: it tells users that someone else is already working on that particular file - something they should know without using a version control system.
Since there are better ways to help with the communication among team members, most (all?) version control systems don't implement exclusive locking anymore or just a reduced version (i.e., locking, but such that those locks are not enforced).
It's not the job of a version control system to help with the communication.
I like having the option to exclusive-lock some file[s].
Having an exclusive lock is necessary, e.g. for binary files.
It's also semi-necessary for some machine-generated non-binary files (e.g. for Visual Studio project files, which don't 'merge' at all well if ever there are two parallel changes to be merged).
If you believe that merges are hard (and while we've come a long way, they can be in some circumstances), and you don't have programmers frequently wanting to edit the same file, exclusive locking isn't necessarily that bad.
I wouldn't use them on an open source project, obviously, but in the corporate world where the rules are stricter and you can walk over to a guy and say "can I break your lock?", it gives visibility into what people are working on and avoids conflicts so they don't have to be resolved later.
If two people really need to work on a file at the same time, often you can branch that file, and so long as the tool makes it clear that that branch needs to be merged back in, you can do that and resolve any conflicts then.
That said, I don't think I want to have to work in an exclusive locking world again.
Exclusive locking is the best you can do in a worst-case scenario, so its presence always tells me that there are bigger problems.
One of those bigger problems is bad organization of code. On one of my consulting gigs for a major telecomm, eight out of thirty team members were constantly working on the same source file (a VB.NET "god" form). We would wait for someone else to finish their work and release the exclusive lock (VSS), then the next person in the pecking order would immediately lock the file to apply their changes. This took forever because they had to reintegrate all their work into the new code that they could see only just then. Since I was the new guy, I was on the bottom of the pecking order and I NEVER was allowed to check in my code changes. I eventually went to the project manager/director and suggested that I be tasked with another part of the application functionality. This project eventually self-destructed, but most of us left as we realized that inevitability. Note that the use of VSS integration was a crucial part of this failure, too, since it forces early acquisitions of that precious file lock.
So, a well-organized project should almost never result in two people working on the same part of the same source file at the same time. Therefore, no need for exclusive locking.
Another of those bigger problems is putting binary files into source control. Source control tools are not designed to handle binaries, and that is a good thing. Binaries require different treatment, and source control tools cannot support that special treatment. Binaries must be managed as a whole, not as parts (lines). Binaries tend to be far more stable/unchanging. Binaries tend to need explicit versioning different from source control versioning, often with multiple versions available simultaneously. Binaries are often generated from source, so only the source needs to be controlled (and the generation scripts). See Maven repositories for a binary-friendly storage design (but please don't use Maven itself, use Apache Ivy).
The arguments for locking are really bad. They basically say: our tools are so bad they cannot merge, so we lock.
In my experience, it's often necessary for two people to work on the same file at the same time. (There are, presumably, shops where this doesn't happen, but I have fairly varied experience to draw on.)
In these cases, it is necessary for both people to get copies of the original, do their work, and merge their changes. In non-locking VCSs, this is done automatically and accurately for the most part.
With a locking VCS, what happens is that one person gets the lock. If that person finishes first, great; if not, the other person gets to wait before being able to introduce changes. Sometimes it is necessary to make a quick bug fix while somebody is in the middle of a long change process, for example. Once the second person has the lock, the second person needs to merge the changes, typically manually, and check in the new version. On several occasions, I've seen the first person changes dropped entirely, as the second person didn't bother with the manual merge. Frequently this merge is done hastily, either out of distaste for the job or simple time pressure.
Therefore, if two people need to work on the same file at the same time, a non-locking VCS is almost always better.
If this doesn't come up, and two people never need to work on the same file at the same time, it doesn't matter which you use.
On an open-source project like a game, it makes sense to keep images under revision control, and those are nice to be able to lock (Subversion supports this). For source files, it's better to get into the edit-merge work flow. It's not hard and increases productivity in my experience.
Here's my $0.02.
Locking is an old school of thought for textual Code. Once programmers use merging a couple of times they learn and usually like the power of it.
Valid cases for locks still exist.
Graphics alterations. 99% of the time you cannot merge 2 peoples work on the same graphic.
Binary updates.
Sometimes code can be complex/simple enough to justify only 1 person working on it at a time. In this case it's a project management choice to use a feature.
Interesting question. To me, the issue is not so much whether to lock, but how long to lock. In this shop, I'm a minority of one, because I like to merge. I like to know what other people have done to to the code. So what I do is:
Always work in a local copy of the source tree.
Run Windiff often against the "official" code and if necessary merge changes down to my local copy. For merging, I use an old Emacs (Epsilon) and have the compare-buffers command bound to a hot-key. Another key says "make the rest of this line like the one in the other file", because many changes are small.
When I'm ready to check in changes, Windiff tells me what files I need to lock, check in, and unlock. So I keep them locked as short a time as possible, like minutes.
So when Fearless Leader says "Have you checked in your code?" the answer is "I don't have any checked out."
But as I said, I'm a minority of one.
In my opinion, the main reason people use exclusive locking is its simplicity and for them, lack of risk.
If I have exclusive access to a file, I won't have to try and understand someone elses changes to the same file. I don't have to risk making my changes and then having to merge with someone elses when I check in.
If I have an exclusive lock on the files I'm changing, then I know that when I checkin, I will be able to checkin a coherent changeset; it is simpler for me to do this.
The other aspect of merging (esp. automatic merging) is the potential for regression problems. Without good automated tests, every time you do a automatic merge, you may get problems. At least if you have an exclusive lock on something you ensure that someone is looking at the code before it's checked in. This, for some, reduces risk.
What exclusive locking takes away is the potential parallelism of changes. You can't have two people working on a file.
The open source model (lots of people around the world collaborating on different stuff) has promoted the view that locking is bad, but it really does work for some teams. It does avoid real problems. I'm not saying that these problems can't be overcome, but it requires a change in behaviour for people; if you want to change to a non-locking model, you have to persuade them to change to a way of working which can seem harder for them, and can actually (in their view) increase risk cause regressions.
Personally, I prefer not to use locks, but I can see why some people don't like it.
A bit late to this discussion but to anybody who has read and digested Steve Maguire's Writing Solid Code a central point is to have your tools detect and identify as many problems as possible.
A compiler doesn't get tired after 12 or more straight hours and forget to issue a syntax error. But it is quite easy to forget a manual step of initiating a communication and paying for it later.
If you need to version control a binary file then you need some form of locking to prevent - or at least warn of - an accidental overwrite. It must be a fundamental feature of any VCS even a distributed one. To use such a feature in a DVCS may require the creation of a central repository but is that so evil? If you use a DVCS in any sort of corporate environment, you will have a central repo to ensure business continuity.
Addressing your edit comments.
Even RCS and SCCS (the grandfather VCS for most of what runs on Unix/Linux these days) permit concurrent editing access to files, and I'm not referring to separate branches. With SCCS, you could do 'get -k SCCS/s.filename.c' and obtain an editable copy of the file -- and you could use an option ('-p' IIRC) to get it to standard output. You could have other people doing the same. Then, when it came time to check-in, you'd have to ensure that you started with the correct version or do a merge to deal with changes since your starting version was collected, etc. And none of this checking was automated, and conflicts were not handled or marked automatically, and so on. I didn't claim it was easy; just that it could be done. (Under this scheme, the locks would only be held for a short time, while a checkin/merge was in progress. You do have locks still - SCCS requires them, and RCS can be compiled with strict locking required - but only for short-ish durations. But it is hard work - no-one did it because it is such hard work.)
Modern VCS handle most of the issues automatically, or almost automatically. That is their great strength compared to the ancestral systems. And because merging is easy and almost automatic, it allows different styles of development.
I still like locking. The main work system I use is (IBM Rational) Atria ClearCase; for my own development, I use RCS (having given up SCCS around Y2K). Both use locking. But ClearCase has good tools for doing merging, and we do a fair amount of that, not least because there are at least 4 codelines active on the product I work on (4 main versions, that is). And bug fixes in one version quite often apply to the other versions, almost verbatim.
So, locking-only VCS typically do not have good enough merge facilities to encourage the use of concurrent editing of files. More modern VCS have better merging (and also branching) facilities, and therefore do not have as strong a need for locking for more than the shortest term (enough to make the operations on the file - or files in the more advanced systems - atomic).