Re: Lock-Modify-Unlock vs Copy-Modify-Merge

I'm jumping in here in the middle of the discussion. If my comments happen
to be completely irrelevant regarding the context then just ignore
them. :-)

> -If you have binaries in your repos that are generated by humans then
> IMO Lock-Modify-Unlock is necessary.

The "text vs. binary" distinction isn't really real. It's all binary in one
form or another. (Now, whether the VCS/CMS understands this or not is
another thing altogether.)

> -If an acceptable amount of the files in your repos are merge-able, then
> Copy-Modify-Merge can work for you.

The keyword here is "can".

> Copy-Modify-Merge requires a merge, in the case of text files (code)
> this is trivial.

No, it isn't necessarily trivial. Even when an automatic merge is possible
(i.e. when the modified blocks don't overlap) the result doesn't
necessarily make sense.

E.g. consider two people fixing an infinite loop ('+'=added line):

Patch 1:
p1: while (i<10) {
p1: print(i);
p1: + i++;
p1: doStuff();
p1: }

Patch 2:
p2: while (i<10) {
p2: print(i);
p2: doStuff();
p2: + i++;
p2: }

The result of an automatic merge:
res: while (i<10) {
res: print(i);
res: i++;
res: doStuff();
res: i++;
res: }

In practice Copy-Modify-Merge works more often than not. However, that is
more because of good luck than because the system would be well designed.
The bugs that arise when this luck runs out can be very hard to find.
Optimally we would have file-type specific plugins that know what would
constitute a conflict. Thus they would know what to lock (if using LMU), or
what parts of which merges need review and/or conflict solving (if using
CMM). Until then both LMU and CMM are broken.

Meanwhile, I'd say that LMU is way, way safer when you have a large team and
a large project. In very small teams and/or small projects it might not be
much difference which one they use if all team members know all the code by
heart and review all commits.

- Marcus Sundman

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 11 19:31:18 2004