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.
Bloody ignorance
fp?
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
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.
Clinton made me a Republican. Bush made me a Libertarian. Trump is making me question reality.
well, half of all projects may not use version control, but an even larger percentage of claims in advertisements are completely made up to make you want to buy their product.
And even when there's good data, words can be misleading. For instance, maybe they meant ALL projects use VCS, but 1/2 the people on each project don't. Like, the managers and secretaries and accountants, for instance.
AND it says many others experience problems, but it *doesn't* say that their problems are with their version control! They could have fertility problems, or drinking problems, and the ad would still be strictly factual.
(but to answer your question, no, I don't see any reason why people would want avoid version control of source files)
I had the misfortune to work with a third-party software who had its own programming language, IDE and "repository" (it was on a database).
We hadn't any "offical" way to export and then import the code from the db and the "versioning" function provided by the IDE wasn't useful at all..
I hope it is rare to be in this situation now.
This message doesn't need a sig
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
I really can't believe this article got "green-lighted".
Most people that don't use VCS started coding long before they learned of VCS. These people are either lazy, ignorant (to the great advantages), sloppy, etc. and revert back to old habits.
I worked in a company without any version control (~10 of people), with version control (the real one, but not M$ :)), and using version control for some projects and not using for other (~50 of people). I don't remember someone's update breaking other people's stuff without version control, but with one it happens almost every time :).
Actually you can think of not using version control as of checking out and in all the files every time, while with version control you might have an illusion you can change just this one file without looking into the rest. But even without version control you should maintain complete history of course.
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.
poor environments (like some RAD tools) which store source code in binary formats and/or where you would have to trigger exports manually to get to the code could be reasons for not using a repository. those tools must be easy to use, e.g. being integrated with your IDE or you simply would not use them.
_all_ my documents go into Subversion: source code, office documents (text, spreadsheet, presentation), pdf manuals, invoices...
easy to back up and keep consistent over all machines.
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.
Of course, 20 years of advancement now present me with the opprotunity to learn ARCH, etc... and I may do so. But I'll still refuse to use any language that sees CaSe SensiTivitY as a FeatUre.
--Mike--
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.
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.
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.
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?"
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.
u spelled collage wrong.
Idiots and amateurs. ;)
News for Geeks in Austin, TX
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.
Sounds like Uniface to me.
"...silence is a dangerous sound."
I worked for them in the mid 90s. I don't know what they do now, but back then they certainly did *NOT* do version control.
yeah i worked for a company that used PVCS. it SUCKED. horrible experience. i hated it. cvs is sooo much better. command line, scriptable, multiple people can work on the same piece of code, and it helps that cvs is faster than a freaking ant and isn't a horriblly implemented java gui. unlike PVCS which SUCKED.
the only product that i've had a worse time with is a bug tracking system called Remedy or Peregrine. Remedy REALLY REAlly sucked. wow. bugzilla is way better.
i love my new company.
return -ENOTFUNNY;
Next day I start with mv project-0.0.1 project-0.0.2.
Of course, I work alone on my programming projects.
I could use CVS, but there are a number of "concerns" (I admit, I am ignorant):
- how do I backup my CVS-server?
- can I be certain different versions of CVS-clients on MacOSX, linux and cygwin will work nicely together?
- when do I need to patch my CVS server?
- will there be ANY benefits?
I very rarely go back to old versions of my code. I simply dont program that way...Um? Distributed development is not the only advantage of using source control.
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.
So in my case, the reason for not using it was a combination of thinking "we're too small to need to worry about this", inertia, fear of complexity from some users, and the inability on my part to make a really solid case saying "this is what we need, this is why". When we grew, many of these arguments went away - and made making the case for it a lot easier.
Lead developer, http://wisptools.net
A few years back I worked on a 2-person project, and we thought about going to VC. I was in NY and sitting next to the server, the other person was in Ottawa on an ISDN line (barely faster than dialup). The impact on her of having to check in and check out files over the slow link would have killed her productivity, and her having those files tied up that long would have killed mine.
The tradeoff was that OCCASIONALLY we would both have made changes to the same file, and I would have to re-sync the files by hand - a nuisance, but it turned out better than using VC in this case.
Networking and connection speeds have gotten better since then, so it's less likely to be a problem today, but it could still happen.
Teen Angel - a Ghost Story
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
I have never seen such a lopsided reaction from slashdot.. i think there was one, maybe two lowmodded posts that were pro-noCVS, and they have +4 insightful replies slamming them..
herebeit resolved, CVS is the shiznittybingbang.
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.
Eric Sink has recently started writting a detailed HOWTO off of his personal website titles "Source Control HOWTO. He doesn't just cover his own companies project "Vault", but also touches on CVS, VSS, and Subversion.
In my IT career I've used VSS, PVCS, a bit of CVS, and now becoming more familiar with Subversion behind GForge. Of all the documentation I've consumed, Eric Sink's article has so far been the most thorough (and least dry!)
As for the comments regarding source control being overkill for personal projects; I feel there is a misconception that source control will add continually overhead to a project. The initial setup may be a pain, but when refactoring components, it's much easier to perform differences along a file's history from a source control system than diff directory which you manually copied to perserve a "version". I've done it both ways, and found using source control with my solo projects to provide a multitude of benefits. I could list them out here, but I believe they're all addressed (and then some) in the HOWTO.
I wonder if that 50% means projects with no version control at all, or just none of the usual alphabet-soup SCC products. I've worked on (and run) several entirely successful projects without CVS, RCS, SCCS, whatever. That doesn't mean that we didn't have version control, it just wasn't fancy or formalized. In all cases, we had a bunch of guys all within shouting distance; we had some kind of informal check-in/check-out that left some kind of trail; and we made damn sure that the nightly backups worked, every night. If someone screwed up and stepped on someone else's work, we were all right there, and we could have a little come-to-Jesus meeting.
Obviously, for larger or geographically distributed teams, or projects where back versions need support for an extended time, something more formalized becomes increasingly necessary.
Running with NO version control of any kind, not even safe backups, is nuts. I wouldn't even do that for at-home toy projects.
I'll speak up for the developers use tools like Macromedia Flash and Director. These tools produce binary source files, for which the advantages of CVS are slim when compared to the classic method of of "save as..." version number incrementing.
The very nature of the tools make multi-programmer projects extremely difficult as is, so not using CVS -- making each developer an island -- is a natural extension of the tools. Macromedia tools are like sharing a hammer -- you can't really have multiple hands on the hammer at once.
Mix in the fact that multimedia developers are routinely working with lots of binary files (sounds, graphics, whatnot) that also don't get a lot of benefit from CVS repositories, and you've got a recipe for a wholesale subset of developers who have no need to learn CVS commands.
Recent versions of Flash and Director allow developers to link in external text files for ActionScript/Lingo/JavaScript coding, so it's now possible to use version control for the code, at least, in your project. However, in these tools, code isn't half of the data in a source file: you've got the timeline (or score) data, the library (or cast) data, you've got any internal text references... plus, when the feature first came our, we had trouble with external code references being buggy, so people avoided it rather than lose hours of code.
It's still just a pain in the ass to use version control with Macromedia products. Not impossible, not entirely fruitless like in years past, just a pain in the ass. So many old-school developers I know just stick with what they know: "save as.." ++i.
However, in our company we recently set up a Subversion server, and hopefully we can get some more traction with checking in and out code. Since we now have multiple developers touching the same file, version control will help us with things like "who's got the ball" at the very least. But regardless, getting CVS used is an uphill battle.
I run my own consulting business and do a lot of cross-platform projects. Although I am a one-man shop, I essentially forced myself into using a source-control system (cvs) just to help manage shipping updated source between Mac and Windows with the proper line endings.
After I lost some code in a relatively small project, I also forced myself to put EVERY project into cvs, no matter how small. My repository sits on a Linux box running amanda so everything gets backed up too.
Now I use cvs for projects that span multiple platforms (Windows, Mac, Linux, IRIX) and use the full feature set for managing versions, etc. I'm looking into migrating to subversion in the near future.
I'm the lead programmer in a group of five, doing primarily internal SQL Server, ASP, and PHP development. We don't use a formal check-in/out system. We use Twiki, with a series of perl scripts that are run from cron jobs, to monitor all of our SQL databases and ASP/PHP pages. The SQL objects are monitoring using a "snapshot" of the sysobjects tables, comparing that to the current sysobjects table - any objects that are different get scripted off and published into Twiki. ASP/PHP files are compared using simple file compare, and published to Twiki if changes are detected. Twiki handles all the versioning and diff functionality for us, along with giving us the ability to do keyword searches. Want to know how many places the field named "vchCustomerName" is reference? Just do a keyword search in Twiki, and you see every stored proc, PHP page, trigger, etc.
I played around with CVS for a bit a few years ago, and found it to be too much of a pain in the ass for personal use.
SVN is so much better, and IMO easier to use. I'm using it for all future personal projects. (Already have the LaTeX source for my resume in a personal SVN repos)
retrorocket.o not found, launch anyway?
Probably many of the teams not using version control should be, but there
are certainly circumstances wherein it isn't necessary. Sometimes the
division of labor on a project is such that each developer really only has
to make changes his own parts of the project -- his own files, or, in some
cases, his own library or application. This is not the norm even for
proprietary software and is probably _very_ unusual in the open-source world,
but it does happen occasionally.
And, of course, there are always the projects with pretty much just one
programmer (though there may also be other people doing e.g. content, art,
music, PR, marketing, or what-have-you).
I currently don't use any version control for Net::Server::POP3, because
no other developers have expressed an interest in working with me on it.
(Which is fine; it's a small module and probably only needs one developer.
It does build on the work of others, e.g. by using Net::Server, but I have
not contributed anything back to Net::Server itself, because I haven't
needed to make any changes to it; I just use it.)
Cut that out, or I will ship you to Norilsk in a box.
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
Infuriate left and right
MY company is a certified quality company with a procedure that talks about source control. We have PVCS as the corporate standard however no-one outside the test area is willing to pay the $10K a seat I was quoted.
I set up CVS and I have been trying to mandate that through the other groups who proclaim it a wonderful idea that they will use 'real soon now'. I even have agreement from my manager that it is a requirement of the group. I manage ALL checkins from my group after virtually dragging the code out of the people who use wrote it.
One critical piece of software that our company depends upon the only copy of the code was stored on his personal PC at home. After 4 years chipping away I think I have the majority of the code that he has. It is all working therefore out of sight and out of mind. I keep hassling other groups and trying to get the mandate but I guess things will never change.
Years ago, I worked for these guys. The major application for capacity planning in the region I worked in was under "copy the file to a .bak extension before you work on it" version control.
600 or so perl files... 800 or so PHP files... 100 or so directories... Nightmare.
Why? Couldn't get approval. "The system works, there's no need!"
I did my own version control at my desktop via CVS when I worked there and it saved my bacon a number of times. I've heard they've since implimented CVS or somesuch after an errant "rm -rf" command in the main source directory.
Some programming environments (*cough* MS Access *cough*) do not readily support traditional version control. They often involve cryptic binary formats that render intelligent diffs/merges impossible, assuming you even have discreet files at all. And without that, your VCS is nothing more than a daily backup.
Other times it's just too difficult to do version control. For example, how do you perform version control on database stored procedures? If you mention exporting to a text file and then checking that in, you fail. That's too much manual labor to expect a developer to do. If it takes more than one command to check in your changes, developers won't do it; they'll eventually get lazy and skip it.
As for the single developer not needing it, I guess all you developers have never had to deal with regression bugs then, eh. I guess you've never had to roll back significant changes because in the end it just didn't work right.
SO I guess what I'm getting at is the only reason to not use version control is because you can't.
When it comes to source code I basically always use version control, when it are single-file things I tend to use RCS, when it gets more I switch to CVS or SVN, but when it comes to binaries (.xcf, .blend, .png, etc.) I tend to not use version control systems or at least use them to a much lesser degree. Reasons for this are mostly ease of use related, with text editors you often have build-in support for checkin/checkout, with graphical editors you seldomly have them. Being able to do a 'diff' between different versions is also relativly useless with binary files, so I end up doing manual versioning instead (file-1.png, file-2.png, file-with-special-light-2.png, etc.), since that is much easier to access from the 'editor' (Gimp, Blender) and also much easier to work with. If i want to have a look at and older version or want to compare to different versions I just load them up, would they be stored in version control it would be much more tricky to get access to them. A filesystem plugin that allows to transparently access the version control system from withing the filesystem itself without falling back to svn or cvs command line tools would surly help to fix this issue, but so far I havn't seen any of them in the wild.
Last not least there is also the problem with newer version control systems that they are meant for larger projects, managing a single dotfile with svn or cvs is quite a pain, doing it with rcs on the other side is relativly easy. Would be nice if they would provide some 'instant' mode that doesn't require a seperate repository, but just works like RCS in a dot-directory or something like this.
Before you question the sanity of the developers in question, you need to reflect on why you use it yourself and what is sufficient to meet those needs. If the project is small or well partitioned, it might be just fine to use regular ol' backups. Even for more complicated projects, a lot of the VC tools can still be overkill and require too much manual hand holding. Personally, I eagerly await the day where we have filesystems that essentially do versioning themselves. Drive space is cheap, especially when it comes to text files, so I don't see why we can't just have the system maintain snapshots of critical files and then allow you to change the view to a particular point in history.
Souce control is not a reality for every IT development. Unfortunally, some people like to use "directories" to control sources, what is great step to doom the entire project.
At least in the companies where I did work here in Brazil, everybody was using some sort of VCS. However, the common problem is the discipline to use a VCS. Sources that are updated outside the VCS and then deployed to the customers is the main problem I could see so far.
I feel that you must not only use a VCS but have discipline to use it.
Ronaldo Faria Lima
E-mail:ronaldo@ronaldolima.eti.br
Home page: http://www.ronaldolima.eti.br
Keep in mind that there are several projects out there who are nominally using SCC but do not implement effective source control. Here is a recent example from the beginning of the 21st century out of a fortune 50 company:
Only changed or new files were labeled, the majority of the files NOT. Hence the build lineup was different depending on which machine a build was being performed and whether an update from the SCC was done or not. This led to the funny situation where the class composition of an installation was different from environment to environment (test vs qa vs staging vs production).
Nobody knew what exact file lineup was currently in production nor what lineup was in any environment (e.g. production) lets say 2 month ago.
Needless to say that CTO and Mgmt. were thinking that everything is under tight control as the group was using the officially prescribed SCC tool.
New DARCS URL. (Note: Points to same IP address as old URL.)
Most projects outside your hacker by night use version control, although they may not use a diff-based tagging program. Think of Linux. It didn't use "version control" until fairly recently, and yet it was version controlled. Releases are version control. Backup tapes are version control. They work pretty good in THE REAL WORLD. They just take up more disk space. Although, in the real world, you probably end up using a lot more disk space with version control software because everyone is always "checking out" stuff that hasn't been changed, so there are hundreds or thousands of copies of something that you only need once.
Job security
I've seen enough teams that, if you asked the management if they used version control, would answer in the affirmative and indicate the corporate standard (some atrocity like PCVS) SCM software. Ask the people actually writing code, however, and the answer will be no, they don't actually use it. Generalized, there are two reasons. One, the team is too clueless and undisciplined to use version control. The other, the dictated corporate standard is such an awful mismatch for the environment/toolset that the net productivity lost working with it is greater than just using a shared copy and manually resolving conflicts.
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.
- What if at the end of the day you forget to do a tarball?
- What do you do when you want to find a change to a file and you're currently on project-3.216.197 and you're not sure when or why you changed foo.c's logic and you want to change it back but you don't know what you're going to break in the process? I use cvs log. What do you do? Open up hundreds of tarballs trying to find your one silly change? I know you said you don't look at old code, but that's probably because it's too tedious for you to examine all the tarballs.
Others have already answered your questions. Backing up CVS is trivial (read the docs... it's not too much unlike your tarball method), CVS clients play nicely together in my experience, what are you talking about patching your CVS server? You mean upgrading CVS? Just upgrade it. I'm not sure what you mean by that.The benefits are too numerous to list. Read the Cederqvist. It's not very long, and you can decide for yourself if you want it. Basically, it's good for when shit goes wrong (helps answer the question of where, when, and why), when you want to experiment (create a branch... what do you do when you want to experiment? Make two nightly tarballs?), collaborate (I know you said you work alone, but that will not always be the case hopefully), and many more.
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
Wouldn't svn log be easier? It's hard to diff a video.
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
The simplest version (free for single users and some open-source developers) is so simple it doesn't even support branching and merging. The full version does, and it isn't terribly expensive. It's pretty easy to install, too.
Because every single version control system I've used sucked. Or rather, let me rephrase that, they were very good at what they did, but were a pain in the ass to use and were poorly documented. Make something hard to use, and less people will tend to use it.
Perhaps the stat counts SourceSafe as "not using any source control at all", which in my opinion is totally wrong, since there should be a third category for teams "using russian-roulette style source control".
Seriously, I met some MS people who obviously had only used VSS in their lifetime. I showed CVS and they were reluctant at first (which was irrelevant since our whole repository was already on CVS), but they asked around and supposedly MS uses CVS internally in many projects... that was funny in so many levels. They don't eat their dog food. They know their dog food sucks. But they keep it a secret, because CVS is open source and they're against it...
These guys never understood how CVS worked and installed VSS for their own projects, and had someone else sync that with the global CVS repository. I guess some people just don't want to learn better stuff.
Go hug some trees.
huh. i thought they went out of business a couple years ago.
we had problems with everything. a lot of it was probably due to how my company handled the product. but still. there were a *lot* of gui bugs. like we couldn't turn off the tips feature. and everytime a tip tried to launch, it had an error and would pop up an error window. which was insane, because it launched a new tip every time you clicked any button. i remember it being really very very not intuitive either. i couldn't figure out how to fill out a bug. i learned bugzilla in a half hour or so, but i had to keep checking the reference sheets they gave us in order figure out how to around in rememdy. that was 3 or 4 years ago though, so who knows how things are now.
really it was so unpleasant to use and took so long to slog through, that i just stopped logging bugs i found. in retrospect i was disillusioned with the company in general and should have moved on.
good luck.
No, it's still out there. We just paid 10's of $1k for the same sort of headache. The guy in charge of procurement apparently thought that a drag-and-drop gui was a better idea than an opens source project in languages most of his developers already knew. He's not with us anymore, but this creeping monstrosity is about to be core to our business functionality.
"No," says my boss, "I don't want to use that stuff."
"It's easy, and the software is free," I said.
"No, it's too complicated!"
So whenever we need to make changes to the web site, we have to work on the live site (no test site), taking care not to step on one another's toes. Needless to say, I'm looking for another job.
At least where I'm taking my post-secondary education, students aren't educated on the use of source control, and I've seen the results. A lot of times, students will end up with regressions in their class projects without any way to recover any code that worked better.
Even I'm at fault for this in my class projects, sometimes, but generally I use SVN for pretty much everything else.
Christopher S. 'coldacid' Charabaruk -- coldacid.net
Who would willingly* accept a job at a company that didn't have version control?
*Economic need to take the available first job offer doesn't (in my mind) constitute willing acceptance.
This discussion is pretty interesting. Speaking from personal expierience I can safely say I've never really used a version control system until yesterday when I started downloading the cvs version of vegastrike(it's still going). I am ashamed of this fact, in case you think I'm not. i really wish I'd "discovered" them sooner.
I've worked in two programming jobs. One, didn't have any VCS at all. Files were copied one by one. The only "version" was the zipped folder that got emailed to everyone. The second job had a VCS, visual source safe to be exact, but people only used that for the companies legal documents. None of the programmers used it except to check in their code after six months solo work.
Never once in almost four years of university education have I been exposed to any sort of version control system. Then again, in my university, none of the the programmers can use Linux, of any flavour. Most can't use visual studio either... Hmmm. Yup, all our programming lecturers are pretty much incompetant. In any case, such courses exist, so don't be too surprised by coders that can only compile one source file, static programs on windows platforms only. But I digress.
I always wanted to get into some kind of cvs/subversion type VCS, but I never had the oppertunity(or the training). Hopefully by participating in a sourceforge project I will.
P.S.
cvs rocks for downloading apps. Forget cutouts when downloading some 20MB tarball. Just get the cvs download and you'll get the files one by one with download resuming built in. Yes, yes that's not the point of cvs, but I'm on a dialup that drops connections all over the place.
May the Maths Be with you!
Actually, that is a lot like the "plugin" methodology used by SalesLogix. We have a very large, highly customized installation managing almost 500,000 contact records... I would truly love to be able to implement versioning in the system, but that is not possible as all of the code/screens/reports are stored as blobs in the database.
The only moderately reliable method of versioning is copying the code out of the scripts into text files with date stamps.
Coding my way to the next BSOD!
This lets me manage my own files myself without having to be tied to a specific computer/OS/software installation.
Also, using a CVS program adds another layer of complexity and another point of failure. I've heard horror stories about Microsoft Visual SourceSafe crashing (gee, no surprise there) very non-gracefully..... So I decided not to "participate".
Furthremore, in many situations there are non-developers dealing with things. If I let them use a system such as this, all of a sudden, *I* will have to do their checking in and chekcing out *FOR THEM*. Fuck that.
In short... I'd much rather rely on myself than some piece of software I have never used. I'm supposed to just take Software X's word that it will work as described, and never fail? And then drop my own responsibilities and HOPE the program will be responsible for my stuff for me? Bah. Self-reliance is better.
-Clio
Karma: Bad (mostly from not giving a fuck)
Blog: http://clintjcl.wordpress.com
I'm a single developer working mostly on small projects, and svn has been a godsend for me, mainly because I do development from one of many different locations, so svn lets me keep an accessible and centralized copy, so I just do an update when I'm going to start working, a commit when I'm about to leave a particular location and that way I don't mess things up. It's easier than using rsync, with which I've clobbered more than one project because I wasn't paying attention to which direction I was syncing files to.
Also, it gives me a lot of freedom to make changes and mess things up since I can always go back a revision or two. I've yet to use it for a large, multiple-person dev project but at least I know the technology is there when I need it. And svn was dead-simple to install and use!