the majority of pre-commit hook scripts I have seen have to do with
metadata: filename, mime-type, eol settings, file size. "Is it okay for
this file to be checked in?", as far as I have seen, rarely checks the
file content itself (and if you're not checking if it's okay for the
file to be checked in, you tend to use a /post/commit hook). Due to
this, I wouldnt think the number of cases where this optimization
/wouldnt/ pay off would be all too high.
As for filesize, most pre-commit hooks that I have seen are intended to
assist with new files being added (or preventing those additions), the
assumption being that other operations will tend to be done through an
existing clean working copy- something which already follows the repos'
naming conventions and has (at the least) templates for all required
properties. While they also check files which already exist, it is for
the most part uneccessary as most accidents which are checked for by
pre-commit hooks are only going to happen when adding things.
The pre-commit hook included as an example checks the log file to see it
is not empty- would you really want to upload your entire commit before
recieving this information?
Yeah, more time is sometimes spent calculating diffs than transferring
data. That doesnt mean the current order makes sense :)
James FitzGibbon wrote:
> On Aug-19-05, at 8:30 PM, Vincent Starre wrote:
>
>> Doesnt that hook script not act until AFTER all data has been sent?
>> (am I the only one who sees this as a seriously limitation? Or
>> perhaps the only one with files greater than a couple kb in his repo?)
>
>
> Bear in mind that the client sends diffs to the server, so the file
> size doesn't directly translate into network traffic.
>
> What alternative would you suggest? That the metadata go first, then
> some hooks get the chance to run, then the content get sent and other
> hooks get the chance to run? I don't think that the number of cases
> where that particular optimization would pay off is worth the ongoing
> maintenance costs. It would also, I believe, increase the size of
> the window during which conflicts could happen, and so have a
> detrimental effect on heavy hit repositories.
>
> Regards
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Aug 20 05:54:43 2005