Re: Pre-commit and post-chekout hooks on client side

From: Waldemar Augustyn <waldemar_at_nxp.com>
Date: 2004-09-08 18:31:37 CEST

That's because the scripts use rule sets and distributing them to clients is really not under consideration.

There is this idea of having clients pull the scripts from the server on demand.  This would require a wrapper or a client-side hook.  Rather ugly. 

I think, the way to go is to use a post-commit hook that triggers a checkout-modify-checkin cycle on the server side on behalf of the original user.  A bit involved but doable.

BTW, I am having hard time believing the clients would get messed up.  They really have to do an implicit 'status' to claim correspondence to any particular version.  Do they get just a version number back?  Maybe they should get a diff along with it instead of assuming perfect synchronization.

Whatever the case, I think this points out to some missing functionality svn might want to consider adding.




kfogel@collab.net wrote:

Waldemar Augustyn <waldemar@nxp.com> writes:
  

Now, with SVN, that is not possible.  The hooks, that you are
referring to, do not allow updates to pending transactions, which I
understand prohibits any file modifications.  I am no expert, but I
thought I saw a note to that effect.  I think that would break the
atomic nature of transactions otherwise.
    

You are correct that this is disallowed.  Not because it breaks
atomicity, but because it breaks the correspondence between what the
client thinks it has committed and what the repository thinks was
committed.

However, why don't you use a 'pre-commit' hook to check if the files
are correct, and simply reject the commit if they're not?  Then the
user on the client side will notice, fix them, and try again.

-Karl


  

--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For additional commands, e-mail: users-help@subversion.tigris.org Received on Wed Sep 8 18:32:29 2004