• Joe (unregistered) in reply to Fred
    Fred:
    "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.

    Hey, I didn't know you were a coworker of mine. What floor are you on? I say we band together and raid IT!

  • Chris (unregistered)

    I don't get how people can be against source control. I'd never used it in school, but at my current employer (and my first) we use ClearCase, I'd never develop large applications without it again.

    Also, how does one bypass source control? Here, we make our branches, and have a release team responsible for merging everything into a release branch and building from that. If you bypass source control, your work doesn't make it into the release. Granted the release team won't deal with non-trivial merges, so we usually make our own un-official release branch and give that to release to merge into the official release branch and build.

  • True WTF (unregistered)

    I can't fathom not using source control.

    It's a bloody fundamental tool of software development, and it's absurd not to use it. There is absolutely no excuse. It's simple and reliable.

    If you were a mechanic, would you forgo buying wrenches?

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

    Depends, is your name Merv?

  • ben (unregistered) in reply to Joe
    Joe:
    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?

    Well, you're not completely wrong in that, yes, the production site does ultimately pull the code from the SVN repository. But just doing an "svn up" live in the wild is a ghetto way of doing things. You would typically use a tool that does the basic update from the repo and a lot of other necessary housekeeping; Depending on your environment you might use capistrano (RoR) or do some magic with massive deployable WAR/EAR files in Java ...

  • (cs) in reply to Chris

    Based on how the story was worded, it seems like everybody checks out to the same server and works out of the same working directory. Which is a WTF in itself.

  • RandomWTF (unregistered) in reply to Michael

    Maybe so, but that's how were 'supposed' to do things here...

  • RandomWTF (unregistered) in reply to Michael
    Michael:
    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.

    I don't doubt that you're right, but that's the established procedure of how were supposed to do things. Maybe that's the actual WTF...

  • Morasique (unregistered) in reply to akatherder

    It seems to be a trend on here lately that all the source control stories are by people apparently using terrible source control, all of them would be prevented by any rational source control package. My question is if everyone uses source control except Joe, how does he ever keep any of his work? This would just keep happening to him, everything he does would eventually be overwritten

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

    Joe, is that you? hehe, just kidding.

    Typically people use seperate tools for deploying vs source control. So you would code on your machine and check your changes into your source control system.

    Then your continuous integration system on your build server would get the latest version of the code, perform a build of it, run any unit tests that you might have and deploy it if all the tests passed.

    So you should really not be editing anything on that final server.

  • MyFirstJobHadAUnixNon-GuruLikeThat (unregistered)
    f he wasn't yelling at you, he was yelling to you about his incredible feats of software development strength. "I worked on [incredibly ancient mainframe] back when they were state of the art! You young punks with your C and your DB2!"

    My first job, I had one of those. He would always talk about, "when we wrote Unix..." but he was pretty much incompetent with it, and I can't imagine that he had anything to do with it. Part of my reason for that is the next fact: He would also talk about his Congressional Medal of Honor, which I now know is BS. 95% of the people who go around claiming to have a CMH are liars (the other 5% are real heroes).

    Many places I have worked since then have been slow on the uptake of version control, or haven't done it in a reasonable way. It's one of the things I always insist on. There's no sane way to do a project otherwise.

    And going with version control is the idea that your web app should be an installable product, meaning that it isn't married to the particular infrastructure, and that it can be easily installed in an isolated test / dev environment. Many places don't understand that and how problematic it is to violate that.

    Android seminars - the future of mobile platforms

  • Joao (unregistered) in reply to Morasique
    Morasique:
    It seems to be a trend on here lately that all the source control stories are by people apparently using terrible source control, all of them would be prevented by any rational source control package. My question is if everyone uses source control except Joe, how does he ever keep any of his work? This would just keep happening to him, everything he does would eventually be overwritten

    Maybe his source code is useless and nobody cares about what he eventually writes

  • SoonerMatt (unregistered) in reply to my name is missing

    Right. I have never had an instance where "saving time" and "cutting corners" did NOT come back to bite me.

    I know it sounds cliche, but it gets truer every day for me.

  • (cs) in reply to AlanGriffiths
    AlanGriffiths:
    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.
    That's some seriously bad advice right there. I'd go so far as to say that it's a worse "solution" that having no source control at all and simply editing files on the production server.

    (1) If at all possible (and the only constraints are disk space and installation time) take a back-up of all important files before every installation. Otherwise roll-back is ahem problematic. (2) In the typical case, the set of files on the production server is nothing like the set of files in source control. Things like databases probably shouldn't be under source control at all (bar a SQL dump file of the DDL). Things like configuration files are almost certain to differ between development, test and production. Even script files may well differ radically. And then there's "emergency patches" on the production machine -- we've all been there, even though we shouldn't have.

    Bottom line: put a significant amount of effort into developing an installation procedure, complete with documentation, tick-boxes (yeuch, but good in this case for use as a personal audit trail when the inevitable goes wrong), basic sanity checks and a proper roll-back procedure.

    Checking out directly from source-control just doesn't cut it; not even for a simple web site using PHP. Looks like Joe was just a tiny sub-set of the WTF-heads out there.

  • (cs) in reply to Morasique
    Morasique:
    It seems to be a trend on here lately that all the source control stories are by people apparently using terrible source control, all of them would be prevented by any rational source control package.

    I'm not sure that installing ClearCase is necessarily the best solution here.

  • Al (unregistered)

    I worked at a place a while ago but could only take it for two months. In my interview, I checked with the 'technical director' what development tools and source control system they used. He replied, very smugly, that they had the latest Visual Studio and VSS.

    When I started the job, I found out that they did indeed have Visual Studio 2005 and the latest VSS, but unfortunately they were both sitting in neat shrink-wrapped boxes in a filing cabinet.

    We actually worked with VB6 and didn't bother with the luxuries of source control. Any changes you made were done to the live server. After the first time I lost 3 days of work because someone had overwritten it, I ran subversion locally on my computer and prevented the problem ever happening again (to me).

    Working with a live server certainly instills a work ethic of getting something right first time ... though more often that not, a bug crept in and everyone was in a state of panic for hours on end. Ahhh ... happy days ...

  • McLovin (unregistered)

    Wow, I thought only desktop support peons like myself took "@$$-whippins" like that.

  • katastrofa (unregistered)

    In my company, people have been fired for avoiding using the SVN repository. It's taken very seriously.

  • katastrofa (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.

    But then it's nonsene, because the only way to edit the repository's contents should be by checking the stuff in.

    How could Merv overwrite Joe's working copy? Or was this "source control" setup like that Joe could edit the repository directly? Then it was bollocks.

  • Joe (unregistered) in reply to ben
    ben:
    Joe:
    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?

    Well, you're not completely wrong in that, yes, the production site does ultimately pull the code from the SVN repository. But just doing an "svn up" live in the wild is a ghetto way of doing things. You would typically use a tool that does the basic update from the repo and a lot of other necessary housekeeping; Depending on your environment you might use capistrano (RoR) or do some magic with massive deployable WAR/EAR files in Java ...

    Agreed on the pushing of changes directly onto the live server. For the larger sites I maintain, I would never do it that way. Plus, those sites tend to be run by a CMS (Drupal) + MySQL so a simple repo of their files wouldn't apply.

    Where I'd like an improvement in workflow, it's with a number of mini-sites I publish. They consist of HTML, PHP, CSS, and JavaScript. The contents are more or less static text within the HTML files. The internals are very basic; they work off some templates that I reuse. There's no DB backend, logging, etc. Once in a while when a file needs to be tweaked, it'd be nice to maintain version control.

    However, I also don't need a complicated deployment strategy either. A simple "svn update" should work in that case. Anyone disagree?

  • katastrofa (unregistered) in reply to Joe

    "svn export" is better for deployment.

  • (cs)

    I'm pretty sure I've worked with Joe. Joe is his real name. He has those ticks and some others which are worse. He likes to verbally attack new people with considerable viciousness. And he routinely regards himself as being above all the rules, even ones that the entire programming world knows are just a good idea, like version control.

    Any attempt to get the manager to understand how much harm Joe does is wasted effort—years of effort, in my case. It was a major reason for my departure.

  • JohnLocke (unregistered) in reply to Al
    Al:
    I worked at a place a while ago but could only take it for two months. In my interview, I checked with the 'technical director' what development tools and source control system they used. He replied, very smugly, that they had the latest Visual Studio and VSS.

    When I started the job, I found out that they did indeed have Visual Studio 2005 and the latest VSS, but unfortunately they were both sitting in neat shrink-wrapped boxes in a filing cabinet.

    We actually worked with VB6 and didn't bother with the luxuries of source control. Any changes you made were done to the live server. After the first time I lost 3 days of work because someone had overwritten it, I ran subversion locally on my computer and prevented the problem ever happening again (to me).

    Working with a live server certainly instills a work ethic of getting something right first time ... though more often that not, a bug crept in and everyone was in a state of panic for hours on end. Ahhh ... happy days ...

    And I'm sure neither your co-workers nor your "technical director" would understand how SVN works and would still think that zipping files is the only reliable way of handling source code. You may end up having a discussion like:

    • I don't understand, how does this handle changes? Developers work on the same project, at the same time, and can change the same files? This is not safe! This is not reliable!
    • Source control tools such as SVN are used worldwide by all the major software companies in the world, so I'd say it's reliable, yes. SVN's merging handles parallel development much better than VSS or no-source-control (which is better than VSS).
    • Merging? How am I going to trust this? What if two people change the same lines of the same file? How am I supposed to know what to do?
    • SVN doesn't read minds. You have to tell SVN what to do next. Without SVN that would be even worse! Using SVN, the only way of overwriting someone's changes is by willing to do so. Even if you end up overwriting something, you can roll back to a previous revision.
    • I don't buy it. I'd rather tell other developers not to open project X while I'm doing something big. I refuse to understand how SVN works, and I love to have to unzip hundreds of ZIP files when I need a change history! SVN sucks and I'm a fucking genius!

    I fucking hate when people just don't want to understand that source control is not only a major plus, it's supposed to be a damn requirement. And why the fuck is it so hard to understand that there are source control tools better than SourceSafe? Why do some people say "We're going to use SourceSafe", as if they were doing something innovative? For fuck's sake, it's ridiculous.

  • Pete (unregistered) in reply to blackd

    WTF

  • Ed Swangren (unregistered) in reply to DOA
    DOA:
    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.

    The word "costed" is a WTF in and of itself.

  • ambrosen (unregistered) in reply to JohnLocke
    JohnLocke:
    And I'm sure neither your co-workers nor your "technical director" would understand how SVN works and would still think that zipping files is the only reliable way of handling source code.

    Especially as SVN's free software, and that must mean it's scary and threatening to all they hold dear. Or at best means that they have to relearn everything they know. And probably feel guilty about owning an Audi and everything.

  • Fedaykin (unregistered)

    Sounds like their source control operation was implemented in a very WTF way as well. It sounds like they had a single working copy for all or at least >1 developer. At least that's how I read it when it talks about his checkout overwriting the jerk's changes.

    Not using source control is just a horrible failure. Using it in a moronic fashion is a true WTF.

  • (cs) in reply to VGR
    VGR:
    I'm pretty sure I've worked with Joe. Joe is his real name. He has those ticks and some others which are worse. He likes to verbally attack new people with considerable viciousness. And he routinely regards himself as being above all the rules, even ones that the entire programming world knows are just a good idea, like version control.

    Any attempt to get the manager to understand how much harm Joe does is wasted effort—years of effort, in my case. It was a major reason for my departure.

    I'm pretty sure everyone has met at least one Joe in their lifetime. Especially with that point about not being able to get rid of him, as management sees him as a critical resource; usually this is because the "Joe" programmer/sysadmin has rigged things in a way he, and only he can fix stuff when something goes wrong.

    Its kind of like having the whole company by the yarbles...

  • Alex (unregistered) in reply to JohnLocke

    You must have been under the table with a tape recorder at my last job... :(

  • Edward Royce (unregistered) in reply to A Nonny Mouse
    A Nonny Mouse:
    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 :(

    Been there.

    Frankly the first thing I ask about any new job is what source code control is in use. The second question concerns bug tracking software.

    Far too often the answers are: None and Excel.

    Ugh.

  • Joao Marcus (unregistered) in reply to Edward Royce
    Edward Royce:
    A Nonny Mouse:
    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 :(

    Been there.

    Frankly the first thing I ask about any new job is what source code control is in use. The second question concerns bug tracking software.

    Far too often the answers are: None and Excel.

    Ugh.

    Mine would be: None (except for SVN which I started using myself for three projects) and a horribly unusable and slow Notes-based ticket system with no workflow support, horrid attachments support (you can attach files but can't download them, go figure), no way to view tickets assigned to other developers, etc.

  • ben (unregistered) in reply to Edward Royce
    Edward Royce:
    Frankly the first thing I ask about any new job is what source code control is in use. The second question concerns bug tracking software.

    Far too often the answers are: None and Excel.

    What kinds of jobs are you applying for?

  • Ste (unregistered) in reply to DOA
    DOA:
    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.

    and his manager just shrugs? The shrugging asswipe is the root of many WTF. If they care a bit its at least easier to tolerate.

  • ^H^H^H (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...

    Dear RandomWTF. Source control applications are not installers.

    Hmm. PEBKAC. What you are experiencing is default behavior. Do not panic. Have a latte.

    By default my scc (source control client) will not overwrite files if the readonly bit has been cleared. It does prompt me though to overwrite. The scc will usually assume that that since the file is not readonly that you've gone ahead and modified it without using the scc to 'check out'. When you check in a file the scc usually sets the file to readonly to indicate that action. It's a pretty lame mechanism, but scc's are typically pessimistic and assume a writable file is a file that has been modified outside of it's control.

    So, to sum up, source control clients are not installers - it's a repository of files with history, that when used properly, helps keep everyone's changes in sync.

    1. get everything from source control to a clean location
    2. compile it (if it's compilable code)
    3. package it up to be installed.

    Dev's usually create installers/packages for dev/test/stage/production with each having slightly different settings. Automate as much as you can to have a repeatable process.

    Now take the correct package and install it. The scc client is only used in step 1. Don't run scc on production.

  • (cs)

    Wait,the real WTF is what the fuck source control system overwrites everything, and not just the module that's changed?

    Unless Merv and Joe were editing the same file, any source control application should have just overwrote that one file; anything that Joe was working on should have remained untouched, if it wasn't modified.

  • Al (unregistered) in reply to JohnLocke
    JohnLocke:
    I fucking hate when people just don't want to understand that source control is not only a major plus, it's supposed to be a damn requirement. And why the fuck is it so hard to understand that there are source control tools better than SourceSafe? Why do some people say "We're going to use SourceSafe", as if they were doing something innovative? For fuck's sake, it's ridiculous.

    Unfortuantely, the people who dislike source control are often also the people who dislike everything else which is usually taken for granted as standard practice. The number of times I have heard managers saying: "Yes, those things are fine for other software companies. However, our business isn't the same as theirs and we can't use standard off-the-shelf tools. We'd write our own if we had time, but we're just too busy."

    Normally, the reason they're too busy is because they're constantly fire-fighting problems caused by not having bug tracking or source control. Meh.

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

    Distributed version control is for you then.

    Start working with git or darcs, push patches to each other's machines without the need for it to be installed on the server.

    You can still submit your forms, and hope to get it up on the server as well, but in the meantime, it's much better.

  • Joao Marcus (unregistered) in reply to drinkingbird
    drinkingbird:
    Fred:
    "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.

    Distributed version control is for you then.

    Start working with git or darcs, push patches to each other's machines without the need for it to be installed on the server.

    You can still submit your forms, and hope to get it up on the server as well, but in the meantime, it's much better.

    A DVCS can be a good idea even if you're not going to push/pull changes to/from other machines. I even used PortablePython+Bazaar inside a company that had a very strict policy like : "The use of free software, including freeware, opensource, etc, is forbidden". Developers were constantly afraid of changing the source code, zipping several versions of the same project. As of me, whenever I did something wrong, I just needed to roll back to a previous revision.

  • (cs)

    I think an explanation was left out.

    Why is Joe still working there? Why hasn't he been fired yet?

  • scotth (unregistered) in reply to blackd

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

    Some idiot musta checked in a change and blew away comment selector functionality.

  • Sanity (unregistered)

    To everyone who can't imagine not using source control... Until BitKeeper, Linus Torvalds didn't. He used patches and tarballs.

    Me, I've practically grown up on easy source control -- tools like bzr and hg make it trivial. When setup is "bzr init", there's really no excuse...

    Well, unless the previous revision will be mirrored all around the world. As Linus says, "Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it."

    So if your name is not Linus Torvalds, there really is no excuse...

  • Bo, the ancient mainframer (unregistered) in reply to Outlaw Programmer
    Outlaw Programmer:
    ... 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...

    Common occurrence in mainframe development. In that kind of setup there (often) is no "local machine" except the dev server.

    Actually when reading the story I was almost certain that the story was from a certain mainframe installation in Denmark. Only differences:

    • "Joe" considered it a requirement for any system to have a component written by him in assembler
    • The source control system in use was written by "Joe" - in assembler (of course)
    • Using the source control system was a requirement for everyone BUT "Joe"
    • "Joe" didn't have a manager - Joe WAS the manager

    Leaving that place was, well, not a tearfull experience...

  • 1747 (unregistered)

    Having SCC and not have access to test/qa/etc. locked down bogs my mind.

  • csrster (unregistered) in reply to icelava
    icelava:
    I think an explanation was left out.

    Why is Joe still working there? Why hasn't he been fired yet?

    ... and that's the real WTF.

    Either that, or the fact that Joe's boss hasn't been sacked for not sacking Joe.

  • Dave (unregistered)

    cant you check out previous versions in most if not all source control systems? i think joe needs a swift and sharp slap up-side the head tbh - if he acted like that towards me id tell him where to go.

  • The real wtf fool (unregistered) in reply to katastrofa
    katastrofa:
    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.

    But then it's nonsene, because the only way to edit the repository's contents should be by checking the stuff in.

    How could Merv overwrite Joe's working copy? Or was this "source control" setup like that Joe could edit the repository directly? Then it was bollocks.

    How I see the situation: They are developing a web app in php or similar and have just one dev web server with php installed. So everyone does their development on the files in the dev server. Joe is editing some php files on the dev server, has all his changes done. Merv checks a file out from source control to the dev server, thus overwriting the file that Joe has edited. So all Joe's changes are overwritten. The only thing that doesn't support this hypothesis is that the checkout did not warn on seeing the file was different to the version in the repository, but maybe some SCCS behave like this?

  • Matt C (unregistered) in reply to blackd

    that's the thing with randomness :P

  • (cs) in reply to Sanity
    Sanity:
    So if your name is not Linus Torvalds, there really is no excuse...
    Changes name by deedpoll ;^)

    Actually, there is one and only one reason I've never used formal source control in my work. I've never worked in a team larger than.. well... 1. I occasionally worry that my lack of source control knowledge will be a barrier to getting a job on a larger dev team in the future; but then I come and read TDWTF and realise that I'm probably not so badly off after all ;^)

  • (cs) in reply to True WTF
    True WTF:
    I can't fathom *not* using source control.

    It's a bloody fundamental tool of software development, and it's absurd not to use it. There is absolutely no excuse. It's simple and reliable.

    If you were a mechanic, would you forgo buying wrenches?

    By 'wrenches' you mean 'a time machine'?

  • The real wtf fool (unregistered) in reply to JimM
    JimM:
    Actually, there is one and only one reason I've never used formal source control in my work. I've never worked in a team larger than.. well... 1.

    Still no excuse! I have recently started using SCC for my hobby projects at home and it still has great benefits even when there's just you. You feel less constrained about changing things as you know you can always go back and look at how the code used to be. You have a documented history of why you made each change, which is useful when you're looking at some ancient code and wonder just why you did it like that. You can easily tell which is the latest version if for example you are doing web development and changing the web site from various machines - just download the version of the web server and look at differences to your current machine.

    It's not that hard to get up to speed. You just need to get a mental model of the system in your head. svn is quite easy to set up and tortoise svn is a gui for windows that means you don't have to remember all the svn syntax and repository paths. There are other front ends for other platforms if you're not using win. Then you can add it to your resumé.

Leave a comment on “Source Control Mastery”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article