• (cs)

    There seems to be some messing up of "Merv" and "I" near the beginning of this story...

  • (cs)

    would you believe at this very moment i am hand-synchronising our dev/uat/prod code bases because a "senior" developer doesn't believe in source control.. thank f*ck for windiff :(

  • anodes (unregistered)

    Is this a posting from the seventies? I guess I've been spoiled for the last thirty yers or so, but that sort of behavior - bypassing source control - would be a ticket to unemployment everywher I've worked.

  • (cs)

    So Joe is temperamental, abusive, his stupidity just costed the company a lot of man hours of work and his manager just shrugs? It's a cliche but I have to say it... that's TRWTF.

  • (cs)

    Can someone explain what "checking out a file to the dev server" means? Granted I'm stuck here with VSS, but what the hell kind of environment has developers share a single machine? Or, is this just an oversimplification of "he checkin in the file then uploaded the new build to the integration server?"

  • (cs)

    Wouldn't the files be marked with a status of "Modified" or "Needs to be Merged" or whatever the equivalent of "Some dumbshit edited this file without checking it out" is in that particular source control package is?

    Personally, that would be my new hobby. It sounds like the boss is really cool so I guess I wouldn't push my luck and keep trashing the other guy's code just for fun. But really, how good could his code be? You might be doing everyone a favor.

  • SomeBody_Else (unregistered) in reply to anodes
    anodes:
    Is this a posting from the seventies? I guess I've been spoiled for the last thirty yers or so, but that sort of behavior - bypassing source control - would be a ticket to unemployment everywher I've worked.

    You should be thankful then. A couple jobs ago I worked at a gov agency and source control was 3 separate direcotries on 3 different servers. One for Dev, one for Testing, and one for Production. When you needed to work on something, you copied the Production code to your local box, made any changes, copied it to dev for testing, moved it to Testing for more rigorous testing (But done by the dev all the same) and then moved to production at the earliest opportunity. Made it fun when trying to merge the changes made by 3 different devs, we learned to talk to each other often to be sure we did not overwrite someone elses changes.

  • Escalator (unregistered)

    That sort of behavior - being a foul mouthed, abusive asshole to one's colleagues - would be a ticket to a swift kick in the nuts everywhere I've worked. If I were Merv - and had there been witnesses - I'd have been making a formal complaint about Joe. It doesn't matter how much of a "genious dev" you think you are, speaking to someone like that in a work environment is just not acceptable.

    TRWTF as far as I can see is that the company continues to employ such a dick.

  • (cs) in reply to Outlaw Programmer
    Outlaw Programmer:
    Can someone explain what "checking out a file to the dev server" means?

    It might make more sense as "checking out a file FROM the dev server".

    There was a file on the dev server. Joe edited the file without checking it out. Merv then checked it out, made his changes and checked it back in (overwriting Joe's changes).

    That's what I got out of it, at least.

  • SoonerMatt (unregistered)

    Ha! Ha! Ha!

    I had this same thing happen at my workplace. The only difference was that I had been asked to restore a staging environment from svn. The month earlier I had migrated ALL code from VSS to SVN. This allowed all php code to be used by the linux developers too.

    A student dev had been dev'ing on our stage environment and was not using SVN as I had made available and recommended to our team ealier.

    So I overwrote weeks worth of work when I pushed the code to stage.

    The student had to explain to his boss why all of his work was gone, and I had to report to mine that I simply used our version control system.

    I don't see why teams will allow people to not use version control. It costs these teams TOO much money.

  • Codes 4 $ (unregistered) in reply to A Nonny Mouse

    Nonny Mouse-

    For what little it's worth, I've had significantly better luck with WinMerge than with WinDiff. Good luck, I feel your pain.

    The last project I was assigned to couldn't even build out of the source repository. I asked the "senior" developer what was going on. He zipped up a copy of his version of everything, stuck it on a share, and told me that I should just copy that directory and work off of it instead of using the source control.

    I ignored him. The very first issue I put into our tracking database was, "Source code doesn't build." It only took about a week to get it building again. The project was (thankfully) pretty small.

    Hmmm, I should submit some WTFs from that codebase. There were so many...

  • (cs) in reply to SoonerMatt
    SoonerMatt:
    I don't see why teams will allow people to not use version control. It costs these teams TOO much money.
    Yes, but it saves them time, which we all know is free. Wait...
  • Paddington (unregistered) in reply to akatherder

    Okay, so I'm a bit (read a lot) out of date - but I don't practice anymore so forgive me if I'm wrong here...

    but if what you say is right, and Merv's change was minor, then this wouldn't have caused any fuss.

    Isn't it more appropriate that he copied the section from Prod, made his change, and checked that into Dev?

  • ozymandias (unregistered) in reply to Outlaw Programmer
    Outlaw Programmer:
    Can someone explain what "checking out a file to the dev server" means? Granted I'm stuck here with VSS, but what the hell kind of environment has developers share a single machine? Or, is this just an oversimplification of "he checkin in the file then uploaded the new build to the integration server?"

    Once you make changes to the code, many places have you check the new code out to the dev server, for in-place testing.

  • dave (unregistered)

    How do you loose 2 weeks of work? No backups, that’s how. That’s the real WTF!

  • d000hg (unregistered)

    How does a guy who's never used source control, or even worked with a team, get hired as a contractor? I thought the highly paid, unskilled contractors were the ones we vilified, not praised?

  • ozymandias (unregistered) in reply to akatherder
    akatherder:
    Outlaw Programmer:
    Can someone explain what "checking out a file to the dev server" means?

    It might make more sense as "checking out a file FROM the dev server".

    There was a file on the dev server. Joe edited the file without checking it out. Merv then checked it out, made his changes and checked it back in (overwriting Joe's changes).

    That's what I got out of it, at least.

    In my limited programming experiance, the latest files are kept in the repo, so no need to check out from the dev server -- you place a copy on the dev server once it has been altered and notify the testers, who go out and try to break your code. Once all bugs are cleaned up, the stuff moves to stage, and is tested a little more completely, with a snapshot of the prod environment. Once it is clean and ready to go it is deployed to prod.

  • Guido (unregistered) in reply to ozymandias

    The real WTF is that checking out goes to the dev server indeed. Every dev can easily have a local or userspace copy of the source, and keep it up to date with the central repository, merging changes with the other devs. That's what source control is about - if everybody checks out to the same location it kinda defeats the purpose...

  • Brian B (unregistered)

    Guys, cut Joe a break. He's using the good old "All your eggs in one basket" source control.

  • Alastair (unregistered)

    Surely TRWTF is the word "unintelligibler"?

  • (cs) in reply to Codes 4 $
    Codes 4 $:
    Nonny Mouse-

    The last project I was assigned to couldn't even build out of the source repository. I asked the "senior" developer what was going on. He zipped up a copy of his version of everything, stuck it on a share, and told me that I should just copy that directory and work off of it instead of using the source control.

    i think my "senior" developer and yours were separated at birth. mine uses zipped up codebases too!

  • (cs) in reply to Alastair

    Meh. Implementing source control is pathetically simple. Setting up Subversion or CVS is almost trivial compared to other common setup tasks like Tomcat, or even MySQL or Perl.

    Not being able to use source control, or having your changes over written...I don't even know how you'd manage that. At my current gig, I'm about the only person who uses source control, so I've gotten a bit sloppy, and only really overwrite on significant new versions. That means I have a copy on my dev machine, a copy in subversion, and a copy deployed on the server.

    What kind of moron edits the live copy on a daily basis, or, alternately, what kind of moron edits the "checked in" version of the source on the server?

  • n (unregistered) in reply to dkf

    Look at the quotes.

  • RandomWTF (unregistered)

    I've never really done "real" development work either. We aren't really a development shop, so it isn't really surprising that we don't follow all of the standard procedures you would see for software development. We mostly use third party applications, so most of our own code is application interfaces and other custom scripts built around and between applications.

    Still, despite my lack of exposure to doing things the 'right way', I still try. We do use a source control application to check in our changes, and have them automatically migrated to production.

    The WTF? Our source control application doesn't produce any kind of error if it fails to migrate some or all files in a package to production. Files in production that are maintained by the source control application should be in a read-only state, and if they aren't in a read only state when it tries to replace them with a newer version it simply won't make the change. The person who maintains our source control application fails to see the problem here, because "the file should be read only".

    Unfortunately there are years of people half working directly with the file system and half using the source control. While the files maintained by source control should be in a read-only state, I can't necessarily guarantee that they will be. In this circumstance if I try to get a file migrated to production, the source control application will indicate that all is well while silently not actually putting the changes in place.

    Is it really too much to ask that the source control application reliably place the files into production that it's supposed to? Apparently.

    Then they wonder why so many people don't actually use it...

  • (cs)

    This was a great story :-)

    Made me hate my life a little less for the moment! Damn you System.AddIn and all that you stand for!

  • (cs) in reply to ozymandias
    ozymandias:
    akatherder:
    Outlaw Programmer:
    Can someone explain what "checking out a file to the dev server" means?

    It might make more sense as "checking out a file FROM the dev server".

    There was a file on the dev server. Joe edited the file without checking it out. Merv then checked it out, made his changes and checked it back in (overwriting Joe's changes).

    That's what I got out of it, at least.

    In my limited programming experiance, the latest files are kept in the repo, so no need to check out from the dev server -- you place a copy on the dev server once it has been altered and notify the testers, who go out and try to break your code. Once all bugs are cleaned up, the stuff moves to stage, and is tested a little more completely, with a snapshot of the prod environment. Once it is clean and ready to go it is deployed to prod.

    Yea, I was a little lost as well. I think he must have been working on the dev version and when the version from the repo got copied out to the dev server, it over-wrote it.

    I've seen a LOT of people who don't understand source control. They don't check back in, they don't refresh their version, they don't understand about branch merging, etc. But even the most flexible version control systems still have the stoneage option to just let you lock the damn file, and that is enough to stop most common errors.

  • blackd (unregistered)

    Not a single blue comment! Your random comment selector is not working again!

  • Jasmine (unregistered)

    All I could think of while reading this was the immortal words of Captain Kirk - "There's two ways to calm down a hysterical woman, slap her, or kiss her - and I wasn't gonna kiss her"

  • Kehvarl (unregistered) in reply to A Nonny Mouse
    A Nonny Mouse:
    Codes 4 $:
    Nonny Mouse-

    The last project I was assigned to couldn't even build out of the source repository. I asked the "senior" developer what was going on. He zipped up a copy of his version of everything, stuck it on a share, and told me that I should just copy that directory and work off of it instead of using the source control.

    i think my "senior" developer and yours were separated at birth. mine uses zipped up codebases too!

    I've dealt with this same "senior" developer... unless mine is different in that he used the same method (zip the DLLs and throw them on a share) to roll out "final" changes to the users without bothering with the whole testing phase.

  • Anonymous (unregistered)

    Joe probably edited the file directly on the dev server. After commiting the file to CVS, Merv updated the files on the dev server (overwriting Joe's work)

  • (cs) in reply to Satanicpuppy
    Satanicpuppy:
    ozymandias:
    akatherder:
    Outlaw Programmer:
    Wait what?
    It might make more sense as "checking out a file FROM the dev server".

    In my limited programming experiance, the latest files are kept in the repo, so no need to check out from the dev server...

    Yea, I was a little lost as well...

    The thing I'm most confused about is the fact that SOURCE CODE is apparently on this dev server. I mean, I can understand circumventing the source control/automated build systems, but that usually required you to make changes on your local machine, compile, then push to the dev server. The story makes it seem like this guy actually writes code on the dev server...

    Now that I think about it, maybe I'm having a hard time with this because I'm used to a compiled language. Is this story about an interpreted language where there is ONLY source code and not some kind of binary/JAR file? If so, I guess that makes a lot more sense...

  • ThePhwner (unregistered)

    At least its not the company that "updated" bugs by keeping handwritten notes on Bugzilla printouts in a filing cabinet. That is scary.

    CAPTCHA: ingenium

    Ironic given the nature of this WTF.

  • SoonerMatt (unregistered) in reply to Outlaw Programmer
    Outlaw Programmer:
    Can someone explain what "checking out a file to the dev server" means? Granted I'm stuck here with VSS, but what the hell kind of environment has developers share a single machine

    In my environment this would be accurate. In subversion, you perform a "checkout" to your dev environment, which in our case is a shared server with our own workspaces. And then you would "commit" your changes. To get your coworkers changes you perform an "update".

    I'm sorry about you having to use VSS. We started using VSS and switched to SVN. The migration was someone simple with conversion scripts, and we have had less "collisions" or locking problems since. It is great to allow to people to edit the same file at once.

    Of course I haven't used GIT or other versioning systems, I can just attest to productivity/accuracy gains from leaving VSS.

  • Michael (unregistered) in reply to Guido
    Guido:
    The real WTF is that checking out goes to the dev server indeed. Every dev can easily have a local or userspace copy of the source, and keep it up to date with the central repository, merging changes with the other devs. That's what source control is about - if everybody checks out to the same location it kinda defeats the purpose...
    I think that what was supposed to happen. Merv checked the file out locally, edited it locally, then copied it to a remote dev server to verify the changes worked in that environment.

    The problem was that Joe, instead of editing locally and then copying his changes to the dev environment, simply kept editing for two weeks directly on the dev environment.

    Ideally, you check out locally, edit locally, test locally (if possible), then check back into source control and tag it. Then you check out the tagged version to your dev environment for testing.

  • cooljonboy (unregistered)

    If Merv just punched Joe in the gut when he came over there wouldn't be a WTF story. Merv, keep working on those jabs.

  • Michael (unregistered) in reply to RandomWTF
    RandomWTF:
    Is it really too much to ask that the source control application reliably place the files into production that it's supposed to? Apparently.

    Then they wonder why so many people don't actually use it...

    Um, source control is for managing source code, not deploying.
  • my name is missing (unregistered)

    I think any company that allows someone to do such a stupid act is itself stupid. Take away his red stapler and dump him in the basement. Oh wait...

  • Anon Spitzer (unregistered)

    Back at FTP Software there was a guy who refused to use source control, and kept all the source code "encrypted" on his desktop.

  • ves (unregistered)

    Couldn't Joe just grab last nights cron backup?

    I mean fucking. hell.

  • Quango (unregistered) in reply to DOA

    Absolutely agree - the manager's obviously useless and unable to control his team in this organisation.

    I'd have got Joe in my office, told him to apologise to Merv, and a written warning that he uses source control from now on or he's fired.

  • (cs) in reply to Escalator
    Escalator:
    That sort of behavior - being a foul mouthed, abusive asshole to one's colleagues - would be a ticket to a swift kick in the nuts everywhere I've worked. If I were Merv - and had there been witnesses - I'd have been making a formal complaint about Joe. It doesn't matter how much of a "genious dev" you think you are, speaking to someone like that in a work environment is just not acceptable.

    TRWTF as far as I can see is that the company continues to employ such a dick.

    If anybody were to berate me like that on my workplace, I'd be calling security right there, and file a report. In other places, I might just pull a BOFH and taser the guy, teching him a lesson and having some fun while doing so.

  • Mike D. (unregistered)

    If I were Merv, I wouldn't say anything to Joe The next time Joe gets mad at me, I'd start by just ignoring him and getting back to work. Bonus points for iPod use here. If that doesn't make him go away, then I'd tell him that I'd work with him once he caught up with modern programming practices; sloppiness is no excuse.

    Oh, and a recording of everything Joe says would be dandy in case Joe gets creative and escalates his complaints. The boss may have his hands tied due to lack of evidence...

  • Fred (unregistered) in reply to Satanicpuppy

    "Implementing source control is pathetically simple."

    Simple? Try impossible. You have to fill out for ABC-23 Rev Q for permission to talk to the IT peon, who will give you form REW-43 Rev AA which is a request to modifiy a server. After that you have to get form LOE-92 Rev A which is the "Pretty Please with Sugar on Top" (helps to slip a $20) form to the IT Nazi to actually install the Source Control Service on said server.

    You're better off using stone tablets.

  • AlanGriffiths (unregistered) in reply to RandomWTF
    RandomWTF:
    The WTF? Our source control application doesn't produce any kind of error if it fails to migrate some or all files in a package to production. Files in production that are maintained by the source control application should be in a read-only state, and if they aren't in a read only state when it tries to replace them with a newer version it simply won't make the change. The person who maintains our source control application fails to see the problem here, because "the file should be read only". ... Is it really too much to ask that the source control application reliably place the files into production that it's supposed to?

    Version control software isn't intended as deployment software. But if one choses to use it for that purpose, then one ensure it has the required features and use them.

    I've not used a version control system that doesn't report on what it is doing since a "manager's email folder" repository in the early 1990's. You should just need to parse this report.

    But even if you are using something as uninformative as you imply it is easy to script a solution: delete the target directory tree before exporting files to the production server.

  • (cs) in reply to Mike D.
    Mike D.:
    If I were Merv, I wouldn't say anything to Joe The next time Joe gets mad at me, I'd start by just ignoring him and getting back to work. Bonus points for iPod use here. If that doesn't make him go away, then I'd tell him that I'd work with him once he caught up with modern programming practices; sloppiness is no excuse.

    Oh, and a recording of everything Joe says would be dandy in case Joe gets creative and escalates his complaints. The boss may have his hands tied due to lack of evidence...

    There's plenty of evidence there though. The source control will log the checkins. If you look in the logs, you won't find Joes valid checkins. That's evidence enough that Joe isn't using source control.

  • CW (unregistered)

    Does Alex change the names in these stories? Because if this guy's name really is Joe, and if this story happens to take place in Florida, I think I might know him. We were both contractors on the same project - at least up until the day he refused to let the project manager review his "perfect" code, which was getting stuck in an endless loop and bringing down the database every couple of days...

  • Joe (unregistered) in reply to akatherder
    akatherder:
    Outlaw Programmer:
    Can someone explain what "checking out a file to the dev server" means?

    It might make more sense as "checking out a file FROM the dev server".

    There was a file on the dev server. Joe edited the file without checking it out. Merv then checked it out, made his changes and checked it back in (overwriting Joe's changes).

    That's what I got out of it, at least.

    Excuse me for being new to source control. Here's what I don't get. You can't directly edit a file that's in a repository. In SVN at least, the files are stored in SVN's own internal system; be that FSFS or BDB. So if you're editing live files on the server, that means they're part of a "working copy". Right?

    I'm looking into how to keep the most up to date version of the repository out in a live environment, like a website for example. In that case, you'd have your repository out somewhere, then a working copy on your machine to work on the site's files. Then when you commit your changes to the repo, you need to run something like "svn update" on the website. The website is a working copy itself. When the update command is called, the website updates itself with the repo.

    Correct about the use of SVN for websites?

  • (cs) in reply to blackd
    blackd:
    Not a single blue comment! Your random comment selector is not working again!
    A swing, and a miss.
  • And I (unregistered)

    Joe needs some anger management classes or a pink slip. The WTF in my eyes is Merv's boss--for allowing anyone to behave like that and then just shrugging it off.

  • Joao (unregistered) in reply to pitchingchris
    pitchingchris:
    Mike D.:
    If I were Merv, I wouldn't say anything to Joe The next time Joe gets mad at me, I'd start by just ignoring him and getting back to work. Bonus points for iPod use here. If that doesn't make him go away, then I'd tell him that I'd work with him once he caught up with modern programming practices; sloppiness is no excuse.

    Oh, and a recording of everything Joe says would be dandy in case Joe gets creative and escalates his complaints. The boss may have his hands tied due to lack of evidence...

    There's plenty of evidence there though. The source control will log the checkins. If you look in the logs, you won't find Joes valid checkins. That's evidence enough that Joe isn't using source control.

Leave a comment on “Source Control Mastery”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article