I am gaining a sort of an understanding and appreciation of the
Copy-Modify-Merge (CMM) method of version control ... having come
from the Lock-Modify-Unlock (LMU) environment, it's not easy, but I'm
getting there. :-)
I am already convinced that CMM is "better" than LMU in terms of team
productivity, but I'm still a bit skeptical about some of the issues
regarding conflicts.
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.
I don't know how to argue against it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 29 00:52:29 2007