[EMAIL PROTECTED] on 2000.02.18 10:39:50
>>--- Forwarded mail from [EMAIL PROTECTED]
>
>>On Friday, February 18, Frode Nilsen wrote:
>
>>> This whole discussion started because we have lots of files in our source
>>> tree that are non merge able -> we have to assure serialized work on these
>>> files. Hard locking is the only solution that guarantees that.
>
>>I disagree, it is *one* solution that could guarantee that. There are others.
>
>The ones you've mentioned in the past rely on out-of-band communications.
>Can you suggest one that can be enforced by the VC system?
The "cvs edit -c" patch supports in-band communication. I keep bringing this
up, but noone has yet responded saying why they can't use it (other than maybe
they're too lazy to apply/maintain a patch).
>...which cannot be resolved without a LOT of pain... How nice it would have
>been to have been discouraged from making changes when a conflict could
>have been predicted and avoided.
Again, "cvs edit -c". The suggested use of "cvs edit -c" is to also have
communication, but nothing forces that. A site can use "cvs edit -c" just as it
would use locks (except that users can always do "cvs edit -f" to override the
locks).
>Fair enough. I believe there's a user model for locks in CVS that will meet
>your acceptance criteria.
Again, what's lacking in "cvs edit -c"? I'm also working on a "cvs ci -c" patch
that'll check if the files to be commited have proper "edits" (ie locks) on
them. I think, though, that "cvs edit -c" is sufficient for most (if not all)
locking needs.
Noel
