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. > 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. >> 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. -- Les Mikesell lesmikesell at gmail.com