Re: Locking by default

 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