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

Client Hook to Server Hook communication

From: Simon Berry <Simon.Berry_at_andromeda.uk.com>
Date: Tue, 27 Jan 2009 23:21:10 +0000

I want to achieve the following :

1. User starts a commit
2. Client side hook checks files being committed for validity, rejects if not ok
3. Client side hook 'signs' the commit (via log message ?) to verify that data is correct
4. Server side hook checks incoming commit for 'signature'
5. Server side hook either accepts commit or rejects it with appropriate message

The reason for the signature is twofold
- it verifies that the data is in the correct format
- it prevents clients without hooks from committing at all (and therefore prevents committing of un-validated data)

My questions are:
a) Is the log message a good place to put the 'signature'?
b) I could make the signature a simple string, e.g. 'VERIFIED', but then I would want to strip this out in the server side hook so that user wouldn't cotton on to the fact that they could append 'VERIFIED' to their log message and bypass the system. However, the server side 'start-commit' hook does not appear to receive any parameters relating to the log text. There is also a warning in the documentation about modifying any of the committed data. Because in our case the files being committed are large (20MB+), I would prefer to use the 'start-commit' hook rather than the pre-commit hook ... the users would get pretty upset if they spent an hour uploading data only to be told that the commit failed...
c) I also thought that I could do a hash/MD5 of the data being committed to 'sign' the commit. Maybe svn/tortoisesvn does this already? If so, can it be accessed?

Has anyone done anything similar before? Any thoughts are welcome.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-01-28 06:56:19 CET

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