Re: gzip compression (was: Re: Logging Subversion client HTTP requests)

Hello, on 08/01/2011 04:55 AM ehu...@gmail.com said the following: Please note that many of the responses subversoin sends are already compressed as binary difference streams against the previous version. Gzip compression on REPORT responses isn't going to yield an average factor 5 compression r

Re: Logging Subversion client HTTP requests

Hello, on 08/01/2011 05:23 AM Andreas Krey said the following: On Mon, 01 Aug 2011 04:20:07 +, Manuel Lemos wrote: ... Been there, tried that, but wireshark does not decrypt SSL traffic unless you have the server SSL key, which is not the case because the server is not under my control. Y

Re: gzip compression

Hello, on 08/01/2011 04:43 AM Ryan Schmidt said the following: >> Anyway, another odd thing is that the client always sends a request >> header saying it can handle HTTP compression but SubVersion servers >> seem to never compress responses. >> >> Given than a typical gzip encoding can compress t

Re: Logging Subversion client HTTP requests

on 08/01/2011 05:31 AM Andreas Krey said the following: Anyway, in my implementation I did not do any repeated requests and I can retrieve the information I want apparently much faster in PHP than using the svn program. So I wonder if could be missing anything. It *may* be another opportunity

Re: AW: Logging Subversion client HTTP requests

on 08/01/2011 09:55 AM Les Mikesell said the following: On 8/1/11 2:37 AM, Manuel Lemos wrote: As I mentioned before, I needed to see traffic to SSL servers, which you cannot see with Wireshark unless you have the server private SSL key, which is not the case. Thanks for the tip anyway. If

Re: Releasing an open source subversion client

On Aug 5, 2011, at 01:47, Rajith Chathunga wrote: > I'm Rajith Chathunga from university of Moratuwa, Sri Lanka. My team is > developing an open source Subversion client as our internship project. It > will be a great help that you can provide us some directions to release it. > What is the pro

Re: 1.7 'svn upgrade' issue on windows vista

>> The problem was that the svn upgrade command is case sensitive on the WC >> folder name and failed if the >> name doesn't match exactly. Windows itself is case insensitive and none of >> the other svn commands are >> case sensitive to the WC folder name. > >That is correct. The Subversion clie

Estimation of repository upgrade

I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17. We have 75 repositories, with an average size of 30MB. They're not big, I agree, but I wonder if anyone has any tip on how to estimate how long the "svnadmin upgrade" command will take. I mean, will it be a matter or minutes or

RE: 1.7 'svn upgrade' issue on windows vista

> -Original Message- > From: Stephen Meechan [mailto:s...@smeechan.co.uk] > Sent: vrijdag 5 augustus 2011 1:04 > To: users@subversion.apache.org > Subject: 1.7 'svn upgrade' issue on windows vista > > While testing out the svn upgrade feature in 1.7 beta 2, on some working > copies the u

Re: Releasing an open source subversion client

On Fri, Aug 5, 2011 at 6:05 AM, Ryan Schmidt wrote: > On Aug 5, 2011, at 01:47, Rajith Chathunga wrote: > >> I'm Rajith Chathunga from university of Moratuwa, Sri Lanka. My team is >> developing an open source Subversion client as our internship project. It >> will be a great help that you can p

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 07:09, Giulio Troccoli wrote: > I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17. > > We have 75 repositories, with an average size of 30MB. They're not big, I > agree, but I wonder if anyone has any tip on how to estimate how long the > "svnadmin upgrade" co

Re: 1.7 'svn upgrade' issue on windows vista

thanks Bert, I'll continue with some more testing, with a much faster svn update on large working copies this release looks like a very worthwhile upgrade. - Original Message - From: "Bert Huijben" To: "Stephen Meechan" , users@subversion.apache.org Sent: Friday, 5 August, 2011 12:32:41

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli < giulio.trocc...@mediatelgroup.co.uk> wrote: > I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17. > > We have 75 repositories, with an average size of 30MB. They're not big, I > agree, but I wonder if anyone has any tip on how to esti

RE: Releasing an open source subversion client

> Hi Subversion, > > I'm Rajith Chathunga from university of Moratuwa, Sri Lanka. My team is > developing an open source Subversion client as our internship project. It will > be a great help that you can provide us some directions to release it. What is > the procedure that we should follow to re

Re: Estimation of repository upgrade

On 05/08/11 14:18, Mark Phippard wrote: On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli > wrote: I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17. We have 75 repositories, with an average size of 30MB. They're not big, I

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 10:11, Giulio Troccoli wrote: > > > On 05/08/11 14:18, Mark Phippard wrote: >> >> On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli >> > > wrote: >> >>    I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17. >> >>    We

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 10:11 AM, Giulio Troccoli < giulio.trocc...@mediatelgroup.co.uk> wrote: > > > On 05/08/11 14:18, Mark Phippard wrote: > > On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli > mediatelgroup.co.uk > giulio.troccoli@**mediatelgroup.co.uk>> >> wrote: >> >>I'm working on a pla

RE: Estimation of repository upgrade

