You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by ch...@kpn.com on 2008/07/16 12:27:55 UTC
any "must-have" hooks to implement on svn server?
Hi all,
I've been reading up on SVN for the last month and after trying CEE and
SFEE (on demand), I decided to start simple and see where it'll lead us.
I now have a svn 1.5 server up and running well, imported 100 or so old
RCS files, and I'm slowly letting my co-workers use it. I plan to tweak
and polish the server here and there while they work. :)
My question:
- which hooks or scripts are must-have on a day to day basis?
I don't mean pre-commit or pre-lock in general, but who knows for a fact
that using a pre-commit hook to test for X, Y and Z in a multi-user dev
group working on several project is a good idea?
I've seen the hook templates, read a few posts on the forum and various
blogs, but while I agree that they contain potentially useful stuff, I
have yet to see a collection of must-have tools, contribs or hooks for a
subversion server. :)
And... if they are "must-have" or commonly implemented, why are they not
included with the svn server by default?
Sincerely,
Chris.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: any "must-have" hooks to implement on svn server?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jul 20, 2008, at 00:42, Waynn Lue wrote:
>>> There are files that should exist in each developer's environment
>>> called dbsecret.php.inc and reality.php.inc, and I want to make
>>> sure no one tries to check in a file named that. This was my
>>> attempt in pre-commit to fix it, but it doesn't seem to work.
>>> Any ideas?
>>>
>>> $SVNLOOK changed -t "$TXN" "$REPOS" | \
>>> grep -E "dbsecret.php.inc|reality.php.inc" > /dev/null || exit 1
>>
>> You're telling the script to exit if the filename is NOT
>> dbsecret.php.inc or reality.php.inc, when actually you want the
>> script to exit if the filename IS dbsecret.php.inc or
>> reality.php.inc. Change "||" to "&&" to fix this.
>>
>> But you should also escape the special characters in the filenames
>> (in this case the periods) and anchor the search to the beginning
>> and end of the string (so you don't match files whose names merely
>> CONTAIN dbsecret.php.inc or reality.php.inc). And you will
>> probably want to print message to the user explaining what went
>> wrong.
>>
>> $SVNLOOK changed -t "$TXN" "$REPOS" | \
>> grep -E "^....(.*/)?(dbsecret\.php\.inc|reality\.php\.inc)
>> $" > /dev/null
>> if [ $? -eq 0 ]; then
>> echo "You con't commit files named dbsecret.php.inc or
>> reality.php.inc" 1>&2
>> exit 1
>> fi
>> exit 0
>
> Excellent, thanks so much for the help, this worked like a charm.
> Two quick questions so I understand what's going on, why the "...."
> at the beginning of the regex? Shouldn't (.*/) be enough? Second,
> what's $? map to? Searching "$? bash" didn't help.
"^...." matches 4 characters at the beginning of the string. The
format of "svnlook changed" is such that the first character
indicates whether the file or directory contents are Added, Modified
or Deleted; the second character indicates whether the properties are
being Modified; and the third and fourth characters are I believe
currently always blank. In any case I want to skip over those and get
to the path. "(.*/)?" matches, optionally, any path component. This
is because e.g. I want to find the string "dbsecret.php.inc" either
at the beginning of the path (meaning the file is at the root of the
repository) or after a "/" in the path (meaning it's in some
directory). I do not want to match a file named e.g.
"notdbsecret.php.inc". The "$" at the end of the regexp anchors it to
the end of the string, because I do not want to match a file named
e.g. "dbsecret.php.inc.txt". If you do want to match any file whose
name merely BEGINS with "dbsecret.php.inc" then remove the "$" at the
end of the regexp.
"$?" is the exit code of the previous command. So I'm checking if the
exit code of the grep command is 0 (meaning grep encountered no error
and did match the string).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: any "must-have" hooks to implement on svn server?
Posted by Waynn Lue <wa...@gmail.com>.
>
> There are files that should exist in each developer's environment called
>> dbsecret.php.inc and reality.php.inc, and I want to make sure no one tries
>> to check in a file named that. This was my attempt in pre-commit to fix it,
>> but it doesn't seem to work. Any ideas?
>>
>> $SVNLOOK changed -t "$TXN" "$REPOS" | \
>> grep -E "dbsecret.php.inc|reality.php.inc" > /dev/null || exit 1
>>
>
>
> You're telling the script to exit if the filename is NOT dbsecret.php.inc
> or reality.php.inc, when actually you want the script to exit if the
> filename IS dbsecret.php.inc or reality.php.inc. Change "||" to "&&" to fix
> this.
>
> But you should also escape the special characters in the filenames (in this
> case the periods) and anchor the search to the beginning and end of the
> string (so you don't match files whose names merely CONTAIN dbsecret.php.inc
> or reality.php.inc). And you will probably want to print message to the user
> explaining what went wrong.
>
> $SVNLOOK changed -t "$TXN" "$REPOS" | \
> grep -E "^....(.*/)?(dbsecret\.php\.inc|reality\.php\.inc)$" >
> /dev/null
> if [ $? -eq 0 ]; then
> echo "You con't commit files named dbsecret.php.inc or
> reality.php.inc" 1>&2
> exit 1
> fi
> exit 0
>
Excellent, thanks so much for the help, this worked like a charm. Two quick
questions so I understand what's going on, why the "...." at the beginning
of the regex? Shouldn't (.*/) be enough? Second, what's $? map to?
Searching "$? bash" didn't help.
Thanks again,
Waynn
Re: any "must-have" hooks to implement on svn server?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jul 19, 2008, at 09:22, Waynn Lue wrote:
> There are files that should exist in each developer's environment
> called dbsecret.php.inc and reality.php.inc, and I want to make
> sure no one tries to check in a file named that. This was my
> attempt in pre-commit to fix it, but it doesn't seem to work. Any
> ideas?
>
> $SVNLOOK changed -t "$TXN" "$REPOS" | \
> grep -E "dbsecret.php.inc|reality.php.inc" > /dev/null || exit 1
You're telling the script to exit if the filename is NOT
dbsecret.php.inc or reality.php.inc, when actually you want the
script to exit if the filename IS dbsecret.php.inc or
reality.php.inc. Change "||" to "&&" to fix this.
But you should also escape the special characters in the filenames
(in this case the periods) and anchor the search to the beginning and
end of the string (so you don't match files whose names merely
CONTAIN dbsecret.php.inc or reality.php.inc). And you will probably
want to print message to the user explaining what went wrong.
$SVNLOOK changed -t "$TXN" "$REPOS" | \
grep -E "^....(.*/)?(dbsecret\.php\.inc|reality\.php\.inc)$" > /dev/
null
if [ $? -eq 0 ]; then
echo "You con't commit files named dbsecret.php.inc or
reality.php.inc" 1>&2
exit 1
fi
exit 0
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: any "must-have" hooks to implement on svn server?
Posted by Waynn Lue <wa...@gmail.com>.
>
>
> * pre-commit: prevent committing a file whose name would be problematic on
> Windows (don't know a script that does this):
> * these filenames are illegal on Windows: CON, PRN, AUX, NUL, COM1 thru
> COM9, LPT1 thru LPT9, and any of these with any extension
> * a filename may not end with a period or space
> * a filename may not contain the characters < > : " / \ |
>
I'm actually looking for a more specific instance of this. There are files
that should exist in each developer's environment called dbsecret.php.inc
and reality.php.inc, and I want to make sure no one tries to check in a file
named that. This was my attempt in pre-commit to fix it, but it doesn't
seem to work. Any ideas?
$SVNLOOK changed -t "$TXN" "$REPOS" | \
grep -E "dbsecret.php.inc|reality.php.inc" > /dev/null || exit 1
Waynn
Re: any "must-have" hooks to implement on svn server?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jul 16, 2008, at 07:27, christian.peper@kpn.com wrote:
> I've been reading up on SVN for the last month and after trying CEE
> and
> SFEE (on demand), I decided to start simple and see where it'll
> lead us.
> I now have a svn 1.5 server up and running well, imported 100 or so
> old
> RCS files, and I'm slowly letting my co-workers use it. I plan to
> tweak
> and polish the server here and there while they work. :)
>
> My question:
> - which hooks or scripts are must-have on a day to day basis?
>
> I don't mean pre-commit or pre-lock in general, but who knows for a
> fact
> that using a pre-commit hook to test for X, Y and Z in a multi-user
> dev
> group working on several project is a good idea?
>
> I've seen the hook templates, read a few posts on the forum and
> various
> blogs, but while I agree that they contain potentially useful stuff, I
> have yet to see a collection of must-have tools, contribs or hooks
> for a
> subversion server. :)
Must-haves:
* post-commit: normalize commit messages so they always end with
exactly one newline (http://svn.collab.net/repos/svn/trunk/tools/hook-
scripts/log-police.py)
* post-commit: you probably want to email change notifications to a
list or somewhere (http://svn.collab.net/repos/svn/trunk/tools/hook-
scripts/mailer/)
* pre-commit: prevent committing a file whose name differs from
another in that directory only in case, since such a commit makes it
impossible to check the directory out on a case-insensitive
filesystem like the ones used by default on Windows and Mac OS X
(http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/case-
insensitive.py)
* pre-commit: prevent committing a file whose name would be
problematic on Windows (don't know a script that does this):
* these filenames are illegal on Windows: CON, PRN, AUX, NUL, COM1
thru COM9, LPT1 thru LPT9, and any of these with any extension
* a filename may not end with a period or space
* a filename may not contain the characters < > : " / \ |
* pre-commit: I just found this script which prevents problems with
svn:keywords on binary files which sounds like a good idea (http://
svn.collab.net/repos/svn/trunk/contrib/hook-scripts/svn-keyword-
check.pl)
* Apache module: if you're serving your repository(ies) with Apache
you might want to prevent people from checking out whole swathes of
your repository which would put unnecessary load on your server and
waste bandwidth and your users' disk space probably (http://
svn.collab.net/repos/svn/trunk/contrib/server-side/mod_dontdothat/)
> And... if they are "must-have" or commonly implemented, why are
> they not
> included with the svn server by default?
Many of these are included in the Subversion source distribution. As
to why Subversion does not have these behaviors built-in, not all
users need to care about Windows or case-insensitive filesystems or
these other situations. Personally it seems to me that these should
be added to Subversion proper. But they haven't been.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: any "must-have" hooks to implement on svn server?
Posted by ch...@kpn.com.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2008c@ryandesign.com]
> Sent: Thursday, July 24, 2008 11:18 PM
> Subject: Re: any "must-have" hooks to implement on svn server?
>
[schnipp]
> > Why not write a pre-commit hook that checks if the file
> type is some
> > text file, aka not binary, and set the eol-style to native
> and be done
> > with it? No bothering users with client=side config that
> they forget
> > to update, save, maintain or even apply at all. You also
> don't need to
> > maintain the hooks when new file types get added that you haven't
> > supported yet.
>
> You cannot always guess whether a file should be treated as
> text or binary. For example, Subversion usually guesses
> (incorrectly) that a PDF file is a text file. There may be
> other types of files which seem to be text but where the line
> ending style is relevant to the program that reads them.
>
> Also, you cannot change a transaction in progress in a hook script.
> The only thing you could do is commit a second revision right
> after to add a forgotten svn:eol-style property. This has the
> effect that the developer's working copy is immediately out
> of date after committing a new file addition. This would
> rightly be confusing to the developer. It also adds
> complexity to the hook script as it now has to manage its
> very own working copy. And what if that working copy breaks?
> Then the hook script stops working, possibly blocking all
> commits until it's fixed.
>
> It is better to do it the normal Subversion way: educate the
> developer how to set up auto-props correctly, and install a
> pre- commit hook script to enforce it.
thanks, Ryan! I'm so glad I asked the questions. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: any "must-have" hooks to implement on svn server?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jul 24, 2008, at 08:38, christian.peper@kpn.com wrote:
> David Weintraub wrote:
>>
>
>> Another hook I have is one that verifies that particular
>> subversion properties are attached to your files before being
>> committed. For example, we want all files that end in *.sh,
>> *.pl, and *.makefile to have the property "svn:eol-style" =
>> "LF". Users can configure auto-properties, but this
>> guarantees that the property is on the file before being
>> committed.
>
> what I don't understand is why, if svn:eol-style=native always chooses
> the correct format for the destination system, why the other specific
> options even exist. Except for backward compatibility of course.
"Correct" is in the eye of the beholder.
For example in the web site development shop where I worked,
programmers used Windows workstations but the working copies were
stored on a Samba share exported from a Linux server where Apache
ran. This was so that developers could test changes in their working
copies before committing them, using the web server on the Linux
machine, without having to install and maintain a web server and
related software on their development machines. The working copy
might be checked out or updated either using TortoiseSVN on Windows
or using the svn command line client on Linux. We used "svn:eol-style
LF" on all files and configured developers' Windows text editors to
understand LF line endings. Using CRLF line endings would not have
worked, because then the tools on the Linux machine would not have
known what to do with these files.
> Why not write a pre-commit hook that checks if the file type is some
> text file, aka not binary, and set the eol-style to native and be done
> with it? No bothering users with client=side config that they
> forget to
> update, save, maintain or even apply at all. You also don't need to
> maintain the hooks when new file types get added that you haven't
> supported yet.
You cannot always guess whether a file should be treated as text or
binary. For example, Subversion usually guesses (incorrectly) that a
PDF file is a text file. There may be other types of files which seem
to be text but where the line ending style is relevant to the program
that reads them.
Also, you cannot change a transaction in progress in a hook script.
The only thing you could do is commit a second revision right after
to add a forgotten svn:eol-style property. This has the effect that
the developer's working copy is immediately out of date after
committing a new file addition. This would rightly be confusing to
the developer. It also adds complexity to the hook script as it now
has to manage its very own working copy. And what if that working
copy breaks? Then the hook script stops working, possibly blocking
all commits until it's fixed.
It is better to do it the normal Subversion way: educate the
developer how to set up auto-props correctly, and install a pre-
commit hook script to enforce it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Svn info from TortoiseSVN?
Posted by Steve Constable <st...@hotmail.com>.
Yep, found it-thank you.
Now the problem with that is that I can't select the data.
Maybe I can write a little script to do this instead.
-----Original Message-----
From: Andy Levy [mailto:andy.levy@gmail.com]
Sent: Thursday, July 24, 2008 3:21 PM
To: Steve Constable
Cc: users@subversion.tigris.org
Subject: Re: Svn info from TortoiseSVN?
On Thu, Jul 24, 2008 at 17:17, Steve Constable <st...@hotmail.com>
wrote:
> Not sure this is the right place to ask but there's likely a bunch of
> Tortoise users here.
> Can Tortoise provide me with a files 'svn info'? When I right click on
> a file I don't see that as a menu item. Show Log and a bunch of other
> commands are available, but I've had to use the command line to get svn
info.
Check the file's Properties. You'll see a new tab named Subversion.
> Also, has anyone ever heard of a way to integrate the 'svn info'
> automatically into an email when I attach a SVN controlled file? I'd
> like the file(s) info added like a signature to any attachments so I
> can track exactly what version I've send to someone.
This would depend upon email client support for scripting, among other
things.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Svn info from TortoiseSVN?
Posted by Andy Levy <an...@gmail.com>.
On Thu, Jul 24, 2008 at 17:17, Steve Constable
<st...@hotmail.com> wrote:
> Not sure this is the right place to ask but there's likely a bunch of
> Tortoise users here.
> Can Tortoise provide me with a files 'svn info'? When I right click on a
> file I don't see that as a menu item. Show Log and a bunch of other commands
> are available, but I've had to use the command line to get svn info.
Check the file's Properties. You'll see a new tab named Subversion.
> Also, has anyone ever heard of a way to integrate the 'svn info'
> automatically into an email when I attach a SVN controlled file? I'd like
> the file(s) info added like a signature to any attachments so I can track
> exactly what version I've send to someone.
This would depend upon email client support for scripting, among other things.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Svn info from TortoiseSVN?
Posted by Steve Constable <st...@hotmail.com>.
Not sure this is the right place to ask but there's likely a bunch of
Tortoise users here.
Can Tortoise provide me with a files 'svn info'? When I right click on a
file I don't see that as a menu item. Show Log and a bunch of other commands
are available, but I've had to use the command line to get svn info.
Also, has anyone ever heard of a way to integrate the 'svn info'
automatically into an email when I attach a SVN controlled file? I'd like
the file(s) info added like a signature to any attachments so I can track
exactly what version I've send to someone.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: any "must-have" hooks to implement on svn server?
Posted by Andy Levy <an...@gmail.com>.
On Thu, Jul 24, 2008 at 09:38, <ch...@kpn.com> wrote:
> Thanks everyone so far for your great answers! It really helps. :)
>
>> -----Original Message-----
>> From: David Weintraub [mailto:qazwart@gmail.com]
>> Sent: Wednesday, July 16, 2008 9:58 PM
>> Subject: Re: any "must-have" hooks to implement on svn server?
>> [...]
>> Another hook I have is one that verifies that particular
>> subversion properties are attached to your files before being
>> committed. For example, we want all files that end in *.sh,
>> *.pl, and *.makefile to have the property "svn:eol-style" =
>> "LF". Users can configure auto-properties, but this
>> guarantees that the property is on the file before being
>> committed.
>
> David,
>
> what I don't understand is why, if svn:eol-style=native always chooses
> the correct format for the destination system, why the other specific
> options even exist. Except for backward compatibility of course.
> Why not write a pre-commit hook that checks if the file type is some
> text file, aka not binary, and set the eol-style to native and be done
> with it?
Because some programs may require a specific EOL marker, ignoring the
platform they're running on.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: any "must-have" hooks to implement on svn server?
Posted by ch...@kpn.com.
Thanks everyone so far for your great answers! It really helps. :)
> -----Original Message-----
> From: David Weintraub [mailto:qazwart@gmail.com]
> Sent: Wednesday, July 16, 2008 9:58 PM
> Subject: Re: any "must-have" hooks to implement on svn server?
> [...]
> Another hook I have is one that verifies that particular
> subversion properties are attached to your files before being
> committed. For example, we want all files that end in *.sh,
> *.pl, and *.makefile to have the property "svn:eol-style" =
> "LF". Users can configure auto-properties, but this
> guarantees that the property is on the file before being
> committed.
David,
what I don't understand is why, if svn:eol-style=native always chooses
the correct format for the destination system, why the other specific
options even exist. Except for backward compatibility of course.
Why not write a pre-commit hook that checks if the file type is some
text file, aka not binary, and set the eol-style to native and be done
with it? No bothering users with client=side config that they forget to
update, save, maintain or even apply at all. You also don't need to
maintain the hooks when new file types get added that you haven't
supported yet.
Chris.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: any "must-have" hooks to implement on svn server?
Posted by David Weintraub <qa...@gmail.com>.
Must have? I can't say anything is must have. A security hook is the
most requested, but I can imagine many small sites don't really have a
need for one.
The most popular hooks are:
* Some sort of permissioning hook. Does this particular user have
permission to make changes in that file?
* Some sort of file watching hook: Tell this user whenever a
particular file gets changed.
I wrote my own hook for the first one because I didn't like the
original hook that came with Subversion. However, the new python
version of the hook is much better and comes with Subversion. For
example, it has an "add-only" property where users can create a new
folder or file via a "svn cp", but not edit an existing folder or
file. This prevents tags from being modified.
I am still working on how to do the second hook. I want users to be
able to specify the files they want to watch themselves without having
to personally tell me. That means making something that can be stored
on the server where the hook script can find it, yet allows all users
to update it.
Another hook I have is one that verifies that particular subversion
properties are attached to your files before being committed. For
example, we want all files that end in *.sh, *.pl, and *.makefile to
have the property "svn:eol-style" = "LF". Users can configure
auto-properties, but this guarantees that the property is on the file
before being committed. Another one I have makes sure that the file
name is legal on Windows systems. In Windows, you cannot have files
with certain names (like "aux"). Plus, I want to avoid files with
backslashes and other special characters that cause problems with
Subversion (like the "@" sign), cause problems with Windows (a whole
slew of characters) or Unix problems.
--
David Weintraub
qazwart@gmail.com
On Wed, Jul 16, 2008 at 8:27 AM, <ch...@kpn.com> wrote:
> Hi all,
>
> I've been reading up on SVN for the last month and after trying CEE and
> SFEE (on demand), I decided to start simple and see where it'll lead us.
> I now have a svn 1.5 server up and running well, imported 100 or so old
> RCS files, and I'm slowly letting my co-workers use it. I plan to tweak
> and polish the server here and there while they work. :)
>
> My question:
> - which hooks or scripts are must-have on a day to day basis?
>
> I don't mean pre-commit or pre-lock in general, but who knows for a fact
> that using a pre-commit hook to test for X, Y and Z in a multi-user dev
> group working on several project is a good idea?
>
> I've seen the hook templates, read a few posts on the forum and various
> blogs, but while I agree that they contain potentially useful stuff, I
> have yet to see a collection of must-have tools, contribs or hooks for a
> subversion server. :)
>
> And... if they are "must-have" or commonly implemented, why are they not
> included with the svn server by default?
> Sincerely,
> Chris.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org