>-----Original Message-----
>From: Eric [mailto:spamsink@scoot.netis.com]
>Sent: Sunday, January 28, 2007 5:52 PM
>To: users@subversion.tigris.org
>Subject: Conflicts with Copy-Modify-Merge
>For example, suppose Sally makes a change to a function that is
>called by a function that Harry is working on, such that Sally's
>version of the function no longer does what Harry's function expects.
>
>(This could happen whether Harry and Sally are working on the same
>file or different files ... as is pointed out in The Book page 27 -
>"Locking may create a false sense of security"... but for now lets
>restrict ourselves to concurrently revising the same file.)
>
>This is why many developers (including our user, who refuses to use
>CMM no matter what) argue against CMM and in favor of LMU as the only
>way around this problem, despite the other adverse effects LMU has on
>productivity... and despite the warning in The Book about false
>senses of security.
>
>I don't know how to argue against it.
The argument against it, in many shops, is productivity.
<simplication value=on>
If multiple developers on the same project, scattered
across 6 times zones over the planet, are constantly forced
to wait for another user to free a lock so they can work
on a file, productivity is adversely affected. With CMM,
that productivity hit is reduced. It's not eliminated because
the conflict resolution has to be performed, but my experience
is that it's reduced more than enough to offset time on conflict
resolution.
<simplication value=off>
However, the case you describe, one of an "interface" change,
for example Joe adds a call to "foo_bar" while Fred removes "foo_bar"
is quickly caught at the next compile. Better still, interface changes
shouldn't be occuring with design documents and design reviews to let
everyone know an interface change is coming.
In 9 years of being in CMM oriented shops, I can only recall a handful
of
cases where the interface changed and someone else didn't know about
it..
In other words:
a.) Good process (design document, design reviews, change approval
process)
should prevent this case 99% of the time
b.) From SVN point of view, don't worry about this case, because it's a
case that
the process should prevent, not one that the verstion control tool
should catch (IMHO)
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 29 01:14:35 2007