Fix SVN properties for git-svn users

[Util]

git-svn does not support SVN properties (except svn:executable), and that lack of support is painful to Git users working on Parrot. Something needs to be done to automatically apply the appropriate properties during (or immediately after) commits that add files. Possible solutions:

1. Server-side hooks
2. Improvements to git-svn

[Util]

This problem was identified and discussed in the 2009-09-01 #parrotsketch IRC meeting  http://irclog.perlgeek.de/parrotsketch/2009-09-01#i_1454166:

18:55 chromatic   mikehh, question?
18:56 mikehh      I am getting a lot of codetest/distro_tests failures with svn properties from git svn users
18:56 mikehh      any way to sort this out?
18:57 chromatic   We talked about autoprops set on the server with a commit hook.
18:57 allison     are they not able to set svn props?
18:57 * japhb     fights the urge to troll an old argument
18:58 allison     they coul
18:58 chromatic   The old argument "Why are these properties useful again?"
18:58 japhb       allison, that's correct, git-svn does not handle svn props.  So git-svn users need to have a normal svn checkout, and remember to run the codetests in there after committing new files.
18:59 japhb       *have a normal svn checkout *also*
18:59 allison     (cellphone keyboard)
18:59 allison     that doesn't sound so terrible
19:00 japhb       allison, no, but very easy to forget.  :-/
19:00 mikehh      well the svn:keywords appear in the header
19:00 mikehh      of the file that is
19:01 allison     chromatic: server-side hooks are a good idea, but how do we know for sure when to apply them?
19:01 chromatic   We *always* apply them.
19:01 japhb       mikehh, I mean, easy for a git-svn user to forget to give the svn props a hug, after doing a big commit people tend to think they are done and go grab a beer.
19:01 chromatic   They're basically the *same* on *every* file in the repository.
19:01 allison     c: not all props apply to all files
19:02 chromatic   I can think of two files out of our 6500+ which have different properties.
19:02 mikehh      svn:mime_type for tests
19:02 allison     txt vs binary, etc
19:02 Coke        we wouldn't need the mime type if we had sane server defaults.
19:02 japhb       allison, but if there is a computer-understandable rule that works 95% of the time, we should have the computer apply it, and let humans override it.
19:02 duk3leto    allison: there is no git svn propset
19:03 allison     japhb: git users wouldn't be able to interact withit
19:04 allison     but can correct later
19:04 duk3leto    japhb: git svn propget works, just not setting
19:04 japhb       duk3leto, nodnod
19:04 chromatic   Let's move this discussion over to #parrot.
19:04 allison     any volunteers
19:05 chromatic   Volunteers for server-side hooks?
19:06 allison     (can't join #parrot from here, but log my thumbs up for exploring adding server-side hooks)
19:06 Util        I wrote code months ago to analyse our SVN properties, but just used it for manual corrections. Have not done serverside hooks, but willing to try.

[Util]

Everyone in #parrotsketch was keen on solving this with server-side hooks; The SVN documentation speaks to this:
 http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html#svn.reposadmin.create.hooks

Warning

While hook scripts can do almost anything, there is one dimension in which hook script authors should show restraint: do not modify a commit transaction using hook scripts. While it might be tempting to use hook scripts to automatically correct errors, shortcomings, or policy violations present in the files being committed, doing so can cause problems. Subversion keeps client-side caches of certain bits of repository data, and if you change a commit transaction in this way, those caches become indetectably stale. This inconsistency can lead to surprising and unexpected behavior. Instead of modifying the transaction, you should simply validate the transaction in the pre-commit hook and reject the commit if it does not meet the desired requirements. As a bonus, your users will learn the value of careful, compliance-minded work habits.

[Util]

The git-svn manpage,
 http://www.kernel.org/pub/software/scm/git/docs/git-svn.html ,
says in its BUGS section:

We ignore all SVN properties except svn:executable. Any unhandled properties are logged to $GIT_DIR/svn/<refname>/unhandled.log

However, the actual code in git-1.6.1.2 seems to show that this part of the docs is out-of-date, and that properties are supported, if configured correctly.

I am pursuing this line of research now.

[coke]

Rejecting this ticket; we'll be even nicer to the git-svn people by moving to git instead.

Regards.