On Wed, Aug 8, 2012 at 4:03 PM, <m.roth@xxxxxxxxx> 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@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
