Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming Technology

Who Doesn't Use Source Control? 150

Posted by Cliff from the cowboy-care-free-programming dept.
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?"
This discussion has been archived. No new comments can be posted.

Who Doesn't Use Source Control? More

Who Doesn't Use Source Control?

Comments Filter:

  • Alone (Score:2, Interesting)

    by sinclair44 ( 728189 )
    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.
    • I have to disagree with you on this point. I do a lot of small one-person projects, and I can't count the number of times that setting a checkpoint before I start coding has saved me hours of rework when something unexpected happens to what I'm working on. However, I usually use a simple version control system, such as RCS for my one-person projects (CVS, et al. are overkill for that sort of thing).
      • I don't like versioning control. I find it cumbersome to work with, time consuming, and an annoyance. When I need to work with it, I will, but if I can get away with not using it, I do.

        Most developers I've met feel the same way. It's one of those inconveniences you're compelled to participate in, like keeping track of how many hours you work for each client when you'd rather just solve the problems, get the kudos and go home.

        The only time I've found it useful is when you've got multiple developers work
    • Even working alone, sometimes you would want to access the project from someone's laptop, from your wife's PC, etc.
      CVS is godsent. I keep all the documents, files, and of course source I create in CVS. Among other things, it is convinient to backup only one CVS repository instead of multitude of My Documents and /home/biggerman folders.

    • Re:Alone (Score:5, Insightful)

      by maraist ( 68387 ) * <{michael.maraist ... mail.n0spam.com}> on Saturday January 22, 2005 @12:39PM (#11441513) Homepage
      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.

      • I second this. Moreover, many "small projects" are essentially prototyping exercises requiring a lot of fooling around (and changing one's mind). VC is often a much better option than creating a static code base that just accumulates endless comment blocks (especially in a team), e.g.:

        /**
        Hey Bob, I trashed your algorithm something fierce.
        Not sure if that was the right move, now that I think about it. :(
        Not to worry, I commented out the original below (most of it anyway).
        Well, I'm off on vacation.
        */

        I hon

    • There is not much of overhead, ever for tiny project.

      I use VC even for single file projects (in which case I use RCS) or very small projects I work on.

      For my toolbox (mostly EMACS) using RCS is almost transparent - I visit file in read only mode, when I want to edit it, I check out it (C-v v), work on it, then close it (C-x C-q) and describe what I've done. I really wish it would work the same with CVS or subversion.

      I do not this for VC itself, but it half for VC in case I screw up something bad so I c

  • Legal Reasons? (Score:5, Funny)

    by sepluv ( 641107 ) <blakesleyNO@SPAMgmail.com> on Saturday January 22, 2005 @11:44AM (#11441261)
    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 (Score:5, Interesting)

    by hsoft ( 742011 ) on Saturday January 22, 2005 @11:44AM (#11441262) Homepage
    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. :)

    • I'd like to add (Score:5, Interesting)

      by hsoft ( 742011 ) on Saturday January 22, 2005 @11:56AM (#11441322) Homepage
      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 (Score:4, Funny)

        by Hard_Code ( 49548 ) on Saturday January 22, 2005 @01:34PM (#11441891)
        - realize that it really sucks and switch to SVN while others are still wondering how they can get on this new "cvs" wave
        • 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)
          • 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
        • -realize that BOTH suck, and don't use version control.

          Seriously, I'd love to use a version control system for most of my projects, but I seriously don't see any need for it. When I get a source to running condition, I tarball the folder and keep developing. If there were a version control system that didn't take a million years to set up, configure, and didn't fuck the files (don't get me started...), I'd use it. But, I'm not in the mood to look.
          • If there were a version control system that didn't take a million years to set up, configure, and didn't fuck the files (don't get me started...), I'd use it.

            That's the major redeeming facet of cvs.

            Do this once:
            CVSROOT=~/cvs # Put in your .bashrc
            mkdir -p ~/cvs/CVSROOT

            (replace ~/cvs with some other directory in both of the above if you want to--for multiple developers, probably make it somewhere more public and give permissions to a group they're all in).

            Do this to put a project in cvs:
            cd my

      • Re:I'd like to add (Score:1, Insightful)

        by Anonymous Coward
        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 th
    • Don't underestimate the power of ignorance.

      Yes. Revision control is one of those brilliantly simple ideas which are hard to "get" unless you've used it. And I'm talking about even trivial things such as using RCS on a single file. Developers who try to avoid revision control are very common. Developers who do it because they're told to, but never really use it to make their work easier -- I'd say that's the rule.

      Also note that non-developers have almost as much to gain as developers from revision control

      • I have a friend who is a web developer who started using cvs when he was required by clients to collaborate with other web developers. He's just an html monkey, no back end stuff. After the first clusterfuck (where the other guy lost a weeks worth of bot their work), he was given advice from another programmer friend to look into this version control thingie.
        • Ugh.

          Even if you're not using version control (which is pretty much inexcusable, it's almost indispensable for working on private projects at home--with more than one developer it's mandatory, IMO) you should be doing nightly backups. Hopefully he's learned that.

      • I tend to use an analogy of a drawing for revision control.

        When you have created a drawing which is accepted for production or implementation, then it is stored in a filing cabinet for future reference (check in).

        When you need it as a reference, you can retrieve it and look at it. When you need to draft changes, then you use the previous version as reference, but you start a new sheet, instead of doing the drawing on the original.

        And this way you can build up a whole history of the project from day 1.

        Th

        • Try Tortoise SVN. I believe there's a link to it off the official SVN Site. But that's only for Windows. Don't know of any for Linux. I find the best thing to do is to get an IDE that supports it. NetBeans does this for Java. Depending on your programming language, you may or may not be able to find an IDE that supports it.
  • 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.
    • For some environments, it's too much work for the benefit gained. The group I work in supports 6 different ERP environments across various AS400 partitions, with no systematic version control (there are written procedures and forms, but nothing automated). Since our goal is to integrate these 6 ERP's into 3 existing European installations, there isn't much interest in setting up more infrastrucure around the current US stuff.

      That said, we do have problems occasionally with version control, and the microm
    • 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)
      • Perhaps I should expand. I have historically not used any revision control, but have kept old versions of the files around by extensive use of cp and ln.

        The current version of what I'm working on will be in a directory called program-ddmmyy_rev_minorrev with a link from program -> the current revision.

        Generally this works, but the things I'm generally working with are scripts of little consequence and less than 1000 lines. If the new revision doesn't work, I can just link back the old one, and I'm ru
        • Perhaps I should expand. I have historically not used any revision control, but have kept old versions of the files around by extensive use of cp and ln.

          The current version of what I'm working on will be in a directory called program-ddmmyy_rev_minorrev with a link from program -> the current revision.
          So you are using version control of a sort; you just aren't using a version control utility to do it.
      • 1. There is a learning curve. When you a programming and solving a problem, why add to the complexity of your task?

        2. The developer has to admit he isn't perfect. There are no bugs in his code, no feature that can't be easily turned on/off, nothing he hasn't already thought of or antipated that would require different versions.

        3. Administrative overhead. Someone has to set up and maintain the system, with all the responibility and crap that comes with it.
        • 1. The initial learning curve is about as flat as it gets. You need what, an hour of training for initial usage?

          2. If I had a "developer" like that in my projects, I would talk for a minute or two with management about relocation possibilities...

          3. For all intents and purposes, the backup policy works just fine. If you have checkout/checkin scripts, you have already passed the point of no return in VC usage.
    • But in emacs, it's as simple as C-x v v [emacswiki.org]. Really, it's almost as quick as saving the damned thing. Then your problem switches to "how do I get people to write coherent log messages".

      Uploading the code shouldn't be a developer problem, even though it usually is. There aren't enough people who can distinguish between deployment and development.

      -Dom

  • 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 contro
  • 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.
    • 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 vers

  • No Version Control (Score:5, Interesting)

    by SteveX ( 5640 ) on Saturday January 22, 2005 @11:55AM (#11441317) Homepage
    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 [stevex.org]

    • Re:No Version Control (Score:3, Informative)

      by swdunlop ( 103066 )
      This sort of behavior is a little easier to cope with, using DARCS [abridgegame.org], 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

  • Ignorance is bliss (Score:4, Interesting)

    by photon317 ( 208409 ) on Saturday January 22, 2005 @12:06PM (#11441375)

    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.
    • Small chunks of not-to-critical code... yup, that pretty well describes 80% of my job. Usually it results from needing an analysis of some real world problem, and I need a magic widget that converts from Format A, cross references with Format B, and then builds statistical bins containing counts from Format C. It's usually a one-off scenario that I'm looking into some particular business problem, and I just need a quick chunk of code to do the conversions and some of the light statistical stuff.

      They ge

  • Argh. (Score:5, Interesting)

    by crmartin ( 98227 ) on Saturday January 22, 2005 @12:11PM (#11441398)
    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 true (Score:5, Insightful)

    by MobyDisk ( 75490 ) on Saturday January 22, 2005 @12:16PM (#11441424) Homepage
    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.

    • *3) Many individual developers are lazy. They only use it because they are forced to do it.*

      exactly... but lazyness would need you to use it if it made the job easier. most of the time the version control doesn't matter(local backups semi-daily will do).

      if the thing is going to take, say 90 hours to code - what's the point in using hours to set up version controlling? better spend that time on design documents(sure, version controlling becomes kind of a must thing if you don't have any idea what you're go
    • Actually it is part of the CS curriculum, at least it is at RIT. In fact, design, requirements, code commenting, and CVS use are all required components of all CS courses.

      While this may not be a nationwide trend, I'm sure more and more CS programs are beginning to instill these values into CS students.

    • 1) It is not part of CS curriculum so students never hear of it.

      Exactly. We suggest the students in the computer architecture lab at Purdue use CVS, but no one knows how. We're in the process of changing that by creating little mini-lectures that describe how to setup and use CVS effectively.

      3) Many individual developers are lazy. They only use it because they are forced to do it.

      ...which is why I have been coming up with lots of examples that the students encounter and how to solve them using

    • Re:It is true (Score:3, Insightful)

      by utahjazz ( 177190 )

      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 (Score:3, Informative)

      by EvlG ( 24576 )
      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....
  • Of the commerical stuff that I've written, I'm usually the sole author. I've never had formal training in programming, so I've used an ad-hoc system of saving with a new version # appended to file names as I make changes, zipping everything in the source to a file every once in a while.

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

  • Small Cluefree Groups (Score:3, Insightful)

    by Darth_Burrito ( 227272 ) on Saturday January 22, 2005 @12:29PM (#11441473)
    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.

    • Re:Small Cluefree Groups (Score:1, Informative)

      by Anonymous Coward
      How about using a CMS with versioning? There will always be solutions for the non-technical people. A CMS with a browser-based WYSIWYG editor is the route I chose for a small university department where they utilized several maintainers.
      • We're doing a website redesign and I was VERY keen on using some kind of content management system. However, I'd never done anything with one before, and it wasn't clear to me where to start.

        I spent about a week setting up (or trying to setup) different CMS systems on our server and playing with them (drupal, midgard, bitflux, etc). After a week, my conclusion was that all of the open source CMS systems I was encountering were fairly complicated and that learning how to use them and deploy them in a ma
        • If you want a content-only CMS, you may wan to take a look at magnola (http://magnolia.info). It doesn't have the frills of all the portal frameworks out there, but it is very simple to use.

  • Ignorance? Fear? (Score:4, Interesting)

    by esm ( 54188 ) * on Saturday January 22, 2005 @12:49PM (#11441557) Homepage
    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.

    • Re:Ignorance? Fear? (Score:1, Insightful)

      by Anonymous Coward
      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 cr
    • 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.

      Um? Distributed development is not the only advantage of using source control.

  • VC can be had without CVS (Score:3, Insightful)

    by SunFan ( 845761 ) on Saturday January 22, 2005 @12:53PM (#11441579)

    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. (Score:5, Informative)

    by Alpha27 ( 211269 ) on Saturday January 22, 2005 @12:58PM (#11441625)
    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 (Score:4, Interesting)

    by mugnyte ( 203225 ) on Saturday January 22, 2005 @01:02PM (#11441649) Journal

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

    • 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.
      • You're not going to believe this, but right now were using TUTOS for issue tracking, and we'll be moving into Remedy soon, we've been told. Hoboy, now I'm really excited!

  • Plenty of reasons not to, but none good enough. (Score:1, Interesting)

    by Anonymous Coward
    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 f
  • 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.
  • I start in project-0.0.1. At the end of the day I tar -czf project-0.0.1.tgz project-0.0.1, and I upload the tarball off-site.

    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 b
    • If it is just you working on the project, you do not need to run a CVS server at all. Just having the cvs command available on your system is enough. Likewise, this means that you do not have to worry about patching your CVS installation to defend against attacks on the 'Net. Of course, it still makes sense to keep your software up to date against local exploits, but that is just plain common sense.

      To back up data, you just back up the directory that contains the CVS repository. There are no special files,
    • I run Solaris, AIX, Linux, cygwin and standard windows CVS.

      If you have multiple platforms and multiple copies sitting on those separate machines then a source repository is a must. I spent a huge amount of time merging my changes across versions on separate platforms now I simply cvs up and it all works, well I do make portability mistakes but this is easier to fix.

      Backing up your cvs server is simply a matter of backing up the directories that is your repository. You should NEVER have to restore it, yo
    • bingo. this is also how I develop, and what my CECS professors suggested them when I asked if this would be efficient enough. And I've had the same problem with CVS as you have. Very interesting..
    • Here are some problems with the tarball method:
      1. What if at the end of the day you forget to do a tarball?
      2. 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 p

  • The usual reason (Score:3, Insightful)

    by fm6 ( 162816 ) on Saturday January 22, 2005 @02:38PM (#11442367) Homepage Journal
    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.
  • The company I work for initially had no source control (when I joined, I was employee #2), mainly because the boss and the web designer had never heard of it. I mentioned it a few times in the first year, but it didn't really go anywhere - the perceived learning curve put my coworkers off. Then I setup a much more professional setup (proper division between staging and live servers), and we started to grow. With one web developer and one programmer, we didn't overwrite each other very much, and our web deve
  • 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
    • 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
    • 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 sou

  • Man, have I seen this, and it ain't pretty (Score:3, Insightful)

    by BigTimOBrien ( 203674 ) on Saturday January 22, 2005 @02:46PM (#11442437) Homepage
    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.

  • 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 [tigris.org] 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.
    • I use eSVN [kde-apps.org] in KDE. Works okay for most of my SVN needs, but Cervisia [kde.org] 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.
  • Eric Sink [ericsink.com] has recently started writting a detailed HOWTO off of his personal website titles "Source Control HOWTO [ericsink.com]. He doesn't just cover his own companies project "Vault", but also touches on CVS [gnu.org], VSS [microsoft.com], and Subversion [tigris.org].

    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 pers
  • 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
  • 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 th
    • If you don't use CVS or SVN for your multimedia files, how do you find a change that was made weeks ago? Watch the multimedia file 50 times until you see your change?

      Wouldn't svn log be easier? It's hard to diff a video.

  • 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
  • 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 usin
  • 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 dif
  • 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

  • One big segment (Score:2, Interesting)

    by cratermoon ( 765155 )
    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 wor
  • 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 m
  • 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 j
  • 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 f

Slashdot Top Deals

The biggest difference between time and space is that you can't reuse time. -- Merrick Furst

Close