On Fri, Apr 30, 2010 at 4:02 PM, Itamar O <itamarost_at_gmail.com> wrote:
> On Fri, Apr 30, 2010 at 1:23 PM, Ravi Roy <ravi.aroy_at_gmail.com> wrote:
> > On Fri, Apr 30, 2010 at 3:38 PM, Ryan Schmidt
> > <subversion-2010b_at_ryandesign.com> wrote:
> >> On Apr 30, 2010, at 04:52, Ravi Roy wrote:
> >> > I am writing a custom hook (pre-commit) to find out the size of the
> >> > transaction for certain size and then allow / disallow commit. But I
> am not
> >> > sure what is the structure under /db/transactions which should be
> >> > for size ?
> >> You don't need to know. :) Instead, use the "svnlook" program to inspect
> >> the transaction for the information you need. For example, "svnlook
> >> to see what changed in the transaction, and "svnlook cat" to get the
> >> contents of individual files from the transaction, whose bytes you can
> >> sum up.
> > Thankd Ryan. Don't you think svnlook cat -t $T > contentsfile would be
> > havy for pre-commit hook to handle and make repo commits slow :-)
> > Suppose somebody is trying to commit 100 MB of file which I want to
> > in principle, I think this will cause performace issues.
> This will probably add some delay to the process,
> but keep in mind that in the pre-commit part the file was already
> transferred to the server, and this was probably the significant delay.
> Unless information about files in the transaction and their sizes is
> available in the start-commit phase (which occurs before the actual
> transfer of content), there's no way to avoid the "big" delay over the
> Which makes me wonder - is this information available in start-commit..?
Not really sure. making a file *svnlook cat* will definitely slow down
operations (specially for big files).
But anyway file has to be transferred to server before transaction size
could be computed.
So until commit is taking place, it would not be part of repo.
Does somebody knows an optimum way how this could be achieved without
causing performance bottlenecks?
Received on 2010-04-30 13:16:09 CEST