Les Mikesell wrote: > On Wed, Aug 8, 2012 at 4:03 PM, <m.roth at 5-cent.us> wrote: >> >> >>> Errr, what? No sensible VCS forces you to wait for someone else to >>> finish their portion of the work. >> >> You're wrong. I've worked in small and large teams, and *ALWAYS* we >> checked out with locks. If two people need to work on one file, then >> either they need to work together on one copy, and check it back in >> together, or the file needs to be split into more than one, so that one >> person can work on each. > > 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. > >> I have vehemently been against the fad of the last half a dozen or so >> years, with multiple people checking out and working on the same file. >> I've seen hours or days of a developer's work wiped out, when a team >> lead hacked some quick fixes, then merged the file back in. > > You can't do that without knowing it. If the user ignores the other > changes in a conflict or doesn't resolve them correctly, blame the > user just like you would if he typed that in as part of his own > changes. Yes... and one of the main points of a correctly configured VCS is explicitly to prevent one person from screwing up others' work. > >>> That part is true enough, although it is not so much who does the >>> work, it is following the procedure. If you are going to be picky >>> about who does what, there should really be a QA person involved that >>> makes the actual decision about what version should be running in >>> production in between the developers making changes and the operators >>> doing the installs. >> >> I haven't had q/a move to prod; that was always the prod admin's job, >> after q/a was done, and had promoted it to prod. > > 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. mark