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

    On a wooden table?

  • (cs) in reply to Zonkers
    Zonkers:
    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. The almost unprecedented mention of something positive about VSS, and the fact this came from an MS related forum suggests this is some form of astro-turfing.

    Addendum (2008-06-17 10:21): And having checked the CVS docs, it supports file locks as I thought.

    Indeed bullshit. As a longtime user of CVS, I spend a few times re-reading this trying to figure out how Mark could have lost his changes. Then it dawned on me that this is unfortunately a common piece of FUD that is associated with CVS but it would never actually happen in practice.
    I do. If the developer is stupid enough to run cvs with the -f option, CVS UPDATE will overwrite everything, including your changes.

    This is even easier if you are using GUI frontends, as there is a nice checkbox which says "Force update" or something like that. Check it, and see how your update eats away all the local changes. This is useful if you want to "roll back" to the last commited version, though...

    Oh. And by the way, VSS is the worst nightmare I've ever had to use. I prefer CVS with Cervisia as a GUI frontend.

  • James (unregistered)

    I can't speak for CVS, but I am quite sure that this could have happened under VSS. When you're using the Visual Studio VSS plugin, and you try to sync with the repository, it will prompt for any checked-out files. It's not the default (I think), but there's definitely a "delete my changes and overwrite the file" button on the dialog. I know because more than one of our team devs has clicked it before.

  • Ex-Submariner (unregistered)

    This reminds me of my time in the Navy. A decade ago, I served in the Navy on a fast-attack submarine. The submarine community had just spent 1998 trying out some new-fangled technologies - compact discs and personal computers. The very first job I had when I reported aboard was to destroy the microfiche with all the boat's technical schematics which were being replaced. The old-timers kept trying to impress me with how small the CD's were and how great the whole thing was. I didn't want to upset my new shipmates so I pretended to be duly impressed. Yes, the entire CD library now fits into a single cabinet - that's great. And then we went to destroy the microfiche - and I discovered that I was impressed, very impressed. The microfiche weighed in around a couple tons and completely filled an entire room onboard, which was of course humidity and temperature controlled. Over the next couple days, as I hauled heavy boxes up ladders and across the pier to the burn building, I developed a great appreciation for the compact disc and for the opinions of experienced sailors.

  • (cs) in reply to Al Gore
    Al Gore:
    Outlaw Programmer:
    The Real WTF is that there was no need to get rid of the shingle in the first place. In fact, the shingle is probably the most scalable form of source control known to modern man. Here's how it works: ...

    What happens when two developers get to the shingle at the same time and there is a fist fight over custody? :)

    The solution is already known, there should be 2 shingles per library as in dining philosophers problem ;)

  • (cs) in reply to RPJS
    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.

  • Mark (unregistered) in reply to dmh2000

    "Not being a CVS user, I wondered why they would have lost data." I've used CVS since 1994. The story is BS (IMHO), CVS won't just delete local changes. CVS is far from perfect and there is a learning curve, but I've never seem it lose local edits as the commit process includes merging changes to the repository.

  • (cs)

    Wow! I worked at a dot.com in 1999 and we did almost the exact same thing for 3 critical files that for some reason were not in our source control system (VSS at the time, which may have explained that). We had 3 different single serving cereal boxes. Honey Nut Cheerios, Cinnamon Toast Crunch and another that I forget. Each one was the token for one of the files. Do change the files you needed to have one of the boxes on your desk. It was something that I still am amazed about almost 10 years later.

  • allon (unregistered)

    Obviously they need a simple thimble.

    A simple thimble could cost less Than a single shingle would, I guess. So I think that the single shingle should Cost more than the simple thimble would.

  • Dan (unregistered)

    Obviously, they needed a shingle pool where shingles could be color-coded to give priority. That way a developer would feel safe to make changes, and only need to check with all of the other developers with higher priority shingles. Of course, this would necessitate a Shingle Management Plan, that would also need to be maintained in the Shingle repository.

  • (cs) in reply to Sebastian

    "The story's second half is nonsense. I don't know how the developer managed to wipe his local changes, but it doesn't work in the way the story suggests. On the one hand, CVS doesn't allow checking in if the repository version is newer than the local version."

    Bullshit!!! I have personally committed stuff, had a co-worker commit their stuff and overwrite my change because they didn't have the latest version. Maybe SOME versions of CVS are smart enough to perform a version check, either that or the IDE you are using to perform CVS commits does not allow this, but you most certainly can update CVS without having the latest version.

  • (cs) in reply to allon
    allon:
    Obviously they need a simple thimble.

    A simple thimble could cost less Than a single shingle would, I guess. So I think that the single shingle should Cost more than the simple thimble would.

    HEAD ASPLODE

  • (cs)

    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.

  • Patrick (unregistered)

    We had something like that before switching to SVN. Golf balls. Each golf ball had the name and version number of a particular project, and whoever had the golf ball had the latest changes on his computer. This was actually my idea, as the environment I had entered was "whoever has the source code that most resembles the program in question must have the latest version", and I had been working alone until then. It lasted long enough for someone to need to shout "who has the golf ball for Admin 4?", but not long enough for it to actually break.

  • (cs) in reply to Overthinking
    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.
  • dlaio (unregistered)

    Here is a picture of said shingle.

    http://i287.photobucket.com/albums/ll122/dlaio/shingle.jpg

    And yes, Mark did truly hose up his local working copy. No one knows how. We now use SVN.

  • should have took the blue pill... (unregistered)

    seems I've read this before...

  • me (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

    Actually, no. CVS is NOT SourceSafe and doesn't require you to lock the files. Local modifications are preserved on cvs up no matter what.

  • DKO (unregistered) in reply to Chochos
    Chochos:
    Exactly how the hell does UPDATE before COMMIT delete everything?

    I believe Mark commited his changes, and someone else deleted his code and commited. The subsequent update "deleted" Mark's code.

  • me (unregistered) in reply to amischiefr
    amischiefr:
    Bullshit!!! I have personally committed stuff, had a co-worker commit their stuff and overwrite my change because they didn't have the latest version.

    No, as bad as CVS is, it never was that bad, period. First, you cannot check changes to a file in unless you do have the latest version of the file. Second, local changes are never overwritten by update. Never. Period.

    certainly can update CVS without having the latest version.

    What are you smoking?! Updating from CVS server is, BY DEFINITION, bringing your local files there weren't the latest version up to date so that they are the latest thing after the update. So your claim isn't only incorrect, it doesn't even make any sense!

    I offer you an alternative explanation: some user acted like an idiot and screwed up his local copy. Hint: it was the one that ended with broken copy.

  • Al Gore (unregistered)

    There are ways that CVS or SVN can destroy changes. They involve user error for the most part.

    I've had it happen as I've told on this site before. SVN tried to do a merge and somehow, we ended up losing all the changes we had made in the past 2 hours (during a frantic coding session - this was back in college). It was probably user error as we weren't terribly experienced with SVN.

    The moral of the story is, this COULD happen and it was very likely just user error. Yes, typing "cvs update myProject" won't cause the above scenario but how many times do you hear a user say "all I did was click OK!" when really all they did was screw around with some random settings they shouldn't be touching?

  • efb (unregistered)

    Maybe be typed 'revert' instead of 'update'. They... um... both have the same number of letters... and... both have 'e's in them. Yeah, that's it. Whatever it was, be obviously did something else that lost his changes, and accredited that to the commit process.

    Next on TDWTF : 'svn update' got me on spam mailing lists! I received spam only 30 seconds after running the update! Therefore, it's svn's fault!

  • HonoredMule (unregistered)

    Where's the WTF? It sounds to me like normal project evolution, and a bit of natural reticence against adopting new methodology, reinforced by actual weaknesses in the new system (CVS allows commit on out-of-date checkout? That sounds more like a WTF to me.)

  • that guy (unregistered) in reply to HonoredMule
    HonoredMule:
    (CVS allows commit on out-of-date checkout? That sounds more like a WTF to me.)

    It doesn't. Hence the vitriol directed against this article in some comments.

  • (cs)

    If you had just 'a piece of the shingle' could you modify only 'some of the libraries'?

  • jbrecken (unregistered)

    Source Safe was easier to use before Microsoft bought it and called it Visual; we held back on upgrading to the first couple of MS-branded releases for that reason. It has since gotten better, and I think I'd say it's now a superior product to One Tree's original.

  • (cs)

    The 'S' in CVS is for SHINGLE !!!

  • Russ (unregistered) in reply to real_aardvark
    real_aardvark:
    The.Jxc:
    Gotta agree with the "bullshit" call on this one.

    If you have local changes waiting for commit, an update will either:

    • Do nothing (if nobody changed the code), or...
    • Merge the changes cleanly (if it can), or...
    • Merge the changes but mark conflicts with >>> <<< markers

    Under no circumstances will CVS delete your local changes.

    Ah, the wonderful innocence of youth.

    Of course CVS won't delete your local changes (although you're missing out the cvs mangle -- oops, "cvs merge" -- command).

    Once you bring in Source Control, though, you bring in Process. All sorts of unexpected things can go wrong with Process.

    My last (web) project involved working from home. "How would that work?" they asked. "Um, Subversion," I said. "I'll help you set it up."

    Now, ignoring the minor glitch that the Sysadmin insisted on installing it on a server behind the firewall and not giving me direct access to it, this worked quite well. Two or three times a day I'd have to field calls as to why "Subversion is broken!" and demonstrate that, in fact, it wasn't. The other programmer was an excellent human being, and we finally got The Process working.

    Right up to the point where they hired an external auditor who "corrected" the Subversion configuration, to the point where it didn't work.

    "Subversion is broken!" a hysterical series of calls ensued, all the way up to Upper Management. (Upper Management in a ten-person company is a Big Deal.)

    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.

    Figuring out how to get everything back together again was a bit of a pain, and while we were doing that the project collapsed, because we weren't delivering agiley code fast enough. Which, incidentally, was the one thing that the external auditor was brought in to ensure.

    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.

  • (cs)
    ...only he who possessed the shingle was allowed to edit the common libraries.
    What... no conch shell?
  • (cs) in reply to real_aardvark
    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.
  • buey (unregistered)

    I'm the guy who sent in this WTF, and I'd like to answer a few of the questions that have popped up:

    • Alex took some egregious "liberties" with my submission, some of which are pretty trivial, I suppose. We're located in Connecticut, not Idaho. Our system doesn't track the movement of classified information, it stores the info, handles things like pushing out updates, logs day to day activities, and basically just helps the sailors do their jobs. We basically house their documentation and give them a bunch of little apps they use to streamline their own processes, all while keeping everything nicely integrated and easy to access with a single sign-on.

    • I ain't astro-turfing for MS, like ever. VSS sucks.

    • You can step on somebody's changes pretty easily in older versions of CVS (we used CVSNT for our server). Whatever version we were using, it most certainly did allow you to check in out of date files. Nobody's changes were lost, though... that's just what some people inferred from the article. 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.

  • (cs) in reply to DKO
    DKO:

    I believe Mark commited his changes, and someone else deleted his code and commited. The subsequent update "deleted" Mark's code.

    I agree. We had a similar situation with subversion not long ago. One of our developers found his committed changes kept disappearing when he did an svn update. It turned out that another developer (who has since left the company) was doing svn updates and then instead of using the merged working copies was copying his pre-update version of the code over the top of the merged copy. This is not the fault of the tool, it was the fault of a tool, or, to be honest, several tools including the one who was supposed to teach newbies how to use Subversion properly (i.e. me).

  • Michael G (unregistered) in reply to FredSaw

    That's what I was thinking--when your source control system is taken from "Lord Of The Flies", you know you have a problem.

    "'Kill the beast! Cut his throat! Spill his blood!'"

  • b0b g0ats3 (unregistered)

    FIST!!!!!!!!

  • SomeCoder (unregistered) in reply to buey
    buey:
    I'm the guy who sent in this WTF, and I'd like to answer a few of the questions that have popped up:
    • Alex took some egregious "liberties" with my submission, some of which are pretty trivial, I suppose.

    So which is it, trivial or egregious? :)

  • (cs) in reply to me
    me:
    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

    Actually, no. CVS is NOT SourceSafe and doesn't require you to lock the files. Local modifications are preserved on cvs up no matter what.

    The situation I was referring to would be when you are using "watching", where it marks files as being edited in CVS (but not as a lock, just a warning to other users) and it switches the file from read only to read/write. You cam also do a "cvs unedit" which reverts your file to the original version, and removes the edited mark on the CVS server.

    Needless to say, it's difficult to do what was described in the original article.

  • Fedaykin (unregistered)

    I pity any developer, even a person working alone, that does not understand the usefulness of source control.

  • (cs) in reply to Fedaykin

    I've actually used the shingle system on top of CVS. It was used to enforce consistent check-ins -- a developer would update and run tests, get the shingle (a rubber chicken, actually), update again, make sure the changes build and test out, and check in, and then relinquish the chicken. This was needed because CVS commits are not atomic (unlike SVN or Perforce).

    However, by 1999, we had switched to Perforce, and I forced the place I moved to after that to do the same when I found they were still using CVS. CVS is ancient history. And, if you can afford it, Perforce is usually a better choice than SVN.

  • (cs)

    TRWTF is that many commenters don't realize that a cvs update -f is pretty much able to revert your changes ... but oh well...

  • asdfafeeawfa (unregistered)

    I'm impressed. They managed to create a shingleton.

  • (cs) in reply to Jon W
    Jon W:
    I've actually used the shingle system *on top of* CVS. It was used to enforce consistent check-ins -- a developer would update and run tests, get the shingle (a rubber chicken, actually), update again, make sure the changes build and test out, and check in, and then relinquish the chicken. This was needed because CVS commits are not atomic (unlike SVN or Perforce).

    However, by 1999, we had switched to Perforce, and I forced the place I moved to after that to do the same when I found they were still using CVS. CVS is ancient history. And, if you can afford it, Perforce is usually a better choice than SVN.

    Dunno, I used to think the same, (i.e the Perforce / Source Despot / Vault line of SC was the way to go) recently I have really come to love SVN over.. well.. pretty much anything else really...

  • frustrati (unregistered) in reply to danixdefcon5
    danixdefcon5:
    TRWTF is that many commenters don't realize that a cvs update -f is pretty much able to revert your changes ... but oh well...
    If I remember correctly, cvs update -f will still keep backups of locally changed files...
  • binford2k (unregistered) in reply to Bappi
    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.

  • (cs)

    As usual TRWTF is all the comments.

  • (cs) in reply to Code Slave
    Code Slave:

    The situation I was referring to would be when you are using "watching", where it marks files as being edited in CVS (but not as a lock, just a warning to other users) and it switches the file from read only to read/write. You cam also do a "cvs unedit" which reverts your file to the original version, and removes the edited mark on the CVS server.

    Needless to say, it's difficult to do what was described in the original article.

    How it is conceptually different from "multiple checkout" in VSS?

  • (cs) in reply to Michael G
    Michael G:
    That's what I was thinking--when your source control system is taken from "Lord Of The Flies", you know you have a problem.

    Lord Of The Files?

  • (cs)

    Anyone else have to Google what a "shingle" was? I had never heard the term before. Until today, I thought shingles was a disease.

  • Rourke (unregistered)

    Our system involved a different stuffed toy for each module. Scalability was achieved when sticky labels were attached so that each developer knew that the blue dinosaur was the comms library while the green spotted monster was a certain client's GUI (uncanny resemblance).

    The system fell apart when someone kicked the frog under the fridge and no-one could work on data definitions for a week. CVS was enforced soon afterwards.

  • Top Cod3r (unregistered)

    We tried a system like this, but what ended up working for us in the end was as team leader, I had all the junior developers email their code to me, and then I would be in charge of merging it into the main trunk. The advantage of doing it this way was I got to do code reviews whenever a change was made, and was able to determine when one of the junior developers was messing up.

  • Top Cod3r (unregistered) in reply to Nozz
    Nozz:
    Anyone else have to Google what a "shingle" was? I had never heard the term before. Until today, I thought shingles was a disease.

    Didn't you read the article? A shingle is something that you pass around the team to make sure two people don't overwrite the same file. Sheesh!

Leave a comment on “The Source Control Shingle”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article