• Dave Null (unregistered)

    cat /dev/null

  • Murray (unregistered)

    I've never used CVS, but it sounds pretty crappy if you can screw up so easily.

    Did the rest of the company use source control?

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    Apparently TRWTF is that CVS doesn't warn you that you changed a file before overwriting it with an update command. SVN is strictly better than CVS in so many ways that anyone still seriously using CVS is a fool. There are those who will argue for other source code control systems, and that's fine, but SVN was basically designed as a better CVS for reasons such as this story, and there is even a repository conversion utility.

  • scragar (unregistered) in reply to Murray

    There's a reason SVN despite it's huge flaws described itself as CVS done right.

  • Kashim (unregistered) in reply to Murray

    I've used CVS heavily, and it is very crappy, and easy to screw up. However, I've never seen a CVS setup that would allow either of these errors. Tortoise would immediately say, "Cannot commit, not up-to-date." to the one developer, while "saving local changes to [some file, usually yours with a # at the front, and the version at the back]" to the other. Literally, the entire purpose of source control is to deal with these situations. There are a lot of things CVS messed up, but these parts worked fine.

  • Developer Dude (google)

    Source UnSafe.

    For a few years I worked on a team that used Source Unsafe.

    The repo was stored on a shared network drive where anybody could muck with the repo, even delete it. Source UnSafe was not the only thing stored on that drive - all kinds of files were shared there and anybody with access had full access. Repos also contained various binary files and often build artifacts.

    The lead dev would freeze the whole repo when doing a release candidate build, all development would come to a halt, and when a release made it out the door the whole repo would be backed up to an archive repo, and a new cloned repo would be started with a different name. Meanwhile all developers except the lead would sit around on their thumbs for weeks waiting to start the next release. Archived repos also usually contained the release candidate deployment artifacts.

    If testing revealed any problems with the release candidate, the lead's first knee jerk reaction was to rollback any changes that were remotely related to the problem, especially if the changes were something new, and doubly so if it was refactoring for cleaning up the code. Any new classes were not allowed to be created without approval by the lead after he reviewed it for several days. As a result, it was rare that any new classes were created - any new code was usually added to existing classes, resulting in huge incoherent tightly couple classes with methods that were many hundreds of lines long.

    That is just the tip of the iceberg.

  • Leonardo Herrera (unregistered) in reply to Kashim
    Tortoise would immediately say, "Cannot commit, not up-to-date."
    CVS was released in 1997, and TortoiseCVS in 2007. It was _that_ bad.
  • Two Pi Man (unregistered)

    I used CVS on several big project for over a decade and never saw it delete anyone's work; if you updated before commit then it just merged the changes into your working copy. The worst thing I saw was it could leave some lock files floating around if someone terminated a commit midway through.

  • siciac (unregistered) in reply to Developer Dude

    For a few years I worked on a team that used Source Unsafe.

    So what's your gripe with VSS?

    The lead dev would freeze the whole repo when doing a release candidate build

    That is what you do if you don't have a reliable scheme to manage multiple concurrent branches. If that's your gripe, I agree that VSS is not good at this. That doesn't make it unsafe or broken, just not as feature complete as competitors.

    all development would come to a halt

    Yup, hence the term "freeze."

    If testing revealed any problems with the release candidate, the lead's first knee jerk reaction was to rollback any changes that were remotely related to the problem

    Except for labeling it "knee jerk", that procedure makes perfect sense.

    especially if the changes were something new, and doubly so if it was refactoring for cleaning up the code

    You mean he rolled back code in places where bugs are likely. What a moron!

  • (nodebb)

    "Generally speaking, the complete documentation required for a modern warship-from the GPS calibration instructions to the giant 130-millimeter cannon repair guide-is measured in tons."

    The problem is DoD wide. When the weight of the paperwork equals the weight of the aircraft, then you can go fly.

  • (nodebb)

    So I am a little confused, but if I got it right, CVS is the carrot and the shingle is the stick, right?

  • (nodebb) in reply to Kashim

    However, I've never seen a CVS setup that would allow either of these errors.

    Force commits. If you're using those (and GUIs make it disturbingly easy to do) then you can really mess things up. Newer VCSs would have the same issue except they make it much easier to examine and talk about previous states in the history, and so let you recover work with far less effort.

  • Simon (unregistered) in reply to dkf

    Yep. Git is a huge improvement over some of its predecessors, but there are a few things you really need to be careful doing. Merging incoming changes while you've got uncommitted local changes is one of those... I've regularly seen people screw up and drop all the incoming changes from the merge commit.

  • Klimax (unregistered) in reply to Leonardo Herrera

    TortoiseCVS 0.3 dates to 2000.

  • (nodebb) in reply to dkf

    It's harder than I'd like it to be. If you use hg and try to update a branch that someone else force pushed to, and you've got local changes, then it will abort because it will refuse to rebase your local changes across the force push, but you can at least shelve your changes, update to the new tip, and restore your changes. If you use git then it thinks you've got local work that you want to merge into the remote branch. You've got to stash your changes, hard reset to the origin, then restore your changes; a much scarier-feeling operation. Worse if you need to rebase, because you need to find your rebase point; git pull --rebase won't use the old origin for some reason.

Leave a comment on “Classic WTF: The Source Control Shingle”

Log In or post as a guest

Replying to comment #497806:

« Return to Article