On Wed, Aug 8, 2012 at 4:33 PM, <m.roth at 5-cent.us> wrote: > >> >> If you want to force your team to wait for your change, fine - and >> sometimes it is even a good idea, but the tool should not make that >> decision for you. > > Yes, I do want to force them to wait for what one person's working on - > it's not like everyone else isn't working on *other* things. And each > should be independent - changing an interface; that is, the parameters a > function (sorry, "messages that a method) is expecting is always a big > deal. Interface/protocol changes aren't particularly tied to a single file or even a single project. If you are going to make changes that affect other things either everyone else needs to know what to expect or you need to be working on a branch that is kept isolated until everything else matches. It doesn't really matter if the file was locked when you make that change or not. >> OK, both QA and operations should agree - QA as to whether a version >> can be released and operations as to when it happens. > > Absolutely, though in a small shop, that tends to be developers and admin. > Not that many places, unfortunately, have one or more folks who are only > q/a. Or worse, the developer may also change hats and be the admin... But developers should be doing new, experimental things and admins should insist on testing before going to production. -- Les Mikesell lesmikesell at gmail.com