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

Re: any "must-have" hooks to implement on svn server?

From: Ryan Schmidt <subversion-2008c_at_ryandesign.com>
Date: Thu, 24 Jul 2008 16:17:49 -0500

On Jul 24, 2008, at 08:38, christian.peper_at_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_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-24 23:18:19 CEST

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.