On Oct 13, 2004, at 11:35 AM, Ben Collins-Sussman wrote:
>
> On Oct 13, 2004, at 12:01 PM, John Peacock wrote:
>
>>
>> I can see the utility for non-mergeable files of forcing the lock to
>> be obtained in advance of the commit (and I've reread the Hijack
>> section again now ;). But if we are to permit locking of files
>> without setting the flag, how is that going to facilitate
>> communicating that the file is locked now?
>>
>
> It's not important that locking communication be "good" in the case of
> mergeable files. Why? Because the file is mergable. Suppose you
> lock foo.c and I'm unaware of this. Then I edit foo.c and my commit
> fails. My work is 'wasted'. I run 'svn up', merge things, then
> eventually commit after you release the lock.
>
> The whole point of the 'svn:needs-lock'/read-only communication system
> is that it prevents people from writing *unmergeable* changes.
Mergeability is not solely about file type.
If I'm checking out a file to change its indentation style, or to
switch all the identifiers from_underscored_words toCamelCase (and my
hands remain upon my wrists...), these changes are likely to be
unmergeable.
Changes to APIs provide a different use case for locking, having not so
much to do with mergeability as change control (well, you can do a
*really* abstract sort of idea of mergeability here...).
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: +1 650.228.2562
c: +1 408.835.8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 02:49:52 2004