Hi Eric
I'll try to have a go at answering your question with my own knowledge.
I can remember days when I used to code within an LMU environment, and I
especially loved the times when both the individual maintaining a module
and our team leader were unavailable. Those were very productive days
indeed.
Your problem seems like a real conundrum for many developers. This
conundrum is resolved somewhat in conducting of a build when code is
committed, and a nightly build.
In the case of function interface differences, the build will fail, and,
if this build is associated with a pre-commit hook, you can use build's
failure to prevent a commit from taking place. In the case of a
behavioural change that might violate some functional or performance
parameter, a nightly build would probably pick this up. Even though code
was committed, it can be backed out.
Your situation would be relatively rare, the mistakes would be obvious,
and I don't believe an LMU environment would necessarily prevent them
from occurring anyway.
I hope that helps you. :)
Owen.
-----Original Message-----
From: Eric [mailto:spamsink@scoot.netis.com]
Sent: Monday, January 29, 2007 10:52 AM
To: users@subversion.tigris.org
Subject: Conflicts with Copy-Modify-Merge
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
---------------------------------------------------------------------
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:42:04 2007