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?"
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.
I work in a small university department. There are several different people working on the website. Most are using some variant of dreamweaver. Most are very non technical. Getting version control working seemlessly and reliably within dreamweaver and other clients, and then attempting to explain it to everyone so that they actually understand it, is simply put, not worth it. As far as using something outside of dreamweaver, I think that's too complicated for most, especially for those who might only make a change once or twice a month.
Some might be saying that Dreamweaver has some sort of pseudo version control thing built in. Frankly, I don't trust it. I'd rather have something standard like cvs, subversion, or sourcesafe. I'm new to dreamweaver so that attitude could change but I doubt it.
That said, I'm planning on automating some backups to in essence archive older versions of the site, libraries, and scripts... sort of a poor man's version archive system.
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
A person doesn't have to install CVS, Subversion, or BitKeeper to be a "good little developer". Many people get by quite successfully by just keeping good daily backups of their work and making copies of milestones and releases as "branching." It works pretty well when the size of the team allows good communication and relatively little toe-stepping.
Quite honestly, if there are only a handful of copies, even manually porting fixes across the releases can be simpler than learning a VC system.
Sometimes, once a person has learnt programming and everything else, adding more tools for tools' sake can be the straw that breaks the camel's back.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
Actually, having worked both sides of the fence, (physical scientist with background in programming and systems administration) I'd say the problem isn't that the scientists are stupid, but they aren't trained in software engineering. I received all sorts of comments over the years from the scientists I worked for about "computer people changing things, just because they can".
What they really hate is Computer People (apparently you), with Computer Theory Solutions (CVS) which do nothing for them except create overhead and slow down their programming. Most groups have a policy of everyone getting their own copy of the source tree, so that they can only screw themselves. They also have a senior person with long institutional knowledge, responsible for integrating changes, if/when necessary.
Nex time, try forcing them to use FFTW or some other optimized library which will increase their productivity instead of their hand-written routines, and see if you aren't viewed as a hero instead of the computer jerk.
Why do people drive too fast without seatbelts? Why do skiers ignore the skull-and-crossbones signs around avalanche zones? Why do people live in mobile homes in tornado and hurricane zones? People will always ignore non-immediate dangers and problems in favor of immediate costs and inconveniences, even if the risks are high and the costs are low.
This is an excellent point. I studied CS in school but didn't stick with it (went to EE) because they didn't actually *teach* anything. They talked about testing, but didn't say how you incorporate it into your work. They talked about version control, but not in any practical way or how useful it is.
Only years later I have gotten back into serious programming, thanks in part to the "Agile" programming movement. It's sad that it takes a buzzword "movement" to teach basic best practices.
If only in school they taught about "test-first development" and using CVS to do incremental development. Version control is such a productivity enhancement. I feel like I wasted a lot of time in those classes. In engineering they teach you best practices from day #1. I guess part of the problem is that in CS everybody has there own pet methodology and somebody would get offended...
It would also help to eliminate the "brain gap" in CS classes and help the slower folks, or folks who don't code for fun 24 hours a day, learn the principles.
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