• (disco) in reply to RaceProUK

    Yup. 7.0

    https://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html

    Without multi-catch, your exception handling can get a little ugly. That's why I mentioned it :)

  • (disco) in reply to ChrisH

    That's when "Shelves" become very useful. Make a change, shelve it, and send it to the lead developer/architect for blessing and merging. Over time, assuming I was seeing good code practices, I would likely tell a developer that they didn't need to bring every single thing like this to my attention, so long as they did their proper unit testing.

    A developer who is actually knowledgeable and able to clear up "technical dept" without causing big holes in the system is all too rare a treasure, though, in my experience.

  • (disco) in reply to tenshino

    Not all VCSs have shelvesets though; I know for a fact git doesn't. Then again, with git, branching is pretty cheap; you can easily branch then issue a PR, and it achieves the same goal.

  • (disco) in reply to RaceProUK

    Good point. 99% of my personal experience has been with VSS/TFS over the years. Shelving in TFS is really just a special kind of branch, so making a branch that can be merged and destroyed later would accomplish the same thing.

  • (disco) in reply to tenshino

    You missed my point. It's not about the changes per se alone, it's about the unauthorized effort put into those changes.

  • (disco) in reply to sloosecannon
    sloosecannon:
    7.0
    That's also when they introduced try-with-resources, which is _very_ much like the C# `using` statement. Between them, these two changes can help you shorten complicated code a lot while getting rid of subtle bugs.
  • (disco) in reply to Jaime

    I didn't say "not make a change", I said "not leave your fingerprints".

  • (disco) in reply to Watson

    I didn't miss that. Again, rule # 2 is:

    If you don't make a change and something goes wrong, it's your fault, because you weren't proactive and independent.
    The fact that the change wasn't attributed to you moves you from "bastard that broke it" to "bastard that let it fail through inaction". That's not any better.
  • (disco) in reply to Jaime

    If it goes wrong, in which case it's either "bastard that broke it" to "bastard that let it fail".

  • (disco) in reply to Watson

    Which brings you all the way back to agreeing with the post that you originally posted a rebuttal to.

    Original:

    Jaime:
    The correct behavior (at least the correct game-theoretic behavior) under these rules is to completely ignore management and do what it takes to make things not go wrong.
    To which you relied (somewhat indirectly):
    Watson:
    What that takes is avoiding doing anything that might leave your fingerprints on anything that might go wrong.
  • (disco) in reply to Jaime

    Without the managers catching on.

    You don't suppose what it comes down to is that the developers should be entrusted with development, and the managers should be making it possible for them to do so for the best outcome? It's a novel idea, but I don't think it'll catch on.

  • (disco) in reply to tenshino
    tenshino:
    Shelving in TFS is really just a special kind of branch

    NO.... A ShelveSet is transitory and can be deleted (in fact good practices dictate a process for doing so), a Branch is a permanent (auditable) activity. There is also the Code Review request/response which keeps the review as an auditable activity, but utilizes a transitory shelveset for the code itself (later the review should be associated with the final commit)

  • (disco) in reply to TheCPUWizard

    IMO, shelveset is a handy feature that, when you're the only developer and the test machine is your desktop, when you suddenly need to deploy something out, you can shelf all changes on hand and undo to latest stable state and complie and deploy, then get back the WIP items from shelf and continue.

  • (disco) in reply to RaceProUK

    Hi, git has stashes, which sound very similar, at least in use case, for shelvesets.

  • (disco) in reply to Watson

    Sadly though, for the foreseeable future, will need to be done

    Watson:
    Without the managers catching on
    because of problems like the Law of Disinformation and the ways in which different personality types attempt to satisfy the will to power.
  • (disco) in reply to Gribnit

    Shelvesets are on the server; Stashes are on the client.

    Stashes suck. Git sucks. Gribnit sucks.

  • (disco) in reply to blakeyrat

    Ah okay, yeah, forgot that the mad cult needs the central server thing so hard. So sounds like TFS is beating Subversion pretty roundly these days - bad news for FLOSS!

  • (disco) in reply to Gribnit
    Gribnit:
    So sounds like TFS is beating Subversion pretty roundly these days - bad news for FLOSS!

    I'm guessing this is supposed to be sarcasm?

    But TFS 2013 is really, really great. Both compared to Subversion and Git. It basically has all the features of both of those SCMs.

  • (disco) in reply to sloosecannon

    You're implementing some Iterator<T> and there's no meaningful semantics for #remove(), there the method contract calls for you to throw a subclass of RuntimeException.. also if some fool calls #next() even though not #hasNext(), you throw a RuntimeException there.. lots of use cases if you're following the complete API contracts for things.

    Not even going to think about Swing here. Not that those are even RuntimeException, but (screams) (gibbers)

  • (disco) in reply to blakeyrat
    blakeyrat:
    It basically has all the features of both of those SCMs.

    I moved from SubVersion to TFS and I really miss externals.

  • (disco) in reply to cheong
    cheong:
    IMO, shelveset is a handy feature that, when you're the only developer and the test machine is your desktop, when you suddenly need to deploy something out, you can shelf all changes on hand and undo to latest stable state and complie and deploy, then get back the WIP items from shelf and continue.

    That's only a needed feature when you can't check something out to two places simultaneously. With SVN, when I ran into that situation, I simply checked out another copy to do whatever I needed. It took seconds.

    Also, get a build machine. Building by hand on developer workstations is not a great practice.

  • (disco) in reply to Jaime

    Yeah well I really miss YOUR MOM because there were TOO MANY SAILORS ALREADY IN LINE!

  • (disco) in reply to Jaime
    Jaime:
    That's only a needed feature when you can't check something out to two places simultaneously. With SVN, when I ran into that situation, I simply checked out another copy to do whatever I needed. It took seconds.

    (Psst, you can do that in TFS also.)

  • (disco) in reply to Gribnit

    Being on the server I think a tag will do, just push a tag to server like 2.rc3 for third release candidate of version 10. If it is just for the sake of backing up latest code to the server, it is best be committed to a working branch (not master branch), in git-flow that would be develop if it is the single developer and feature/foo if there are multiple developers.

  • (disco) in reply to foxyshadis
    foxyshadis:
    Every so often I spot someone trying to catch Error in Java. I wonder, what do they think they're going to do with it? (The usual answer is "Log the error and try again" which doesn't help you much when the disk disappears or you encounter a corrupted opcode.)

    I've successfully caught and handled OutOfMemoryException in C# before

  • (disco) in reply to Jaime

    Yes, checking out another local copy is totally the same as storing some work on the server, not checked in, that you can let someone else look at/you can finish later.

  • (disco) in reply to Magus

    I never made the claim you seem to think I did. He wants to build from the unchanged source, and checking out to a second location will accomplish that.

    Besides, checking out a second copy doesn't preclude you from checking in your changes on the first copy, so you very well could save the work on the server and have other people work on it. However, I agree that shelvesets are the right feature for that workflow - the only problem is that we weren't talking about that workflow.

  • (disco) in reply to blakeyrat
    blakeyrat:
    Jaime:
    That's only a needed feature when you can't check something out to two places simultaneously. With SVN, when I ran into that situation, I simply checked out another copy to do whatever I needed. It took seconds.

    (Psst, you can do that in TFS also.)

    ... if you create a second workspace. It's not exactly intuitive, and still limits you to one checkout per workspace.

  • (disco) in reply to Jaime

    kinda hard to devote any brainspace to this topic, really, these are all subcases of branching, and the significance of a branch is arbitrary.. sounds like a bunch of special cases, compared to git.

  • (disco) in reply to Jaloopa
    Jaloopa:
    I've successfully caught and handled OutOfMemoryException in C# before

    It's often difficult to handle OOM, not because it's impossible to recover from a particular failure-to-allocate, but because what do you do next? If a small allocate fails, you're probably screwed because the likelihood that the next small allocate will succeed is minimal.

    Using the stack (C++ style) means that you need much larger stacks. That can create different problems (or at least make them bite on a different schedule).

  • (disco) in reply to dkf

    This was a very special case, where I was using a library to write an Excel file, and OOM basically meant the object was over the 1GB limit. I returned an error message basically saying "save this shit as a CSV" and killed the object. Not particularly pretty, but it worked in this situation

  • (disco) in reply to Jaloopa

    Large-alloc failure is usually recoverable, yes. That's why just setting the computer on fire when allocate fails is a bad move. :)

  • (disco)

    There is a big difference between checking in (leaving a permanent record, of what should ALWAYS be working code) and the purpose of a shelvset (which is transitory, but stored on the server).

    About 6 years ago, I had one client (huge company) a different area was using 100% laptops, but they were no mobile. All locked to the respective desk (and the developers did NOT have the key). One day the office opened and every laptop was gone, and cut cables were all that remained (eventually the cleaning crew was prosecuted, but the laptops were never recovered).

    Since all work had been put into ShelveSets,two things happened. Critical work began by taking whatever was available and RDP into VM's....A run as made to a local store (where they had a corporate account) and all available laptops were picked up [and in service by right after lunch] and the rest were express ordered.

    Would hate to think of what would have happened if the work had all been (only) on the laptops.

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    Since all work had been put into ShelveSets

    :wtf:

    ...Oh, you actually mean all unfinished work. Cool, then. That's a good thing.

  • (disco) in reply to Magus
    Magus:
    ...Oh, you actually mean all unfinished work. Cool, then. That's a good thing

    I was not explicit...yes, work in progress that was not ready to be committed. This [IMHO] should be done every time one takes a break, leaves the office, etc. It eliminates any risk of effort being lost due to a local machine problem, yet does not contaminate the repository.

    Also if for some reason the person does not come back (they get sick), everything right up to the last keystroke is available to those people who are working.

    Additionally, it is a great way to do exchanges (in fact the entire pre-commit code review process is built on them).

  • (disco) in reply to TheCPUWizard

    Not convinced, I am fine with there being branches that are not

    TheCPUWizard:
    ALWAYS ... working code

    as long as the commit notes don't indicate otherwise. Preferably, sure, would want some naming conventions to allow me to be wary of such branches. If the laptops are at risk the devs should push those branches to remote. Hey look, now we have a way to leave an ecosystem where the leader has abandoned ship for hipper markets!

    ShelveSets sounds like a sort of creepy institutional notion, in name - granted, this is not an actual argument against.

  • (disco) in reply to TheCPUWizard

    You do realize you just said in more detail what I said :smile:

    While you are completely correct, I was referring more to how you work with a ShelveSet. Not the dictionary definition differences between the two.

Leave a comment on “No Changes Please”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article