> If the pre-commit hook modifies the commit transaction, the client will
> be forever in the dark. It will think that the new revision looks one
> way, but in reality, it will be something completely different in the
> repository. There's currently no way for a pre-commit hook to "inform
> the client" that something different was committed than what the client
> sent.
Thanks for explaining _why_ it was such a bad idea. Now I see the error
of my ways. I'm really trying to have metadata that represents the sha1 of
each committed file -- there's no reason I can't have the client do this
by setting a property before commit for each file that's equal to the
sha1, and then have the server simply verify that the sha1s are correct,
and abort the commit if they're not.
I was mostly concerned about clients without this support being allowed
to commit code, but making the server pre-commit validate is a better
idea. Thanks again!
...Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Dec 7 07:16:11 2003