> On Fri, Aug 5, 2011 at 10:11 AM, Giulio Troccoli > wrote: > > > On 05/08/11 14:18, Mark Phippard wrote: > > On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli > > wrote: > >    I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17. > >  

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer wrote: > Has anything been done to improve the speed of a load. Last time I did it, > when moving from 1.5 to 1.6 it took over 12 hours. And now, two years later > the repo is probably quite a bit bigger (because we stupidly store binaries > in it, I

Re: Estimation of repository upgrade

On 05/08/11 17:11, Nico Kadel-Garcia wrote: On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer wrote: Has anything been done to improve the speed of a load. Last time I did it, when moving from 1.5 to 1.6 it took over 12 hours. And now, two years later the repo is probably quite a bit bigger (bec

RE: Estimation of repository upgrade

> On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer wrote: > > > Has anything been done to improve the speed of a load. Last time I did it, > when moving from 1.5 to 1.6 it took over 12 hours. And now, two years later > the repo is probably quite a bit bigger (because we stupidly store binaries in > it

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 12:19 PM, Bob Archer wrote: >> On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer wrote: >> >> > Has anything been done to improve the speed of a load. Last time I did it, >> when moving from 1.5 to 1.6 it took over 12 hours. And now, two years later >> the repo is probably quite

RE: Estimation of repository upgrade

> On Fri, Aug 5, 2011 at 12:19 PM, Bob Archer wrote: > >> On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer > wrote: > >> > >> > Has anything been done to improve the speed of a load. Last time I > >> > did it, > >> when moving from 1.5 to 1.6 it took over 12 hours. And now, two years > >> later the re

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer wrote: > > Until you manually copy over the $repodir/db/uuid file, this is true. > > That's one of the "relevant configuraton files" I referred to. > > So, are you saying svnsync will be faster than a dump/load? > > I didn't know the guid was stored in

RE: Estimation of repository upgrade

> On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer wrote: > > > Until you manually copy over the $repodir/db/uuid file, this is true. > > That's one of the "relevant configuraton files" I referred to. > So, are you saying svnsync will be faster than a dump/load? > > I didn't know the guid was stored i

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 1:27 PM, Mark Phippard wrote: > On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer wrote: > >> >> > Until you manually copy over the $repodir/db/uuid file, this is true. >> > That's one of the "relevant configuraton files" I referred to. >> >> So, are you saying svnsync will be fas

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard wrote: > On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer wrote: > > >> > Until you manually copy over the $repodir/db/uuid file, this is true. >> > That's one of the "relevant configuraton files" I referred to. >> >> So, are you saying svnsync will be fas

Re: Estimation of repository upgrade

On 8/5/2011 12:27 PM, Mark Phippard wrote: > Until you manually copy over the $repodir/db/uuid file, this is true. > That's one of the "relevant configuraton files" I referred to. So, are you saying svnsync will be faster than a dump/load? I didn't know the guid was stored in

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 7:52 PM, Les Mikesell wrote: > On 8/5/2011 12:27 PM, Mark Phippard wrote: > >> >> > Until you manually copy over the $repodir/db/uuid file, this is >> true. >> > That's one of the "relevant configuraton files" I referred to. >> >>So, are you saying svnsync will

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 1:52 PM, Les Mikesell wrote: > On 8/5/2011 12:27 PM, Mark Phippard wrote: > >> >> > Until you manually copy over the $repodir/db/uuid file, this is >> true. >> > That's one of the "relevant configuraton files" I referred to. >> >>So, are you saying svnsync will

Re: Estimation of repository upgrade

On 8/5/2011 12:33 PM, Bob Archer wrote: Until you manually copy over the $repodir/db/uuid file, this is true. That's one of the "relevant configuraton files" I referred to. So, are you saying svnsync will be faster than a dump/load? I didn't know the guid was stored in a file. svnsync is slo

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 1:51 PM, Erik Huelsmann wrote: > > On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard wrote: > >> On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer wrote: >> >> >>> > Until you manually copy over the $repodir/db/uuid file, this is true. >>> > That's one of the "relevant configuraton

RE: Estimation of repository upgrade

> On Fri, Aug 5, 2011 at 1:51 PM, Erik Huelsmann wrote: > > On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard > wrote: > On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer wrote: > > > Until you manually copy over the $repodir/db/uuid file, this is true. > > That's one of the "relevant configuraton files"

Re: Estimation of repository upgrade

On Fri, Aug 5, 2011 at 2:12 PM, Bob Archer wrote: > > On Fri, Aug 5, 2011 at 1:51 PM, Erik Huelsmann wrote: > > > > On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard > > wrote: > > On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer wrote: > > > > > Until you manually copy over the $repodir/db/uuid file, t

Re: RE: Releasing an open source subversion client

perhaps they are writing a new java client under a more friendly license than svnkit... otherwise yeah i agree that it smells like a complete waste of time and effort. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct resu

Re: UNS: Re: Logging Subversion client HTTP requests

On Fri, 05 Aug 2011 05:15:24 +, Manuel Lemos wrote: ... > > ssh -L 4080:svnhost:80 wellconnected.host > > svn checkout http://localhost:4080/path/to/repo > > I see but that compression only happens inside your ssh tunnel. I am > sure a direct connection with gzip/deflate compression would