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 are a proprietary software company who illegally copies copylefted (or even other proprietary) code into your work, VCSs leave a chain of evidence ready to be subpoenaed by the court when the FSF et al get wind of your activities.
Joe Llywelyn Griffith Blakesley
[This post is in the public domain (copyright-free) unless otherwise stated]
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
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.
It is kind of like asking "Who doesn't comment their code?!?"
1) It is not part of CS curriculum so students never hear of it. Unfortunately, That goes for concepts like "design" and "requirements" too.
2) It is seen as an enterprise solution, not for individuals.
3) Many individual developers are lazy. They only use it because they are forced to do it.
4) Many developers first see source control systems that are expensive and complicated. (I won't name names right now). Free/OSS solutions like subversion are almost "cult" even if they are better than most commercial systems.
If you're working on a small project by yourself, there's really no nead for the overhead of a version control system.
I completely disagree.. I version-control much of my home directory. This includes several of my dot-files and my home-bin-directory (for useful little non-system tools). Granted, this implies that I use a UNIX/Linux system.
Moreover, even simple one-off projects can get out of hand if you EVER have to move files around. Lets say you have a project that you only ever intended to run on one machine.. But then you're at work, home, friends-house or whatever, and you wanted to remember how you did some part of it. Well, the easiest thing to do, of course is ssh/ftp the files over.. Ok great... But now, that project gets updated. Months pass... Now you're on your friends machine and you've forgotten that changes have been made, so you don't re-copy the files back over.. Or lets say you used the copied image as a starting point, and you've made several changes since, adding new files. Now you have to manually compare each and every file to see if any are changed... So you don't even bother, and now you have a fork.
The key is that version-control allows you to organize your text-files. It's like putting them into a filing cabinet intead of literally leaving them scattered over your virtual desk-top. It promotes modularity and reuse, since you'll always be confident of the entire history of the file or project. You'll know with complete confidence that you could quickly build a project based on a previous one. It's the difference between writing one huge c-main function and creating header-files with separately compiled modules.
There's also one incredibly useful feature of version control.. An undelete that actually works. Lets say you "rm -r" your files. Lets say you use vi and accidently hit the caps lock and type for a little while without looking (all you need accidently do it type zz in that process and the changes are irreversable). Lets say a program goes wankers and starts modifying files indescriminately (say you use a text-formatting tool and it gives you unexpected results). These things happen over time.
In the old days, you'd hear people using word-processors and the phrase "save often" was used. checking in a version is like saving a known good copy. If you remember your 1980's days, you were far more use to complete catastropy. Now good system administrators perform nightly backups, but
a) you lose all the work that current day
b) when you quit the night before may not have been the files most perfect state over the past 24 hours. I know when I code, I'm perfectly willing to leave a document unfinished because a movie just came on, or I have a head-ache.
Next, often people set up separate users/directory-paths for which to manage the revsion control. Or even if you have group-write permissions, the files are stored on a separate host. This means that you have an added level of security from catostrophic demise. rm -r on your home directory means you've only lost the data since you last considered it stable. If you're disciplined, even a partition corruption won't hurt you.
Once you have a system, it takes 20 seconds to enter a project into a version control system. You just get into the habbit of doing so, and you reap the benifits.
-Michael
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.
At a small company I worked at with 3 other developers, and 2 designers we did not use a version control system because:
* we didn't think of installing one, even though a number of negative things happened as a result of not having one.
* had difficulty installing CVS. After reading the docs to install CVS, I still had trouble getting the thing to work and skipped it completely.
* we were naive. not everyone who is programming, especially those new to the scene, know about version control.
I'm not saying these are legitimate reasons, these are excuses for a poor development environment. I have learned from this and have made changes to make my developing better.
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?"
Worked for a now defunct company that had a team of four and no source control. Actually, I lied, they all thought they were using "source control", but it was simply a shared filesystem. So, in other words, everyone worked on the same set of files all day, while some just took a day every month or so to manually copy files from the shared frive to a local drive. It was complete madness.
The organization then decided to adopt source control in the form of "Visual Sourcesafe". Anyone who has used Visual Sourcesafe on a large project will tell you two things:
1. Lock-modify-unlock destroys productivity
2. A shared filesystem is preferable to the ever-corruptable Visual Sourcesafe.
Lock-modify-unlock mean that specific developers would declare ownership of a particular directory and lock it indefinitely not bothering to update the repository with changes until they were good and ready.
The best source control systems are CVS and Subversion. Copy-modify-merge is the only way to go, and don't let anyone tell you that they need to lock files or directories.
------ Tim O'Brien