[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking by default

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: Sat, 7 Feb 2009 20:40:04 -0600

Luca: I think you may want to read the 'locking' section of the
svnbook. It might have cleared up a lot of your (incorrect) ideas
about how locking works. ;-)

Good luck!

2009/2/7 Luca Arzeni <l.arzeni_at_iname.com>:
> Thanks Ben,
> the precommit-hook behaviour is what I'm needing, but, since It's needed for
> every file I was thinking that a change to the core was the proper solution.
> Anyway you clarified the point. I was thinking that attaching a property to
> every file would have caused more job to the server, but if this is not
> true, I will go the way you suggested.
> Thanks again, larzeni
>
> ----- Original Message -----
> From: "Ben Collins-Sussman"
> To: larzeni
> Cc: "Branko Čibej" , dev_at_subversion.tigris.org
> Subject: Re: Locking by default
> Date: Wed, 4 Feb 2009 07:46:35 -0600
>
>
> A correction: the svn:needs-lock property is *not* required for the
> lock-modify-unlock model. Any file can be locked, anytime, whether
> the property is present or not.
>
> The svn:needs-lock property is simply a "reminder" that a file ought
> to be locked before edits begin, so as to prevent someone from wasting
> time working on unmergeable changes. The property causes a file to be
> read-only in the working-copy until 'svn lock' is run on it, at which
> point (1) user discovers if the file is already locked or not, and (2)
> the file becomes read-write. But the use of this property is
> *completely optional*. There is no "server side check" for the
> svn:needs-lock property -- it is a property wholly interpreted by the
> svn client, for making files read-only. The server pays no attention
> to the property.
>
> If you plan to use lock-modify-unlock on almost every single file,
> there's a much simpler strategy which doesn't involve modifying svn's
> core code:
>
> * In each user's ~/.subversion/config file, use the "auto props"
> feature to automatically attach the svn:needs-lock property whenever a
> file is 'svn add'ed to version control. This keeps users from
> forgetting to add the property when they add new files. It all files
> have the property attached, it means checkouts will result in working
> copies that are mostly read-only. And in theory, this should remind
> your users to 'svn lock' files before they edit them.
>
> * On the server side, you can write a pre-commit hook script which
> rejects any incoming commit on files that are not already locked.
> This is a bit extreme, but it may enforce the behavior you want ("you
> must lock every file before changing it").
>
>
>
> On Tue, Feb 3, 2009 at 4:47 PM, larzeni wrote:
>> "Branko Čibej" wrote:
>>> What kind of heavy burden would that be, exactly?
>>
>> In our understanding, on each file that we will submit, snv will need to
>> execute a query to look for prop svn:needs-lock.
>> Also, it will need to manage an attribute more for every file in the
>> repository.
>>
>> Regards, larzeni
>>
>>
>>
>> ----- Original Message -----
>> From: "Branko Čibej"
>> To: larzeni
>> Cc: dev_at_subversion.tigris.org
>> Subject: Re: Locking by default
>> Date: Tue, 03 Feb 2009 16:44:23 +0100
>>
>>
>> larzeni wrote:
>>> |Since we are going to use almost on all files |the lock/modify/unlock
>>> model, we fear that we will impose a heavy burden on the server.
>>
>> What kind of heavy burden would that be, exactly?
>>
>> -- Brane
>>
>> --
>> Be Yourself @ mail.com!
>> Choose From 200+ Email Addresses
>> Get a Free Account at www.mail.com!
>
> --
> Be Yourself @ mail.com!
> Choose From 200+ Email Addresses
> Get a Free Account at www.mail.com!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1121868
Received on 2009-02-08 03:41:17 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.