You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Thomas Pircher <te...@gmx.net> on 2008/01/11 11:10:33 UTC
HTTP network traffic of simple SVN commands
Hi,
[this is probably a FAQ, but I could not find it in the Subversion FAQ.]
A simple 'svn cat file' produces an incredible network traffic. For
example, a
svn cat http://svn.collab.net/repos/svn/trunk/BUGS
produces over 70 packets over the network. When I do it on our internal
SVN server (HTTP with authentication) I get the beauty of 278 IP packets
transferred over the wire.
The SVN client and our internal server are both on version 1.4.4 and are
running on Linux.
Is this due to a misconfiguration on my side? Is it possible to optimize
the traffic? I'm accessing our internal SVN server through a _very_ slow
VPN, so reducing the amounts of packets would give me a huge benefit.
Thanks,
Thomas
PS: Since I'm so impressed with the amount of packets, I'll send a tcpdump
of the above svn cat command:
root@pundit:~# tcpdump host svn.collab.net -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:01:02.043277 IP 192.168.1.33.34809 > 204.11.125.46.80: S
891363628:891363628(0) win 5840 <mss 1460,sackOK,timestamp 40492510
0,nop,wscale 6>
11:01:02.200274 IP 204.11.125.46.80 > 192.168.1.33.34809: S
2064750469:2064750469(0) ack 891363629 win 5792 <mss 1360,sackOK,timestamp
4116581183 40492510,nop,wscale 2>
11:01:02.200290 IP 192.168.1.33.34809 > 204.11.125.46.80: . ack 1 win 92
<nop,nop,timestamp 40492550 4116581183>
11:01:02.200391 IP 192.168.1.33.34809 > 204.11.125.46.80: P 1:267(266) ack
1 win 92 <nop,nop,timestamp 40492550 4116581183>
11:01:02.200398 IP 192.168.1.33.34809 > 204.11.125.46.80: P 267:567(300)
ack 1 win 92 <nop,nop,timestamp 40492550 4116581183>
11:01:02.356835 IP 204.11.125.46.80 > 192.168.1.33.34809: . ack 267 win
1716 <nop,nop,timestamp 4116581340 40492550>
11:01:02.357260 IP 204.11.125.46.80 > 192.168.1.33.34809: . ack 567 win
1984 <nop,nop,timestamp 4116581340 40492550>
11:01:02.360790 IP 204.11.125.46.80 > 192.168.1.33.34809: P 1:652(651) ack
567 win 1984 <nop,nop,timestamp 4116581342 40492550>
11:01:02.360797 IP 192.168.1.33.34809 > 204.11.125.46.80: . ack 652 win
112 <nop,nop,timestamp 40492590 4116581342>
11:01:02.361247 IP 192.168.1.33.34809 > 204.11.125.46.80: P 567:813(246)
ack 652 win 112 <nop,nop,timestamp 40492590 4116581342>
11:01:02.361257 IP 192.168.1.33.34809 > 204.11.125.46.80: P 813:924(111)
ack 652 win 112 <nop,nop,timestamp 40492590 4116581342>
11:01:02.527086 IP 204.11.125.46.80 > 192.168.1.33.34809: P 652:1148(496)
ack 924 win 2252 <nop,nop,timestamp 4116581501 40492590>
11:01:02.527342 IP 192.168.1.33.34809 > 204.11.125.46.80: P 924:1168(244)
ack 1148 win 132 <nop,nop,timestamp 40492631 4116581501>
11:01:02.527354 IP 192.168.1.33.34809 > 204.11.125.46.80: P 1168:1316(148)
ack 1148 win 132 <nop,nop,timestamp 40492631 4116581501>
11:01:02.685017 IP 204.11.125.46.80 > 192.168.1.33.34809: P 1148:1658(510)
ack 1316 win 2520 <nop,nop,timestamp 4116581667 40492631>
11:01:02.685317 IP 192.168.1.33.34809 > 204.11.125.46.80: P 1316:1556(240)
ack 1658 win 153 <nop,nop,timestamp 40492671 4116581667>
11:01:02.685326 IP 192.168.1.33.34809 > 204.11.125.46.80: P 1556:1856(300)
ack 1658 win 153 <nop,nop,timestamp 40492671 4116581667>
11:01:02.842495 IP 204.11.125.46.80 > 192.168.1.33.34809: . ack 1856 win
2520 <nop,nop,timestamp 4116581825 40492671>
11:01:02.843280 IP 204.11.125.46.80 > 192.168.1.33.34809: P 1658:2253(595)
ack 1856 win 2520 <nop,nop,timestamp 4116581826 40492671>
11:01:02.843557 IP 192.168.1.33.34809 > 204.11.125.46.80: P 1856:2102(246)
ack 2253 win 173 <nop,nop,timestamp 40492710 4116581826>
11:01:02.843578 IP 192.168.1.33.34809 > 204.11.125.46.80: P 2102:2213(111)
ack 2253 win 173 <nop,nop,timestamp 40492710 4116581826>
11:01:03.004292 IP 204.11.125.46.80 > 192.168.1.33.34809: P 2253:2749(496)
ack 2213 win 2520 <nop,nop,timestamp 4116581983 40492710>
11:01:03.004574 IP 192.168.1.33.34809 > 204.11.125.46.80: P 2213:2457(244)
ack 2749 win 193 <nop,nop,timestamp 40492751 4116581983>
11:01:03.004595 IP 192.168.1.33.34809 > 204.11.125.46.80: P 2457:2605(148)
ack 2749 win 193 <nop,nop,timestamp 40492751 4116581983>
11:01:03.166133 IP 204.11.125.46.80 > 192.168.1.33.34809: P 2749:3259(510)
ack 2605 win 2788 <nop,nop,timestamp 4116582145 40492751>
11:01:03.166396 IP 192.168.1.33.34809 > 204.11.125.46.80: P 2605:2845(240)
ack 3259 win 214 <nop,nop,timestamp 40492791 4116582145>
11:01:03.166408 IP 192.168.1.33.34809 > 204.11.125.46.80: P 2845:3145(300)
ack 3259 win 214 <nop,nop,timestamp 40492791 4116582145>
11:01:03.330845 IP 204.11.125.46.80 > 192.168.1.33.34809: . ack 3145 win
2788 <nop,nop,timestamp 4116582309 40492791>
11:01:03.331642 IP 204.11.125.46.80 > 192.168.1.33.34809: P 3259:3854(595)
ack 3145 win 2788 <nop,nop,timestamp 4116582309 40492791>
11:01:03.331921 IP 192.168.1.33.34809 > 204.11.125.46.80: P 3145:3391(246)
ack 3854 win 234 <nop,nop,timestamp 40492832 4116582309>
11:01:03.331941 IP 192.168.1.33.34809 > 204.11.125.46.80: P 3391:3502(111)
ack 3854 win 234 <nop,nop,timestamp 40492832 4116582309>
11:01:03.492061 IP 204.11.125.46.80 > 192.168.1.33.34809: P 3854:4350(496)
ack 3502 win 2788 <nop,nop,timestamp 4116582472 40492832>
11:01:03.492305 IP 192.168.1.33.34809 > 204.11.125.46.80: P 3502:3746(244)
ack 4350 win 254 <nop,nop,timestamp 40492873 4116582472>
11:01:03.492317 IP 192.168.1.33.34809 > 204.11.125.46.80: P 3746:3894(148)
ack 4350 win 254 <nop,nop,timestamp 40492873 4116582472>
11:01:03.649818 IP 204.11.125.46.80 > 192.168.1.33.34809: P 4350:4860(510)
ack 3894 win 3056 <nop,nop,timestamp 4116582632 40492873>
11:01:03.650114 IP 192.168.1.33.34809 > 204.11.125.46.80: P 3894:4134(240)
ack 4860 win 275 <nop,nop,timestamp 40492912 4116582632>
11:01:03.650123 IP 192.168.1.33.34809 > 204.11.125.46.80: P 4134:4434(300)
ack 4860 win 275 <nop,nop,timestamp 40492912 4116582632>
11:01:03.806554 IP 204.11.125.46.80 > 192.168.1.33.34809: . ack 4434 win
3056 <nop,nop,timestamp 4116582790 40492912>
11:01:03.809851 IP 204.11.125.46.80 > 192.168.1.33.34809: P 4860:5455(595)
ack 4434 win 3056 <nop,nop,timestamp 4116582791 40492912>
11:01:03.810130 IP 192.168.1.33.34809 > 204.11.125.46.80: P 4434:4694(260)
ack 5455 win 295 <nop,nop,timestamp 40492952 4116582791>
11:01:03.810150 IP 192.168.1.33.34809 > 204.11.125.46.80: P 4694:4842(148)
ack 5455 win 295 <nop,nop,timestamp 40492952 4116582791>
11:01:03.969019 IP 204.11.125.46.80 > 192.168.1.33.34809: P 5455:5971(516)
ack 4842 win 3324 <nop,nop,timestamp 4116582951 40492952>
11:01:03.969276 IP 192.168.1.33.34809 > 204.11.125.46.80: P 4842:5096(254)
ack 5971 win 316 <nop,nop,timestamp 40492992 4116582951>
11:01:03.969287 IP 192.168.1.33.34809 > 204.11.125.46.80: P 5096:5396(300)
ack 5971 win 316 <nop,nop,timestamp 40492992 4116582951>
11:01:04.127700 IP 204.11.125.46.80 > 192.168.1.33.34809: . ack 5396 win
3324 <nop,nop,timestamp 4116583109 40492992>
11:01:04.128515 IP 204.11.125.46.80 > 192.168.1.33.34809: P 5971:6573(602)
ack 5396 win 3324 <nop,nop,timestamp 4116583110 40492992>
11:01:04.128825 IP 192.168.1.33.34809 > 204.11.125.46.80: P 5396:5636(240)
ack 6573 win 336 <nop,nop,timestamp 40493032 4116583110>
11:01:04.128834 IP 192.168.1.33.34809 > 204.11.125.46.80: P 5636:5936(300)
ack 6573 win 336 <nop,nop,timestamp 40493032 4116583110>
11:01:04.291777 IP 204.11.125.46.80 > 192.168.1.33.34809: . ack 5936 win
3324 <nop,nop,timestamp 4116583269 40493032>
11:01:04.292954 IP 204.11.125.46.80 > 192.168.1.33.34809: P 6573:7168(595)
ack 5936 win 3324 <nop,nop,timestamp 4116583270 40493032>
11:01:04.293221 IP 192.168.1.33.34809 > 204.11.125.46.80: P 5936:6196(260)
ack 7168 win 356 <nop,nop,timestamp 40493073 4116583270>
11:01:04.293232 IP 192.168.1.33.34809 > 204.11.125.46.80: P 6196:6344(148)
ack 7168 win 356 <nop,nop,timestamp 40493073 4116583270>
11:01:04.453430 IP 204.11.125.46.80 > 192.168.1.33.34809: P 7168:7684(516)
ack 6344 win 3592 <nop,nop,timestamp 4116583434 40493073>
11:01:04.453686 IP 192.168.1.33.34809 > 204.11.125.46.80: P 6344:6597(253)
ack 7684 win 377 <nop,nop,timestamp 40493113 4116583434>
11:01:04.453698 IP 192.168.1.33.34809 > 204.11.125.46.80: P 6597:6679(82)
ack 7684 win 377 <nop,nop,timestamp 40493113 4116583434>
11:01:04.614701 IP 204.11.125.46.80 > 192.168.1.33.34809: P 7684:8620(936)
ack 6679 win 3592 <nop,nop,timestamp 4116583596 40493113>
11:01:04.615110 IP 192.168.1.33.34809 > 204.11.125.46.80: P 6679:6919(240)
ack 8620 win 406 <nop,nop,timestamp 40493153 4116583596>
11:01:04.615120 IP 192.168.1.33.34809 > 204.11.125.46.80: P 6919:7219(300)
ack 8620 win 406 <nop,nop,timestamp 40493153 4116583596>
11:01:04.776724 IP 204.11.125.46.80 > 192.168.1.33.34809: . ack 7219 win
3592 <nop,nop,timestamp 4116583755 40493153>
11:01:04.777515 IP 204.11.125.46.80 > 192.168.1.33.34809: P 8620:9215(595)
ack 7219 win 3592 <nop,nop,timestamp 4116583755 40493153>
11:01:04.777788 IP 192.168.1.33.34809 > 204.11.125.46.80: P 7219:7479(260)
ack 9215 win 435 <nop,nop,timestamp 40493194 4116583755>
11:01:04.777810 IP 192.168.1.33.34809 > 204.11.125.46.80: P 7479:7627(148)
ack 9215 win 435 <nop,nop,timestamp 40493194 4116583755>
11:01:04.941832 IP 204.11.125.46.80 > 192.168.1.33.34809: P 9215:9731(516)
ack 7627 win 3860 <nop,nop,timestamp 4116583918 40493194>
11:01:04.942103 IP 192.168.1.33.34809 > 204.11.125.46.80: P 7627:7881(254)
ack 9731 win 464 <nop,nop,timestamp 40493235 4116583918>
11:01:04.942114 IP 192.168.1.33.34809 > 204.11.125.46.80: P 7881:8029(148)
ack 9731 win 464 <nop,nop,timestamp 40493235 4116583918>
11:01:05.105024 IP 204.11.125.46.80 > 192.168.1.33.34809: P
9731:10258(527) ack 8029 win 4128 <nop,nop,timestamp 4116584083 40493235>
11:01:05.105335 IP 192.168.1.33.34809 > 204.11.125.46.80: P 8029:8200(171)
ack 10258 win 494 <nop,nop,timestamp 40493276 4116584083>
11:01:05.265600 IP 204.11.125.46.80 > 192.168.1.33.34809: P
10258:10685(427) ack 8200 win 4396 <nop,nop,timestamp 4116584247 40493276>
11:01:05.265827 IP 192.168.1.33.34809 > 204.11.125.46.80: F 8200:8200(0)
ack 10685 win 523 <nop,nop,timestamp 40493316 4116584247>
11:01:05.426249 IP 204.11.125.46.80 > 192.168.1.33.34809: F 10685:10685(0)
ack 8201 win 4396 <nop,nop,timestamp 4116584405 40493316>
11:01:05.426259 IP 192.168.1.33.34809 > 204.11.125.46.80: . ack 10686 win
523 <nop,nop,timestamp 40493356 4116584405>
71 packets captured
75 packets received by filter
0 packets dropped by kernel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: HTTP network traffic of simple SVN commands
Posted by Erik Huelsmann <eh...@gmail.com>.
On 1/14/08, Thomas Pircher <te...@gmx.net> wrote:
> Ryan Schmidt wrote:
> > On Jan 11, 2008, at 17:47, Karen Tracey wrote:
> >
> >> So configuring KeepAlive On in the
> >> Apache config for your internal server could help. (svn.collab.net
> >> is apparently configured with it On)
> >
> > Maybe "SVNPathAuthz off" in your httpd.conf would help, if you don't
> > need path-based authorization.
>
> Thanks Karen and Ryan!
> With KeepAlive I could reduce the number of packets from 282 down to 100!
> With SVNPathAuthz I svae othe 3 packets. Not much, but on our low VPS it
> is still an improvement! :-)
Come 1.5 you'll be able to use HTTP/1.1 pipelining by using the
ra_serf HTTP access layer. That should reduce your latency problems.
Unfortunately, I'm unable to tell you when 1.5 will be available
exactly.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: HTTP network traffic of simple SVN commands
Posted by Thomas Pircher <te...@gmx.net>.
Ryan Schmidt wrote:
> On Jan 11, 2008, at 17:47, Karen Tracey wrote:
>
>> So configuring KeepAlive On in the
>> Apache config for your internal server could help. (svn.collab.net
>> is apparently configured with it On)
>
> Maybe "SVNPathAuthz off" in your httpd.conf would help, if you don't
> need path-based authorization.
Thanks Karen and Ryan!
With KeepAlive I could reduce the number of packets from 282 down to 100!
With SVNPathAuthz I svae othe 3 packets. Not much, but on our low VPS it
is still an improvement! :-)
Cheers,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: HTTP network traffic of simple SVN commands
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jan 11, 2008, at 17:47, Karen Tracey wrote:
> At 06:10 AM 1/11/2008, Thomas Pircher wrote:
>
>> [this is probably a FAQ, but I could not find it in the Subversion
>> FAQ.]
>> A simple 'svn cat file' produces an incredible network traffic. For
>> example, a
>> svn cat http://svn.collab.net/repos/svn/trunk/BUGS
>> produces over 70 packets over the network. When I do it on our
>> internal
>> SVN server (HTTP with authentication) I get the beauty of 278 IP
>> packets
>> transferred over the wire.
>>
>> The SVN client and our internal server are both on version 1.4.4
>> and are
>> running on Linux.
>>
>> Is this due to a misconfiguration on my side? Is it possible to
>> optimize
>> the traffic? I'm accessing our internal SVN server through a
>> _very_ slow
>> VPN, so reducing the amounts of packets would give me a huge benefit.
>
> Based on a wild guess and some experiments I just tried, the 70 vs.
> 278 packets is probably a result of your internal SVN server being
> configured with KeepAlive Off. For my own server (where I use
> https://) I get 86 packets for a small file cat with KeepAlive On
> and 343 with KeepAlive Off. So configuring KeepAlive On in the
> Apache config for your internal server could help. (svn.collab.net
> is apparently configured with it On)
>
> Still, 70+ packets for a tiny-file cat seems like a lot. I took my
> own packet capture for the BUGS file with a tool that could parse
> the payloads and it shows that the SVN client issues 18 PROPFINDs
> before finally sending the GET for the file. Each of these is sent
> in two pieces, first the headers and than the xml of the content;
> the response comes in a single packet. So that is 3*18 = 54
> packets, plus 2 for the actual GET and its response, plus 6 for
> typical minimum TCP connection setup and teardown: 62 packets. In
> my trace there were an additional 14 packets of TCP overhead from
> bare ACKs that did not get piggypbacked on data, for a total
> exchange of 76 packets.
>
> What are all those PROPFINDs? Oddly, 11 of them seem to be
> duplicates of ones requested earlier in the exchange. I know
> nothing of SVN internals, so I have no idea why it does this.
> There may be a good reason, or I may be missing some subtle
> difference in the requests. It may also be a case of this just not
> being an optimized path -- after all, most often you are expected
> to be operating on your working copy, and not going to the server
> at all. Update and commit are the paths I would hope would be
> optimized, more than cat.
>
> But, in case anyone is interested or could explain the behavior,
> I'll append my breakdown of the "svn cat http://svn.collab.net/
> repos/svn/trunk/BUGS" traffic below. There seems to be a (6 times
> repeated) pattern of 3 PROPFINDs in sequence where the 1st is
> always the same and the 2nd and 3rd start to vary after three go-
> rounds.
Maybe "SVNPathAuthz off" in your httpd.conf would help, if you don't
need path-based authorization.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: HTTP network traffic of simple SVN commands
Posted by Karen Tracey <km...@gmail.com>.
At 06:10 AM 1/11/2008, Thomas Pircher wrote:
>Hi,
>
>[this is probably a FAQ, but I could not find it in the Subversion FAQ.]
>A simple 'svn cat file' produces an incredible network traffic. For
>example, a
>svn cat http://svn.collab.net/repos/svn/trunk/BUGS
>produces over 70 packets over the network. When I do it on our internal
>SVN server (HTTP with authentication) I get the beauty of 278 IP packets
>transferred over the wire.
>
>The SVN client and our internal server are both on version 1.4.4 and are
>running on Linux.
>
>Is this due to a misconfiguration on my side? Is it possible to optimize
>the traffic? I'm accessing our internal SVN server through a _very_ slow
>VPN, so reducing the amounts of packets would give me a huge benefit.
Based on a wild guess and some experiments I just tried, the 70 vs.
278 packets is probably a result of your internal SVN server being
configured with KeepAlive Off. For my own server (where I use
https://) I get 86 packets for a small file cat with KeepAlive On and
343 with KeepAlive Off. So configuring KeepAlive On in the Apache
config for your internal server could help. (svn.collab.net is
apparently configured with it On)
Still, 70+ packets for a tiny-file cat seems like a lot. I took my
own packet capture for the BUGS file with a tool that could parse the
payloads and it shows that the SVN client issues 18 PROPFINDs before
finally sending the GET for the file. Each of these is sent in two
pieces, first the headers and than the xml of the content; the
response comes in a single packet. So that is 3*18 = 54 packets,
plus 2 for the actual GET and its response, plus 6 for typical
minimum TCP connection setup and teardown: 62 packets. In my trace
there were an additional 14 packets of TCP overhead from bare ACKs
that did not get piggypbacked on data, for a total exchange of 76 packets.
What are all those PROPFINDs? Oddly, 11 of them seem to be
duplicates of ones requested earlier in the exchange. I know nothing
of SVN internals, so I have no idea why it does this. There may be a
good reason, or I may be missing some subtle difference in the
requests. It may also be a case of this just not being an optimized
path -- after all, most often you are expected to be operating on
your working copy, and not going to the server at all. Update and
commit are the paths I would hope would be optimized, more than cat.
But, in case anyone is interested or could explain the behavior, I'll
append my breakdown of the "svn cat
http://svn.collab.net/repos/svn/trunk/BUGS" traffic below. There
seems to be a (6 times repeated) pattern of 3 PROPFINDs in sequence
where the 1st is always the same and the 2nd and 3rd start to vary
after three go-rounds.
Cheers,
Karen
-----
TCP overhead startup (SYN, SYN+ACK, ACK) -- 3 packets
Q#1 (2 packets, sum 5):
PROPFIND /repos/svn/trunk/BUGS
props: version-controlled-configuration,
resourcetype,
baseline-relative-path,
repository-uuid
TCP overhead 2 bare ACKs for Q#1 packets, sum 7
A#1 (sum 8):
version-controlled-configuration: /repos/svn/!svn/vcc/default
resourcetype:
baseline-relative-path: trunk/BUGS
repository-uuid: 65390229-12b7-0310-b90b-f21a5aa7ec8e
Q#2 (2 packets, sum 10):
PROPFIND /repos/svn/!svn/vcc/default
props: checked-in
A#2 (sum 11):
checked-in: /repos/svn/!svn/bln/28868
Q#3 (2 packets, sum 13):
PROPFIND /repos/svn/!svn/bln/28868
props: baseline-collection,
version-name
A#3 (sum 14):
baseline-collection: /repos/svn/!svn/bc/28868
version-name: 28868
TCP overhead bare ACK for A#3, sum 15
Q#4 (2 packets, sum 17): repeat Q#1
TCP overhead bare ACK for Q#4, sum 18
A#4 (sum 19): repeat A#1
Q#5 (2 packets, sum 21): repeat Q#2
A#5 (sum 22): repeat A#2
Q#6 (2 packets, sum 24): repeat Q#3
A#6 (sum 25): repeat A#3
TCP overhead bare ACK for A#6, sum 26
Q#7 (2 packets, sum 28): repeat Q#1/Q#4
TCP overhead bare ACK for Q#7, sum 29
A#7 (sum 30): repeat A#1/A#4
Q#8 (2 packets, sum 32): repeat Q#2/Q#5
A#8 (sum 33): repeat A#2/A#5
Q#9 (2 packets, sum 35): repeat Q#3/Q#6
A#9 (sum 36): repeat A#3/A#6
TCP overhead bare ACK for A#9, sum 37
Q#10 (2 packets, sum 39): repeat Q#1/Q#4/Q#7
TCP overhead bare ACK for Q#10, sum 40
A#10 (sum 41): repeat A#1/A#4/A#7
Q#11 (2 packets, sum 43):
(similar to Q#2 except Label: 28868 included in headers & different props)
PROPFIND /repos/svn/!svn/vcc/default
props: baseline-collection,
version-name
A#11 (sum 44):
baseline-collection: /repos/svn/!svn/bc/28868
version-name: 28868
Q#12 (2 packets, sum 46):
PROPFIND /repos/svn/!svn/bc/28868/trunk/BUGS
props: version-controlled-configuration,
resourcetype,
baseline-relative-path,
repository-uuid
TCP overhead bare ACK for Q#12, sum 47
A#12 (sum 48):
version-controlled-configuration: /repos/svn/!svn/vcc/default
resourcetype:
baseline-relative-path: trunk/BUGS
repository-uuid: 65390229-12b7-0310-b90b-f21a5aa7ec8e
TCP overhead bare ACK for A#12, sum 49
Q#13 (2 packets, sum 51): repeat Q#1/Q#4/Q#7/Q#10
TCP overhead bare ACK for Q#13, sum 52
A#13 (sum 53): repeat A#1/A#4/A#7/A#10
Q#14 (2 packets, sum 55): repeat Q#11
A#14 (sum 56): repeat A#11
Q#15 (2 packets, sum 58):
PROPFIND /repos/svn/!svn/bc/28868/trunk/BUGS
props: allprop
A#15 (sum 59): lots of props
TCP overhead bare ACK for A#15, sum 60
Q#16 (2 packets, sum 62): repeat Q#1/Q#4/Q#7/Q#10/Q#13
TCP overhead bare ACK for Q#16, sum 63
A#16 (sum 64): repeat A#1/A#4/A#7/A#10/A#13
Q#17 (2 packets, sum 66): repeat Q#11/Q#14
A#17 (sum 67): repeat A#11/A#14
Q#18 (2 packets, sum 69):
PROPFIND /repos/svn/!svn/bc/28868/trunk/BUGS
props: md5-checksum
A#18 (sum 70):
md5-checksum: b19e94b798412ebf58d233b0a5f96b6d
TCP overhead bare ACK for A#18, sum 71
Q#19 (sum 72):
GET /repos/svn/!svn/bc/28868/trunk/BUGS
A#19 (sum 73): file contents
TCP overhead connection takedown (FIN, FIN+ACK, ACK) -- total 76 packets
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org