On Wed, Aug 8, 2012 at 4:03 PM, m.roth@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.