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

RE: Pre-commit Hook

From: <ignacio.lopez_at_tektronix.com>
Date: Thu, 31 Jan 2008 16:45:18 -0800

That's true, I'm actually trimming that string to get the file path in
the repo...
You know, it's one of those days...

Thanks....
 

-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2007b_at_ryandesign.com]
Sent: Thursday, January 31, 2008 4:18 PM
To: Lopez, Ignacio
Cc: users_at_subversion.tigris.org
Subject: Re: Pre-commit Hook

On Jan 31, 2008, at 17:15, ignacio.lopez_at_tektronix.com wrote:

>> If you want to prevent users editing the file without getting the
>> lock,
>> then set the svn:needs-lock property. As well as enforcing what your
>> trying to do with a script, it also makes these files read-only in
>> their working copy until they obtain the lock.
>
>
> Thanks all,
>
> I tried both procedures and finally got them working, the pre-commit
> hook was pretty hard I have to say and it works great with existing
> files, it requires the user to lock the files before commiting any
> changes... BUT
> I just tried to add new files and it wouldn't let me because my "new"
> files are not locked =|... Well they are not under revision control
> so I
> can not lock them. I also tried creating folders and deleting files
> with
> the same results...
>
> Is there a way to distinguish a 'delete file/folder', 'add',
> 'import' or
> 'mkdir' transaction from a 'file changed' transaction?

Everything you need should be in the output of "svnlook changed".
Added items have an "A" at the beginning of the line, so you can
exclude those. Directories have a slash at the end of the line, so
you can exclude those.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-01 02:22:37 CET

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

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