Les Mikesell wrote:
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.
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