[svk-devel] Re: svk-devel Digest, Vol 16, Issue 20

Fri Oct 26 18:44:22 EDT 2007

Darn. Sounds like something that my humble noodling around isn't going to cure.

On 26/10/2007, svk-devel-request at bestpractical.com
<svk-devel-request at bestpractical.com> wrote:
> Send svk-devel mailing list submissions to
>         svk-devel at bestpractical.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel
> or, via email, send a message with subject or body 'help' to
>         svk-devel-request at bestpractical.com
>
> You can reach the person managing the list at
>         svk-devel-owner at bestpractical.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of svk-devel digest..."
>
>
> Today's Topics:
>
>    1. Slow sync on big revisions (Adrian Wilkins)
>    2. Re: Slow sync on big revisions (Jesse Vincent)
>    3. Re: Slow sync on big revisions (Adrian Wilkins)
>    4. Re: Re: Slow sync on big revisions (Chia-liang Kao)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 25 Oct 2007 17:16:35 +0100
> From: "Adrian Wilkins" <adrian.wilkins at gmail.com>
> Subject: [svk-devel] Slow sync on big revisions
> To: svk-devel at bestpractical.com
> Message-ID:
>         <1213a9470710250916y611538b5ue77adc6bab902f78 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> In a revision which edits 3600 files, with 2.2MB of delta in the back
> end repository revision, SVK sits there and eats 19 minutes of CPU
> time. It actually takes so long that I had to switch compression off
> on the server because it was cutting it off at the DEFLATE filter as
> it timed out.
>
> My question is, since SVK seems to be aware of the part of the RA
> layer that svnsync uses to replay transactions, why does this take so
> long? The folder holding the revision takes about 12 minutes for a
> fresh checkout. Is the replay API being used under all conditions (not
> from my reading of the code though)? The sync is being done over an
> office LAN, so bandwidth is not an issue. If the replay functions are
> not being used, would using them speed things up a lot?
>
> I would be taking full mirrors of my production repos for work at
> home, but alas, at this pace, some of them will take longer than a
> workday to sync.
>
> Second example. The entire changeset consists of a mere 1MB composed
> of 708 XML files, in the same folder, added in one revision. About 5
> minutes to sync.
>
> I can fully appreciate there may be a good reason for this, but it's
> still impeding my workflow.
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 25 Oct 2007 15:34:35 -0400
> From: Jesse Vincent <jesse at bestpractical.com>
> Subject: Re: [svk-devel] Slow sync on big revisions
> To: svk-devel at bestpractical.com
> Message-ID: <9B98E0B8-E3D5-4AD1-B434-4913393BB915 at bestpractical.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Adrian,
>
> What versions of SVK and SVN are you using on your client? What
> version of SVN on the server?
>
> Best,
> Jesse
> On Oct 25, 2007, at 12:16 PM, Adrian Wilkins wrote:
>
> > In a revision which edits 3600 files, with 2.2MB of delta in the back
> > end repository revision, SVK sits there and eats 19 minutes of CPU
> > time. It actually takes so long that I had to switch compression off
> > on the server because it was cutting it off at the DEFLATE filter as
> > it timed out.
> >
> > My question is, since SVK seems to be aware of the part of the RA
> > layer that svnsync uses to replay transactions, why does this take so
> > long? The folder holding the revision takes about 12 minutes for a
> > fresh checkout. Is the replay API being used under all conditions (not
> > from my reading of the code though)? The sync is being done over an
> > office LAN, so bandwidth is not an issue. If the replay functions are
> > not being used, would using them speed things up a lot?
> >
> > I would be taking full mirrors of my production repos for work at
> > home, but alas, at this pace, some of them will take longer than a
> > workday to sync.
> >
> > Second example. The entire changeset consists of a mere 1MB composed
> > of 708 XML files, in the same folder, added in one revision. About 5
> > minutes to sync.
> >
> > I can fully appreciate there may be a good reason for this, but it's
> > still impeding my workflow.
> > _______________________________________________
> > svk-devel mailing list
> > svk-devel at bestpractical.com
> > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel
> >
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: PGP.sig
> Type: application/pgp-signature
> Size: 186 bytes
> Desc: This is a digitally signed message part
> Url : http://lists.bestpractical.com/pipermail/svk-devel/attachments/20071025/82b050c4/PGP-0001.pgp
>
> ------------------------------
>
> Message: 3
> Date: Fri, 26 Oct 2007 11:22:18 +0100
> From: "Adrian Wilkins" <adrian.wilkins at gmail.com>
> Subject: [svk-devel] Re: Slow sync on big revisions
> To: svk-devel at bestpractical.com
> Message-ID:
>         <1213a9470710260322o6f17769di25b8760afa9ff626 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> > What versions of SVK and SVN are you using on your client? What
> > version of SVN on the server?
> > Best,
> > Jesse
>
> Client is Win32 SVK 2.02
> Server is Win32 Apache 2.055 running SVN 1.4.3 (r23084)
> The installed command line client is Win32 1.4.4 (r25188)
>
> The client has a perl binding installed, but AFAIK svk uses it's own
> packaged copy of the perl bindings, no?
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 26 Oct 2007 22:40:21 +0800
> From: "Chia-liang Kao" <clkao at clkao.org>
> Subject: Re: [svk-devel] Re: Slow sync on big revisions
> To: svk-devel at bestpractical.com
> Message-ID:
>         <cdd66f110710260740p6971a51djc28370a964f715e1 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 26/10/2007, Adrian Wilkins <adrian.wilkins at gmail.com> wrote:
> > Client is Win32 SVK 2.02
> > Server is Win32 Apache 2.055 running SVN 1.4.3 (r23084)
> > The installed command line client is Win32 1.4.4 (r25188)
>
> at the moment replay is not enabled for win32 svk.  This is due to
> some apr and perl thread issues causing the svk sync process making
> use of replay to crash.
>
> Cheers,
> CLK
>
>
> ------------------------------
>
> _______________________________________________
> svk-devel mailing list
> svk-devel at bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel
>
>
> End of svk-devel Digest, Vol 16, Issue 20
> *****************************************
>