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

pre-commit hook is finding transaction author to be a 'random' number sometimes

From: <nick-svnusers_at_nickpiper.co.uk>
Date: 2007-01-15 14:22:39 CET


I have a pre-commit hook that runs svninfo author, and sometimes it
returns a number instead of the actual username.

The transactions are created by the java svnkit library, over svn://

svnlook returns things like '1571020', or '0:' (inc. the colon!), or
'1571073', but most often works fine returning the real username that
we supplied to the svnkit API.

Is that transaction username provided entirely by the client, and
svnserve just trusts it? I'm trying to see if I should investigate the
client or server initially. We did just upgrade from javasvn 0.9.2 to
svnkit 1.1.0 recently, so this is a likely candidate.

We're now using svnkit 1.1.0 on the client side, and svnserve
1.1.4. (We realise that is very old, we're required by a vendor to
continue to use that server as they "do not support higher versions.")

Our pre-commit hook fails the transaction when the invalid username
appears, so the transactions are not committed to allow us to review
them now.

I'm posting in case someone has seen such a situation before or can
offer advice. I expect we should now allow the transactions to
complete, so we can look at what is written into the repository, and
we should cause lots of transactions so we might catch a bad one under
tcpdump to study the svn protocol conversation.

Thanks and regards,


Nick Piper, Developer, LogicaCMG           http://www.nickpiper.co.uk/
GPG Encrypted mail welcome!                             1024D/3ED8B27F
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 15 14:34:37 2007

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.