But it's where I'm working



  • We just released to production. Naturally, the boss did a merge, marked assorted scratch branches dead and sent an email telling everyone which branch was merged into which branch, and that everyone should only be working in the main branch.

    Since we don't usually work in the main branch, I did a svn update, tried a full build, and got an error. I sent out a general who's-working-on-this-and-what-gives email. The response comes back: do a svn update. I responded I already did. They tell me to make sure to do it in the branch in which they are working - one of the ones that was merged into the main and is now defunct.

    I pointed out the boss's instructions that that particular branch is dead, that their changes (as of last night) were merged into main, that they should be working only in the main branch, to please merge their subsequent changes (since the merge) into the main branch, and start working only in the main branch.

    The response: But this is where I'm working!

    head desk - it's only Monday morning!

     



  • @snoofle said:

    But this is where I'm working!
     

    I'm sort of imagining this in this quivering, nearly crying voice, as if they're losing a friend.

    It's so sweet that some people just find their SVN branches sentimental and can't let them go.



  • Alex should be paying you...  It's really amazing that every new post you write is front-page material.

    Also, I'm really sorry you work where you work.  We're using VSS and HPQC, but from the sounds of it, you have many more WTFs at your work than I do.



  • Being the sole developer on my project alleviates me from these type of issues.



  • @C-Octothorpe said:

    Alex should be paying you...  It's really amazing that every new post you write is front-page material.

    Also, I'm really sorry you work where you work.  We're using VSS and HPQC, but from the sounds of it, you have many more WTFs at your work than I do.

    Thanks, but it's the tools in the chairs, not the ones on the disk, that cause the problems. OTOH, as I've said before, I get paid to watch the stupidity, and it IS entertaining 🙂

     



  • @snoofle said:

    We just released to production. Naturally, the boss did a merge, marked assorted scratch branches dead and sent an email telling everyone which branch was merged into which branch, and that everyone should only be working in the main branch.

    This immediately struck me as TRWTF, unless the boss is actually one of the developers, or at least stays familiar with exactly what's going on in branches, etc. Even then, it sounds like it was done without anyone's knowledge, meaning that you could get some really f'd up branches (and apparently did!).



  • @boomzilla said:

    @snoofle said:
    We just released to production. Naturally, the boss did a merge, marked assorted scratch branches dead and sent an email telling everyone which branch was merged into which branch, and that everyone should only be working in the main branch.
    This immediately struck me as TRWTF, unless the boss is actually one of the developers, or at least stays familiar with exactly what's going on in branches, etc. Even then, it sounds like it was done without anyone's knowledge, meaning that you could get some really f'd up branches (and apparently did!).

    With 'those' types of developers, it sounds like the manager is doing what they should be doing but aren't smart enough to do.

    "We're done with that feature.  We didn't merge it into main.  Now we're doing another feature on that branch"



  • @Sutherlands said:

    With 'those' types of developers, it sounds like the manager is doing what they should be doing but aren't smart enough to do.

    He's doing the easy part of the job by doing the physical merge. But that's less than worthless if it breaks stuff.



  • It seems like there's an easy technological fix to this... can't you restrict permissions on the branches people aren't supposed to be working on?



  • @boomzilla said:

    @Sutherlands said:
    With 'those' types of developers, it sounds like the manager is doing what they should be doing but aren't smart enough to do.

    He's doing the easy part of the job by doing the physical merge. But that's less than worthless if it breaks stuff.
    The boss didn't break stuff - he always does a build and runs the tes suite before committing. This one guy kept making changes in a branch, even after the boss told everyone not to work in that branch any more.  One of his checkins was done over 2 days; part before the merge, and part was done after. 

    If the developers would do what they're told, it wouldn't be a problem.



  • @snoofle said:

    @boomzilla said:

    @Sutherlands said:
    With 'those' types of developers, it sounds like the manager is doing what they should be doing but aren't smart enough to do.

    He's doing the easy part of the job by doing the physical merge. But that's less than worthless if it breaks stuff.
    The boss didn't break stuff - he always does a build and runs the tes suite before committing. This one guy kept making changes in a branch, even after the boss told everyone not to work in that branch any more.  One of his checkins was done over 2 days; part before the merge, and part was done after. 

    If the developers would do what they're told, it wouldn't be a problem.

     

     Are you sure he's actually stupid and not being really damn passive aggressive?



  • @DescentJS said:

     Are you sure he's actually stupid and not being really damn passive aggressive?

    There's a distinction?



  • @snoofle said:


    The boss didn't break stuff - he always does a build and runs the tes suite before committing. This one guy kept making changes in a branch, even after the boss told everyone not to work in that branch any more.  One of his checkins was done over 2 days; part before the merge, and part was done after.

    If the developers would do what they're told, it wouldn't be a problem.

    Ah. I think I confused this thread with the other one with all of the java version drama. Though that brings up another WTF, if you deployed his incomplete work. Seems like he should have spoken up at the time. Was the merge a surprise, with everyone notified after the fact?



  • @boomzilla said:

    ...if you deployed his incomplete work. Seems like he should have spoken up at the time. Was the merge a surprise, with everyone notified after the fact?
     

    No, there was the dev-for-this-release-branch, and a few other branches for subsequent releases. This dev was working on something for the NEXT release.

    My boss took the tested branch, made a snapshot for readonly prod-x.y, then another branch for general development giong forward, and mailed out instructions as to which projects were merged where, and who should continue working in which branch - a day in advance. 

    This guy just ignored the instructions. It was a 10 line email, clearly written, with separate instructions for each branch for where it was merged, if it should be used going forward, and where to pick up work starting the next day.



  • You know, we have Friday as the dedicated Error'd day, we should have a Monday weekly update called "This week in Snoofle's Workplace."



  • @Master Chief said:

    we should have a Monday weekly update called "This week in Snoofle's Workplace."

    +1



  • @dohpaz42 said:

    @Master Chief said:
    we should have a Monday weekly update called "This week in Snoofle's Workplace."

    +1

    Someone Make. This. Happen.



  • @snoofle said:

    This guy just ignored the instructions. It was a 10 line email, clearly written, with separate instructions for each branch for where it was merged, if it should be used going forward, and where to pick up work starting the next day.

     

     My rule of thumb is anything after the 2nd sentance isn't read. And anything in the first 2 isn't understood.



  • @cdosrun said:

    My rule of thumb is anything after the 2nd sentance isn't read. And anything in the first 2 isn't understood.

    Oh, and anything in the first 2 isn't understood.



  • @blakeyrat said:

    @cdosrun said:
    My rule of thumb is anything after the 2nd sentance isn't read. And anything in the first 2 isn't understood.
    Oh, and anything in the first 2 isn't understood.
    Clearly you guys work with better coworkers than me.  The ones I work with won't even read anything after the first 2 sentences.



  • @snoofle said:

    @boomzilla said:

    @Sutherlands said:
    With 'those' types of developers, it sounds like the manager is doing what they should be doing but aren't smart enough to do.

    He's doing the easy part of the job by doing the physical merge. But that's less than worthless if it breaks stuff.
    The boss didn't break stuff - he always does a build and runs the tes suite before committing. This one guy kept making changes in a branch, even after the boss told everyone not to work in that branch any more.  One of his checkins was done over 2 days; part before the merge, and part was done after. 

    If the developers would do what they're told, it wouldn't be a problem.

    That's why I mark dead branches with an SVN property and I have a hook script that rejects all commits to dead branches (including commits that would remove the property).



  • @Jaime said:

    That's why I mark dead branches with an SVN property and I have a hook script that rejects all commits to dead branches (including commits that would remove the property).

    It gets easier than that. The branches are now merged and closed and the only reasonable thing to do with them is to delete them. They are still there if you ask subversion for the particular revision if you ever need to look up some changeset and you don't need them for anything else.



  • @snoofle said:

    This guy just ignored the instructions.
    Maybe he didn't ignore the instructions. It might just be possible that he used SVN Switch to make the branch appear in place of the trunk so he wouldn't have to set up his entire IDE again to point to the new location, and later forgot about it. So to him it would look like he's working on the trunk, but all his commits would end up in the original branch.

    Not that I would know anyone who'd be so lazy and stupid to do something like that cough. Hey, why are you looking at me like that! runs and hides in a hole



  • @Anonymouse said:

    Maybe he didn't ignore the instructions. It might just be possible that he used SVN Switch to make the branch appear in place of the trunk so he wouldn't have to set up his entire IDE again to point to the new location, and later forgot about it. So to him it would look like he's working on the trunk, but all his commits would end up in the original branch.

    Because it was too hard to do another switch? I agree with Bulb. The manager should have deleted the branches after the merge.



  • @Zecc said:

    @dohpaz42 said:

    @Master Chief said:
    we should have a Monday weekly update called "This week in Snoofle's Workplace."

    +1

    Someone Make. This. Happen.

    Editors! You hear this? We would love to have Snoofle on the home page periodically.



  • If the branch is dead...why is it accessible. dead bransches should be trimmed off to avoid exactly this type of problem.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.