Re: auto props / locking

[Nico Kadel-Garcia <nk...@comcast.net>]

rob anderson wrote:

>> This really looks like a post-commit step.
>
> How can a post-commit script help here ?
>
> Thanks
>    Rob

Each repository can have its own post-commit script. That script can look 
for certain types of files and automatically set their "needs-lock" 
properties, with associated messages.

Alternatively, a pre-commit script could detect certain file types and 
refuse to accept changes to them unless they have been set to "needs-lock" 
or actually locked, to force users to lock them. 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: auto props / locking

[Greg Thomas <th...@omc.bt.co.uk>]

On Mon, 1 May 2006 23:42:39 +0200, Ryan Schmidt
<su...@ryandesign.com> wrote:

>
>On May 1, 2006, at 04:56, Nico Kadel-Garcia wrote:
>
>> Each repository can have its own post-commit script. That script  
>> can look for certain types of files and automatically set their  
>> "needs-lock" properties, with associated messages.
>
>It cannot. A hook must not modify the transaction which is being  
>committed. 

Modifying the repository with a *post* commit hook, which the post
suggests, is just fine. It's no different to a person manually
committing a change to their own wc, modifying the repository, after
I've committed something.

Greg
-- 
This post represents the views of the author and does
not necessarily accurately represent the views of BT.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: auto props / locking

[Ryan Schmidt <su...@ryandesign.com>]

On May 1, 2006, at 04:56, Nico Kadel-Garcia wrote:

> Each repository can have its own post-commit script. That script  
> can look for certain types of files and automatically set their  
> "needs-lock" properties, with associated messages.

It cannot. A hook must not modify the transaction which is being  
committed. If it does, the client's working copy will be corrupt,  
because the working copy will think it is up to date, but in fact is  
not (because the hook has changed the transaction without information  
the client, because there is no mechanism by which the client could  
be informed of this). The best the hook can safely do is maintain its  
own working copy of the relevant part of the repository, modify the  
properties of the relevant files there if necessary, and commit a  
second revision. Maintaining this working copy is messy, and the user  
would have to do an "svn update" right after committing in order to  
get any potential property modifications the post-commit hook made.  
It's rather ugly.


> Alternatively, a pre-commit script could detect certain file types  
> and refuse to accept changes to them unless they have been set to  
> "needs-lock" or actually locked, to force users to lock them.

Yes, that's the more Subversion way to handle it.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org