• G (unregistered)

    I call bullshit on everyone who called bullshit on this one.

    Nowhere in the article does it say there was any code lost. The part that was omitted from the story is

    Article:
    "Wait," a third one questioned, "did you do an UPDATE before the COMMIT?"

    "Did I what?" the second developer replied. "Oh. Crap."

    Exasperated, Mark jumped. "That's it! We're going back to the shingle!"

    "The expressions on your faces are priceless" the third developer said rolling on the floor laughing.

  • Top Cod3r (unregistered) in reply to G

    I call bullshit on you for calling bullshit on everyone who called bullshit on this one.

    G:
    I call bullshit on everyone who called bullshit on this one.

    Nowhere in the article does it say there was any code lost. The part that was omitted from the story is

    Article:
    "Wait," a third one questioned, "did you do an UPDATE before the COMMIT?"

    "Did I what?" the second developer replied. "Oh. Crap."

    Exasperated, Mark jumped. "That's it! We're going back to the shingle!"

    "The expressions on your faces are priceless" the third developer said rolling on the floor laughing.

  • shash (unregistered)

    I'd argue that locks, and 'cvs edit' are really just shingles...

    Slightly closer to enterprisey shingles of course...

  • Moss (unregistered)

    I wonder how much money all the roofers had to pay to get their ads on this page.

  • (cs) in reply to NiceWTF

    It CAN happen, if not using the command line but if clueless users work with certain frontends.

    Example: Eclipse.

    We had this situation at university: students were working on a common project with CVS (and Eclipse's integration of it). But they often lost commits of other users... how did it happen? They right clicked the project root, chose "Team" and "Synchronize". In that view, the left side shows the local source and the right side shows the repository's source, and you have to synchronize the files manually. Of course, they just copied everything from the left to the right... deleting possible changes that were done since their last "update".

    The RIGHT way to do it would have been Team/Update, then Team/Commit...

  • Dave (unregistered)

    the giant 130-millimeter cannon repair

    Two points:

    1. "130mm" on a naval vessel isn't giant, it's small.
    2. It's 128mm, not 130mm.
  • Dave (unregistered) in reply to Dave
    Dave:
    >the giant 130-millimeter cannon repair

    Two points:

    1. "130mm" on a naval vessel isn't giant, it's small.
    2. It's 128mm, not 130mm.
    ... and the third of our two points is:
    1. On a naval vessel they're guns, not cannon.
  • (cs) in reply to asdfafeeawfa
    asdfafeeawfa:
    I'm impressed. They managed to create a shingleton.
    And a shingle point of failure.
  • Greg (unregistered)

    Anyone else noticed that Mark was following XP methods?

    I've never seen clearer examples of DTSTTCPW (do the simplest thing that could possibly work) and YAGNI (you ain't gonna need it).

    The shingle could have worked. And Mark didn't need anything else ... until he did.

  • csrster (unregistered)

    I work in a coding department where we use subversion for all our projects. But for our collective departmental timesheet - a single excel spreadsheet - we use the shingle protocol. It sounds better if you refer to it as Physical-Token Pessimistic-Locking Version Control.

  • (cs)
    "What happened to my code?" Mark asked. "I just did a CVS UPDATE and everything I wrote this morning is gone!"

    [...]

    "Wait," a third one questioned, "did you do an UPDATE before the COMMIT?"

    "Did I what?" the second developer replied. "Oh. Crap."

    Exasperated, Mark jumped. "That's it! We're going back to the shingle!"

    FUD and bullsh*t. CVS won't allow you to commit if there are some changes on the server: you have to run update, and have up-to-date sources before you can commit.

    (I think it is great annoyance of centralized version control models, solved only with either good branching and merging, or distributed version control system)

  • K (unregistered) in reply to Code Slave
    The only way I can see that sort of thing happening is if Mark were to have edited the file before doing a "cvs edit" on it first. On a unix system he would have had to ph*ck with file permissions to do that
    Sounds like you are thinking about perforce. CVS does not work the way you describe.
  • (cs) in reply to G
    G:
    I call bullshit on everyone who called bullshit on this one.

    Nowhere in the article does it say there was any code lost. The part that was omitted from the story is

    ...snip...

    apart from this bit, you mean?

    "What happened to my code?" Mark asked. "I just did a CVS UPDATE and everything I wrote this morning is gone!"
  • (cs)

    shingle? wood? well: http://en.wikipedia.org/wiki/Shingle_dancing -> dancing on a wooden platform

    i know this makes no sense

  • Overthinking (unregistered) in reply to dgvid
    dgvid:
    Unfortunately, Source Safe was so painful to license and manage
    No it isn't.
    Compared to a shingle found laying around the office it is. It is also infinitely more expensive.
    As time went on, the project's scope grew immensely. More and more developers came on board, and the source-control shingle was pushed to its limits. Despite not being in possession of the shingle, some developers broke protocol and edited the library files on the share drive. Finally, Mark agreed to use a simple source repository.
    Sorry, the article conflicts with your first statement.

    Your second statement might be true...without knowing the cost implications of using the shingle (e.g. time wasted waiting for 'your turn') we'll never know.

  • Overthinking (unregistered) in reply to jtl
    jtl:
    Overthinking:
    Unfortunately, Source Safe was so painful to license and manage
    No it isn't.

    Perhaps 8 years ago...

    ok, I'll clarify:

    No it isn't.

    No it wasn't.

    A bad workman blames his tools.

  • (cs) in reply to thomas
    thomas:
    We definitely need a photo of the shingle.

    Nah, a photograph of the shingle on the shingle on a wooden table.

  • Dazzer (unregistered)

    Perhaps, instead of an update, he did a "Get Latest From HEAD", thinking that was an "update"?

  • Loseless Source Control (unregistered) in reply to Dazzer

    While I've never lost code, once it was checked into CVS, several times I've had to go back to previous versions and re-merge them into latest version because the automatic merge got it wrong.

    I have lost code through doing a update. As near as I can tell, the merge tool decided that my changes were not new changes and since it could not find them in the server version, they must have been deleted from there, so it removed my changes.

    So, perhaps the problem is more the merge tools?

  • Jim Cooper (unregistered)

    I feel his pain about CVS. It's worse than VSS - obscure commands, opaque UI (WinCVS is appalling), no way of viewing the repository, and merge can throw away uncommitted changes (3 times in a row on one particularly memorable occasion).

    If it's a choice between the shingle and CVS, I'd definitely be wavering :-)

  • Jim Cooper (unregistered) in reply to Overthinking

    Also, good workmen blame their tools, only they know what they're talking about when they do.

  • buey (unregistered) in reply to SomeCoder

    Heh... noting that some were trivial was an afterthought. The article is very different from what I submitted. For starters, I wasn't the 2nd developer, I came along later. Also, we never ended up using VSS, they just wanted to, but were turned off by someone's bad experiences with it. Alex basically rewrote the whole thing.

  • (cs) in reply to davidyorke
    davidyorke:
    I'm so glad that IT has become so evolved that we have to look nearly a decade into the past to find a WTF. We truly live in an enlightened age.
    Two words: Cow Bell.

    Oops, sorry, COBOL.

    Still, it's pretty damn close to a shingle, isn't it? And awfully common in 2008, too.

  • (cs) in reply to Russ
    Russ:
    real_aardvark:
    It took us two days to figure out between us that the external auditor had copied the entire repository to one side and disabled all access bar HTTP/Apache, because that's all he was used to.

    Oh for a shingle. Or at least a knobkerrie to beat the useless dingbat auditor to within an inch of his miserable little consultant life.

    You do know that the default SVN setup is unencrypted and not secure? You should be using https with mod_svn, although sometimes it's slow as hell.

    No, but I'll bear that in mind; thanks for saving me a good ten minutes of reading the documentation, next time I set up an SVN repository. I mean, I trust you implicitly.

    I wasn't using HTTP at all -- the moron consultant was. I was copying a tgz file through the firewall and updating/committing the whole thing from there. Not ideal, but it worked and was secure.

    My point, which I suspect may have escaped you in your evangelical fervour, was that the "rearrangement" of the repository (which wouldn't even have been there if I hadn't insisted on it in the first place) took place behind everybody's back. Consequently, I was checking around a couple of hundred lines worth of changes into around ten files (you know how web frameworks are) a day, and so was the other programmer -- but to entirely distinct and unconnected repositories.

    The key thing here is that we were committing to two separate repositories. That was so much fun, and so helpful to the business.

    Fuck security -- that's secondary. (My code is more beautiful than Uma Thurmann, but I rather doubt it's as economically important.) Get the damn process right, and don't let assholes from outside screw it around.

    Also, if there's anybody out there still using GUIs for SCC, just don't.

    Source control is far too important to leave to some nitwit third-party supplier, be it the Apache cretinis or any other form of cloaked lunacy.

    Just don't.

  • (cs) in reply to FredSaw
    FredSaw:
    real_aardvark:
    Wait ... you mean there's no source control plug-in available for Notepad?
    Yes, there is. It's available through the File menu's "Save as..." menuitem.
    That's quite possibly the worst joke you've posted so far, Fred.

    (It still got me googling, though. I suspect that a combination of Google and innate arrogance may yet erode my productivity to nil.)

    It's also the first time that I've opened Notepad up in the last two years.

    Damn you, FredSaw!

  • (cs) in reply to buey
    buey:
    You can step on somebody's changes pretty easily in older versions of CVS (we used CVSNT for our server). <snip/>

    Anyone who's ever had to manage a repository for a decent sized group of developers in those days has had to unmangle a botched commit.

    Those days, these days, blah blah blah.

    You're asking for the moon if you expect the dim bulbs here who dribble with a pavlovian reaction to admit that, well, there might occasionally be issues with <insert source control system of choice here. Please don't make it VSS or CVS/>

    Nice tale, though.

  • (cs) in reply to chrismcb
    chrismcb:
    As usual TRWTF is all the comments.
    Let's see.

    You registered for this?

    I can provide some quite naughty experiences, provided by fully qualified and quasi-legal eastern european ladies.

    No need to worry about "soft" ware at all!

    On the other hand, you could just submit something yourself, you buffoon.

  • Jesse (unregistered)

    I worked at a company where a developer who was a little unfamilar with CVS did an update/commit operation that removed a bunch of previous changes.

    Basically, what the unnamed developer did was:

    a) cvs update b) copy the files he'd been working on from somewhere else into his cvs tree, overwriting his local copies of the newly updated files c) cvs commit

    There was a bit of a "oh shit" moment until we realized what had happened.

  • (cs) in reply to A Nonny Mouse
    "What happened to my code?" Mark asked. "I just did a CVS UPDATE and everything I wrote this morning is gone!"
    Yes, yes, my oversight. Apologies for the shit I called on everyone.

    Still, they later realized that all they had to do is revert the changes of developer number two and then all sat down and laughed at it, as in a cartoon.

    I agree that dev.no.2 most likely did this:

    Comment #200970:
    a) cvs update b) copy the files he'd been working on from somewhere else into his cvs tree, overwriting his local copies of the newly updated files c) cvs commit
  • jacekm (unregistered)

    "cvs update && cvs commit" DOES NOT LOSE DATA.

    The story described in the article is false.

  • (cs) in reply to jacekm

    cvs update, then cvs commit, without checking if there were conflicts? That can commit <<<<<<<<<<< markers into the repository... sure, these can be fixed, but would be a great annoyance. svn handles this better - it refuses to commit files with unresolved merge conflicts.

  • Fred Dagg (unregistered) in reply to OperatorBastardusInfernalis
    OperatorBastardusInfernalis:
    cvs update, then cvs commit, without checking if there were conflicts? That can commit <<<<<<<<<<< markers into the repository... sure, these can be fixed, but would be a great annoyance. svn handles this better - it refuses to commit files with unresolved merge conflicts.

    CVS also refuses to commit files with unresolved merge conflicts.

  • d potter (unregistered) in reply to A Nonny Mouse
    A Nonny Mouse:
    G:
    I call bullshit on everyone who called bullshit on this one.

    Nowhere in the article does it say there was any code lost. The part that was omitted from the story is

    ...snip...

    apart from this bit, you mean?

    "What happened to my code?" Mark asked. "I just did a CVS UPDATE and everything I wrote this morning is gone!"

    absolutely. "What happened to my code (in my working directory that was here a minute ago but now seems to be gone (from my working directory))?" is a different question than "What happened to my code (cause i can't find it in the revision history of the CVS server)?". Damn some of you people are overly-critical. If the last cvs command I said I ran was "cvs update", what would make you people think I know for a fact what code is or is no longer in some earlier revision? Does the "cvs update" command do that in your version? sigh

    So if just the dude's working version directory was clobbered, most likely by a CVS newb's poor conflict resolution (delete/add is much easier than hand merging!), that doesn't mean the old code's not still on the CVS server. It's still annoying to see your code clobbered unexpectedly and for the first time, and not know where to go to get it back. i've worked a little with CVS, SVN, and even Clear Case; there's ALWAYS a way to clobber code on accident. In fact, i've seen it done on purpose (IMHO) to make someone else have to do painful merging/conflict resolution for you.

    even if that's not the case, it's possible to mis-use CVS/SVN in any number of ways that could lead to some loss. the magic that makes versioning work is in the process and the communication, not the tool.

    peace.

  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    This is bullshit - if you don't update before a commit and your working copies are out of date, then CVS will abort the commit.

    I've been working with CVS for around 8 years, and I have never once seen anything happen even remotely like that described in the article. I suspect it may be possible to force it to happen, if you mess with file timestamps and edit the files in the local CVS directories, but by accident? Bullshit, utter bullshit.

  • (cs)
    "Wait," a third one questioned, "did you do an UPDATE before the COMMIT?"

    Shenanigans!

    The CVS server should have rejected the second developer's commit if it came from an outdated local version. You can't revert someone's committed code that way.

    That's the point of source control, see.

  • josh (unregistered) in reply to Overthinking

    sarsacm perhaps? after all, they've been using a physical shingle to determine file access/modification thus far, the concept of a serial number or whatever might have not been within their grasp... they only "develop" software

    captcha: "causa" yeah... caus' a lotta problems!

  • Vecchio Corvo Stanco (unregistered) in reply to binford2k
    binford2k:
    Bappi:
    RPJS:
    Single-track railways use shingles to make sure head-on collisions don't occur. OK, they don't call them shingles but the driver of a train entering a single-track section has to be in possesion of a physical object before he/she can proceed. It's worked well for 150 years or so!
    A token or semaphore or whatever the heck.

    I had a project at a locomotive manufacturer, and they had a repair shed I had to cross daily on the way to my cubicle. When someone was working on a locomotive, they'd hang a large (1' diameter) blue disk from the front that said "this sign only to be removed by the person who hung it," and it was to make sure nobody was under the locomotive, or wrapped around some moving part, while someone else try to ride off with it.

    In other words, and desparately trying to get back on topic, this kind of problem predates computers by several times the history of computers.

    A place that I worked in my younger days involved dangerous machinery that broke or jammed frequently. Every single employee also carried a simple master lock. Any time we worked on the machines, we'd "lock out". Every person involved would snap his/her lock over some part that would physically prevent the machine from operating (and mangling an arm or some such.) The machine then could not be operated, either intentionally or not, until all locks had been removed.

    Yep, "Lock out / tag out" procedure, been around for a century or so and still a critical safety procedure in, well, pretty well every bricks and mortar industry in the world. The only real change is scope -- started with railways, expanded to repair of industrial electrics, now applied to pretty well any abnormal operating mode of pretty well any potentially dangerous machine.

    Some people have tried moving to electronic versions, but the state of modern IT is so sucky that it just isn't safe; everyone is sticking to physical tokens for the time being.

Leave a comment on “The Source Control Shingle”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article