Slashdot Mirror
Who Doesn't Use Source Control?
VegeBrain asks: "I was reading the description for for a new book, Pragmatic Version Control using CVS and was shocked to read that 'Half of all project teams in the U.S. don't use any version control at all...' Is this true? If so, why? I can't imagine being without one so I'm wondering why anybody would avoid using one, especially now when so many are available for free. Am I missing something here and there really are reasons to not use a VCS?"
If you're working on a small project by yourself, there's really no nead for the overhead of a version control system.
Of course, if you want change histories, have a medium- or large-sized project, or have more than one developer, you very much need CVS or Subversion. There's really no reason to go without then.
Omnes stulti sunt.
Don't underestimate the power of ignorance. My 2 last employers didn't use a VCS because they didn't know that this kind of things existed. Of course, they now know, because I installed them one. :)
perception is reality
I joined about two years ago that had just completed the transition from everyone having their own copy of the source, to using CVS.
Funny thing is, some of the developers missed the old ways, and would occasionally slip back into old habits. A customer would have a problem, and one of the developers make a copy of the entire source tree, fix the problem, build it, send it to the customer, and that'd be it.
People would send modules to other people to merge with their copy...
It seems bizarre but it happens.
Also I wonder if the stat isn't skewed by the number of solo developers working on small projects... You don't really need revision control until your project reaches a certain size. Not a big size mind you - if you've spent a week on a project it's probably big enough to merit cvs - but I think a lot of projects are smaller than that.
--
http://www.stevex.org/longtail
The school I went to never teached me to use a versionning system. I had to:
- Wonder what this "CVS" thing on SF was about
- Go to the cvs website, still wondering what it was really used for.
- Download it and try it.
- Finally understand what it is, and wonder how I could have been without it during my whole CS and survive. (Well, not my whole CS, since I learnt about CVS at the before the end of it.)
It only takes a couple of unaware teachers to train a whole generation of ignorant developers.
perception is reality
For small peices of not-too-critical code, which probably constitutes a good chunk of all development done on the planet earth, source code revision control isn't terribly neccesary. Generally these little projects have only 1 developer, which helps a lot.
For me, personally - once a small project crosses some nebulous boundary between "hacking around on an idea, I'll probably rm -rf this at the end of the day" to "I'm gonna work on this, I think this code can do something good", I generally start using version control - just simple cvs with no tagging or branching (rcs or sccs would work just as well).
It serves as a backup system, and lets me be more bold with changes. I run in a tight loop of simultaneous architect/design/code/test, so once I've got revision control in place I can comfortably do global search and replace text substitutions on my source code, or wipe out whole files as part of a refactoring phase. I can be as aggressive as I want to be, and I can always go back into cvs to pick up what I was doing an hour ago when I realize I just took too many big steps in the wrong direction.
Therefore, I'm a fan. But - for many people doing little projects, just saving a zipfile/tarball of their source code tree as a daily snapshot in some directory somewhere provides them almost as much benefit, for considerably less effort than learning a version control tool.
11*43+456^2
My company uses a piece of 3rd party software for document formatting and archiving, and version control would be a great feature to add.
When we send payments to vendors via electronic payment, a check prints at the bottom of the statement with "VOID" across it. Due to a slipup while putting changes in production, the VOID logic was omitted a few months back and we sent signed checks out to vendors who had already received electronic payment! How's that for coming up with financial justification for version control???
Stop by my site where I write about ERP systems & more
Am I missing something here and there really are reasons to not use a VCS?"
No, you're not. But I tell you what --- I've been consulting for, oh, close to 20 years, and I've seen probably in excess of 200 companies, and I'd hate to tell you how many of them had no version control. Hell, I'd hate to tell you how many of them had no code backup, and you'd be amazed how many companies --- big companies --- have web applications in particular that live on someone's desktop and couldn't be reconstructed if that person was run over by a truck without reimplementing.
I'd hate to tell you, but I'll say, if it's as high as 50 percent who have version contral, then that means it's about doubled in the last few years.
But what about all the ways good version control frees you up? I think all the "but I'm just on a small project by myself" people are missing out.
On my personal projects, I use arch all the time, and I rarely look at the file histories, or share development with anyone else. No, I use it to:
- keep my desktop and laptop copies of my project in sync
- make branches to try out ideas that may not work
- keep a changelog automatically for me
- identify all project files (vs. generated or temp files), for easy tar'ing up for distribution
- etc.
I would expend much MORE effort doing these things without arch (or similar). So, to me, people looking for something easier ought to expend the effort to learn a good VCS.
Most of my jobs have been in professional software development groups, where source control is as implicit as breathing. But for a few years I worked at a prestigious National Lab, and that was an eye opener. Much of the code I saw was written by scientists with no real-world experience. Nobody I worked with had ever heard of the concept of source control; they just sort of did occasional "cp foo.c foo-with-xyz.c" things. I set up CVS, explained the rationale, helped them learn it, and forced them to use it. Most appreciated it, because they could see how much it helped. They simply hadn't known. But... some resented it. "That's not the way we do things". (My wife still works at that Lab, also as a programmer, and says she sees the same thing). For the most part, the people who say that are stupid. Not 100%, since many have PhDs, but truly stupid nonetheless. And they know it, which scares them: they think if they use source control, others can touch their code and make it better, and they won't be needed any more. Job security through obscurity, perhaps.
Think about it: if you're competent, you use source control as much as possible: you know you'll screw up sometimes, you want a strong history of what changed when, and you want others to improve and maintain your code. But if you're not competent (or uncertain), you want others to have as little visibility as possible into your code and process.
Although powerful in it's own way, my company's use of the "PVCS/Dimensions" suite leaves such an ugly taste that our group refuses to use it. The repository tree was designed seemingly by blind monkeys, and there is little power to change this layout per average "user" (although these same developers write code to control most of the servers - ironic).
The product is certainly powerful enough to store an enterprise-amount of data, but our implementation and workflow rules around it are abysmal. This isn't a knock on them, I simply don't know enough about it.
So, we opted to use another product, but for a while there simply was no Source Code Control at all. Each developer had a sandbox directory on the shared drive, and their own little fiefdom of backups, directories, etc. Quite scary. Now, we have a sweet layout that everyone enjoys.
When all this reached corporate, the discussion was
"use PVCS"
"we dont get it, it's confusing and locked from changes"
"get training"
"pay for it, money and time, and show us how this repository is organized"
"soooo, how's that other product working out?"
Before I was hired, my employer had version control, but it was used very little. It was proprietary system that was difficult to use because it tried to control the entire software development cycle, had expensive, per-seat licencing, and no integrated tool support. This meant developers didn't use it unless they had to, and when they did, did not use it effectively.
.
My first task was to deploy something more effective. We rolled out CVS and, with its excellent tool support, a little training and support from management all the developers in our group are using it very effectively, and our support people are even using it to distribute and track much of their documentation. To aid in some of the adminstrative burden we're using SourceForge and, while it is far from perfect, it is good enough to get the job done.
Any development environment worth its salt will have CVS support available and with tools like WinCVS and TortoiseCVS it actually takes little effort for those without technical skills to adapt
When people claim that it is "too difficult" to use version control, I scoff. In our experience, it is far easier to have a single, centralized location to store and backup our source and documentation. As far as we're concerned, if it isn't in CVS, it doesn't exist.
When one of our divisions had what can only be called an "unmitigated disaster" costing many thousands of dollars, their clients told them "get some revision control, or we're not dealing with you". Suddenly, emailing files around and storing them in poorly named directories on a file server seemed a lot more difficult than learning a handful of new commands.
Maybe you used SourceSafe. I tried it. It was really horrible.
I tried several systems. Here's what I think:
No source control: BAD.
SourceSafe: Just almost as bad. Could actually be worse. It can destroy productivity, and has lots of limitations. There's the dreaded database corruption issue, too...
CVS: Decent. Not wonderful, but a lot better than any of the above
SVN: Great. Similar interface to CVS, fixes a lot of limitations, works better.
If you use CVS or SVN, a modem shouldn't be a big problem. It's source code, after all. Excepting global search/replace changes over the whole repository, it's hard to do anything that takes more than a minute or two for SVN to transfer over a modem connection.
SourceSafe is *really* slow. CVS is okay, but SVN is faster due to a better design. So use it if you can. It will save you a lot more time than you lose by waiting a minute or two for a checkout to finish.
At several places I've worked there's been a consistent subgroup of developers that doesn't use version control. The SQL database programmers and analysts rarely put the DDL scripts into version control. I'm sure there are exceptions, but consistently I've seen them reject it. It really puts the hurt on a project when the application programmers can re-create any prior build or release any time, but can't do anything with it because there's no way to get the database back like it was. Even in day-to-day work, some change that breaks a trigger or integrity constraint that would be trivial to fix if you could roll back to N-1 ends up stopping work while the DB programmer tries to figure out what changed and how to fix it. As far as I understand, there are two justifications VC-resistant SQL developers cite for this situation. First, that the database can in theory be rolled back to any prior state by mucking around with the transaction logs and unplaying them. Second, that the database shouldn't be versioned, because its current structure is by logical proof the only correct one, and reverting to an earlier version means somehow violating relational purity.