[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Conflicts with Copy-Modify-Merge

From: L. Wayne Johnson <wayne_at_zk.com>
Date: 2007-01-29 19:27:23 CET

>> Say user A and user B (well, OK, "Harry" and "Sally" ... might as
>> well stick to the conventions in The Book) both want to work on the
>> same source file at the same time.
>> If Harry makes a change to a line of code and Sally makes an
>> incompatible change to the same line of code, I can see how
>> Subversion will flag that as a "conflict" and make Harry and Sally fix
>> it.
>> Beyond that, I have no idea how Subversion can detect conflicts in a
>> way that will save Harry and Sally from the situation where conflicts
>> just go silently into the repository with no hint to anyone that they
>> exist.
>> 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.

The same problem exists whether you use locking or not. One way or another
one either Sally or Harry is going to have to merge there changes. Locking
files does communicate one developer's intention of modifying the file.
However, let's suppose the Harry is faster at locking the file but Sally is
actually faster at adding her changes and testing them. This leaves Sally
with 2 options:
1.) Put her test code aside, wait for Harry to complete and test his
changes, merge her code with Harry's, retest it and then check it in.

2.) Break Harry's lock and make Harry merge.

The difference without locking is that Harry (or Sally) might be surprised
by the unexpected changes by the other. And, Harry doesn't have the moral
high ground (lock ownership) when Sally finishes first ...

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 29 19:28:06 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.