Re: Performance of svn+ssh vs. file for multiple files

2010-07-08 Thread Daniel Shahaf
Eric Peers wrote on Thu, 8 Jul 2010 at 20:13 -: > @Les: tags/branches don't work in this case because an edit on this can change > the tag/branch and because the merge of local edits + local version changes > becomes cumbersome (if not impossible) on the svn switch to the branch/tag. > Perforce

Re: Performance of svn+ssh vs. file for multiple files

2010-07-08 Thread Stefan Sperling
On Thu, Jul 08, 2010 at 11:13:12AM -0600, Eric Peers wrote: > I ended up writing a routine that uses the reparent call as > previously discussed with a minor rework of the > svn_client__update_internal to accomodate this. Overall time to > update: 3.09s rather than 53s originally by reusing the ses

Re: Performance of svn+ssh vs. file for multiple files

2010-07-08 Thread Eric Peers
On 07/08/2010 02:27 AM, Daniel Shahaf wrote: Eric Peers wrote on Wed, 7 Jul 2010 at 04:44 -: Incidentally, where is [svn_ra_reparent] defined??? I can't find it in the libraries, but I see it in libsvn_ra-1.so but not in the libsvn_ra directory... % grep svn_ra_reparent tags svn

Re: Performance of svn+ssh vs. file for multiple files

2010-07-08 Thread Daniel Shahaf
Eric Peers wrote on Wed, 7 Jul 2010 at 04:44 -: > Incidentally, where is [svn_ra_reparent] defined??? I can't > find it in the libraries, but I see it in libsvn_ra-1.so but not in the > libsvn_ra directory... % grep svn_ra_reparent tags svn_ra_reparent ./subversion/include/svn_ra.h /^svn_ra

Re: Performance of svn+ssh vs. file for multiple files

2010-07-07 Thread Les Mikesell
On 7/6/2010 8:44 PM, Eric Peers wrote: I do need to update specific files - I basically need to replicate user's workspaces for per-file-per-version (think continuous build automation). Some files are included, others are not. I'm not quite sure why you wouldn't maintain the versions you want

Re: Performance of svn+ssh vs. file for multiple files

2010-07-07 Thread Nico Kadel-Garcia
On Tue, Jul 6, 2010 at 2:17 PM, Eric Peers wrote: > Howdy, > > I've got a program that needs to checkout specific files at specific > versions. In this particular case a branch does not make sense. I have found > that the performance of svn+ssh in this case is very bad. > > I run the rough equival

Re: Performance of svn+ssh vs. file for multiple files

2010-07-06 Thread Eric Peers
On 07/06/2010 06:16 PM, Bert Huijben wrote: -Original Message- From: Eric Peers [mailto:e...@missinglinktools.com] Sent: dinsdag 6 juli 2010 22:46 To: Daniel Shahaf Cc: users@subversion.apache.org Subject: Re: Performance of svn+ssh vs. file for multiple files Good suggestion

Re: Performance of svn+ssh vs. file for multiple files

2010-07-06 Thread Stefan Sperling
On Tue, Jul 06, 2010 at 02:46:11PM -0600, Eric Peers wrote: > svnserve -d --listen-port 8000 > ssh epe...@localhost -L 3690:localhost:8000 > ...then run my svn update commands... You could also try ssh connection multiplexing. >From the ssh(1) man page: -M Places the ssh client into ``

RE: Performance of svn+ssh vs. file for multiple files

2010-07-06 Thread Bert Huijben
> -Original Message- > From: Eric Peers [mailto:e...@missinglinktools.com] > Sent: dinsdag 6 juli 2010 22:46 > To: Daniel Shahaf > Cc: users@subversion.apache.org > Subject: Re: Performance of svn+ssh vs. file for multiple files > > Good suggestion Daniel.

Re: Performance of svn+ssh vs. file for multiple files

2010-07-06 Thread Eric Peers
Good suggestion Daniel. While this does markedly improve performance, it does so at the expense of changing the underlying protocol. Unfortunately, I'm not at liberty to change the underlying protocol - I have customers that define the protocol, I don't. So my "program" needs to access their re

Re: Performance of svn+ssh vs. file for multiple files

2010-07-06 Thread Daniel Shahaf
Have you tried using SSH port forwarding instead of svn+ssh://? Daniel (perhaps one of the other devs will address the points you made; I'm myself not familiar with that part of the code) Eric Peers wrote on Tue, 6 Jul 2010 at 21:17 -: > Howdy, > > I've got a program that needs to checkout