On Tuesday 12 October 2004 20:54, Konrad Rosenbaum wrote:
> On Monday 11 October 2004 19:33, Marcus Sundman wrote:
> > 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.
>
> Just consider this: if CMM fails regularly for you, your workflow is
> broken.
It doesn't, but the problem is that when it fails it does so quietly. The
same problem also exists with most LMU implementations (unless you lock the
entire module), just not as often.
> > 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.
>
> The mathematically/theoretically safest way of doing things often turns
> into the practically worst case.
Yes. The safest way would be to lock the entire module, and that would be
very bad indeed. The best thing would be that the tools know what to lock
and when to unlock, while at the same time also provide manual overrides.
> In a well organized project each person has specific responsibilities and
> will work 95% if his/her time on these specifics. This is the area, where
> CMM works waayyy better than LMU, because people don't lock each other
> out of their work.
There is no problem with using LMU in that scenario as long as the locks are
limited to the relevant scope and there is a manual override.
E.g., let's say I lock file X and while I work on the file you want to fix a
bug in it. When you try to lock X it fails and tells you that I have a lock
on it. If you don't know what I'm working on (I might even have fixed the
bug already and about to check in the fixes) you wait until I release the
lock, but if you know that I'm working on something not related to the bug
you want to fix then you can override the lock and then we both have a lock
on the file.
Now, here is room for some (nice?) additional features:
- Not all people can override all locks of all people. E.g. there could be
some maintenance admin who could lock some parts, or even everything,
without anyone else being able to override it.
- Let's say you have locked a file and I override it, make some changes and
commit & unlock. When you try to commit you see that I've done some changes
that screwed it up for you. Since you had the lock first you can now undo
my changes and commit yours. The next time when I update I get a warning
that my previously commited changes now produces a merge conflict which I
need to resolve if I want to keep those changes.
- Lock only parts of files. (E.g., only a particular function.) Tools that
don't support this would see the whole file as locked. Tools that support
it could automatically lock and unlock stuff when you edit files.
> On the other side of the spectrum: large projects like KDE(*) work with
> CMM
...and we all know how bugfree KDE is.. ;-)
Coincidentally my KMail just cleared your message for no reason at all. :-/
(No flamewar, please.)
- Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 13 19:20:16 2004