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?"

Comments

It is true

[MobyDisk]

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.

Re:Alone

[maraist]

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.

Man, have I seen this, and it ain't pretty

[BigTimOBrien]

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.