You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Eric Jonas <jo...@MIT.EDU> on 2003/12/05 17:24:11 UTC

server hooks for post-commit metadata modifications?

Hello! Is there any way to use the hooks mechanism to modify individual
file/dir metadata without requiring another commit? Ideally, I'd like to
have users of the repository commit a change, have the server update a
certain property on all the files, and then have the commit proceed. I'd
like to have the server do something like gpg-sign each revision of each
file as its committed.

			...Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: server hooks for post-commit metadata modifications?

Posted by Julian Foad <ju...@btopenworld.com>.
Eric Jonas wrote:
> 
>>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.

That sounds like a very good solution.

- Julian


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: server hooks for post-commit metadata modifications?

Posted by Eric Jonas <jo...@MIT.EDU>.

> 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

Re: server hooks for post-commit metadata modifications?

Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2003-12-05 at 09:24, Eric Jonas wrote:
> Hello! Is there any way to use the hooks mechanism to modify individual
> file/dir metadata without requiring another commit? Ideally, I'd like to
> have users of the repository commit a change, have the server update a
> certain property on all the files, and then have the commit proceed.

This is BAD.  Do NOT do this.  Read the warning in the pre-commit hook
template:


#   ***   NOTE: THE HOOK PROGRAM MUST NOT MODIFY THE TXN.    ***
#   This is why we recommend using the read-only 'svnlook' utility.
#   In the future, Subversion may enforce the rule that pre-commit
#   hooks should not modify txns, or else come up with a mechanism
#   to make it safe to do so (by informing the committing client of
#   the changes).  However, right now neither mechanism is
#   implemented, so hook writers just have to be careful.

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.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org