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

Alone

[sinclair44]

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.

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.

Legal Reasons?

[sepluv]

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.

Ignorance

[hsoft]

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. :)

Some people don't want to bother

[SiliconJesus]

Lets face it - Alt-F-S or Esc-w-q-! is a hell of a lot easier than checking into a CVS server and uploading your new code.

Yes there are easier ways to implement CVS or at least RCS, but most people don't care. Its not that important if your development team is small or if the project is broken down into chunks where each person is in charge of small bits of code.

Re:Some people don't want to bother

[1nv4d3r]

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.

No Version Control

[SteveX]

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

Re:No Version Control

[swdunlop]

This sort of behavior is a little easier to cope with, using DARCS, which supports a more anarchic model of many people incestuously forking repositories, passing around patches, etc. Darcs doesn't force you to maintain a central repository or inflict a directory scheme, making it really very friendly for migrating existing projects into the system*.

After having both arch and svn meltdowns, I have moved my projects to darcs, and have been pretty happy with it, since -- I just wish Sourceforge supported it better.

(* The one exception being DARCS's case insensitivity for file names. )

I'd like to add

[hsoft]

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.

Re:I'd like to add

[Hard_Code]

- realize that it really sucks and switch to SVN while others are still wondering how they can get on this new "cvs" wave

Ignorance is bliss

[photon317]

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.

Re:Unfortunately, sometimes you simply can't use i

[TopShelf]

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

Argh.

[crmartin]

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 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:It is true

[utahjazz]

1) It is not part of CS curriculum so students never hear of it Unfortunately, That goes for concepts like "design" and "requirements" too.

That's because design and requirements are not part of computer science, they are part of software engineering.

Re:It is true

[EvlG]

Too bad comments can be harmful.

How many times in a large codebase have you come across something like this: // Don't doo Foo() here because of x and y and z
Foo()

Comments often don't get maintained properly, which leads them to be out of date and wrong.

Which is worse, no comment, or an incorrect comment? The presence of incorrect comments leads developers to have a rather healthy skepticisim of all comments....

Small Cluefree Groups

[Darth_Burrito]

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.

Ignorance? Fear?

[esm]

I graduated with a CS major almost 20 years ago, and have been making my living since then as a programmer. I never learned anything about source control in collij. I learned it during collij, because I worked summers at a professional organization. I was lucky.

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.

VC can be had without CVS

[SunFan]

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.

Reasons why we didn't use version control.

[Alpha27]

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.

When NOT

[mugnyte]

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

The usual reason

[fm6]

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.

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.

Tortoise SVN for Windows

[tom taylor]

Tortoise SVN for Windows is great for mini projects with a single programmer, because it lets your run a subversion tree locally from your HDD without the need for a proper server install. I'm sure there's an equivalent for *nix.

Re:Tortoise SVN for Windows

[chendo]

I use eSVN in KDE. Works okay for most of my SVN needs, but Cervisia wins, hands down. Probably the main reason I'm sticking with CVS for projects I have control over.

I manage the Tsukihime translation project, and there has been countless times it's saved our asses when someone edited something out of context and made no sense whatsoever. A quick look at a couple of revisons back allowed me to fix it in a few seconds, instead of wasting time contacting the original translator.

Re:A Good Reason for NO Version Control: Speed

[Jason Pollock]

That's why you use a non-locking VC like CVS. :)

It doesn't lock files for edit, and when you're committing you aren't transferring the entire suite, just the files that have changed.

And it usually does the merges for you!

I've used CVS across a 14.4 modem without any problems. :)

VC products have changed substantially from the CCCS/RCS days of edit locks. Subversion has even more nifty features, but I'm unsure of the network performance.

Jason Pollock

Re:A Good Reason for NO Version Control: Speed

[vadim_t]

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.

CVS to SVN to DARCS

[A nonymous Coward]

I used CVS for a long long time, over ten years, finally switched to SVN to get renaming. This is all for personal use, altho I have used CVS at a lot of companies too, so atomic commits didn't have much to do with CVS --> SVN. But I never liked SVN keeping things in binary files, and not being able to just look around the repository with any old editor, and 6 months later, I switched to DARCS to get the simple repository. I was surprised to find the patchset mentality very refreshing, and why I will stick with it. I have only started understanding how much more flexibility it provides. I can't see going back to CVS or SVN.

Try DARCS on some small project sometime. It has conversion scripts from CVS, but I don't think from SVN, altho I could be mistaken; my time with SVN wasn't long enough to obsolete most of my CVS repository.

Really, DARCS is liberating. It's the same feeling I had getting out of the navy. A breath of fresh air, great gobs of it, just fine, thank you :-)

One big segment

[cratermoon]

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.