Re: [PATCH] Speed-up of libsvn_diff using token counts

On Mon, May 30, 2011 at 8:50 PM, Morten Kloster wrote: > Johan, any progress on reviewing the code on your part? Things are > a bit simpler now with the idx patch in: Since that patch settled the > file (re)order issue, this patch now produces fully identical results to > HEAD. Thanks for the upd

Re: [PATCH] Speed-up of libsvn_diff using token counts

On Mon, May 30, 2011 at 12:26 PM, Stefan Sperling wrote: > On Mon, May 30, 2011 at 08:25:38AM +0200, Markus Schaber wrote: >> Hi, Morten, >> >> > Von: Morten Kloster [mailto:mor...@gmail.com] >> >> > I haven't changed the index/count types yet. What's the right type to use >> > to get signed 32 bi

RE: [bug 3740] Change of default behaviour

On Mon, 2011-05-30 at 18:47 +0200, Bert Huijben wrote: > The Squid problem is (if I remember correctly) a serf issue and this patch > is neon specific. > > I think we should implement this support for both ra dav layers, while > keeping our normal per server overrides working. > This actually so

RE: [bug 3740] Change of default behaviour

> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: maandag 30 mei 2011 16:24 > To: Dimstar / Dominique Leuenberger > Cc: dev@subversion.apache.org > Subject: Re: [bug 3740] Change of default behaviour > > On Mon, May 30, 2011 at 03:22:57PM +0200, Dimstar / Dominiqu

Re: svn client with ssh: data loss in output when both stdout and stderr are redirected to a pipe

On 2011-05-30 16:27:04 +0200, Stefan Sperling wrote: > please feel free to file an issue on this bug. OK: http://subversion.tigris.org/issues/show_bug.cgi?id=3906 -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR

Re: svn client with ssh: data loss in output when both stdout and stderr are redirected to a pipe

On Mon, May 30, 2011 at 04:20:29PM +0200, Vincent Lefevre wrote: > In my bug report above, there should be no broken pipe or any > other error (as long as one uses "less" + [End] key, or some > command like wc, which reads the full input stream). It occurs > only when stderr is redirected to stdout

Re: [bug 3740] Change of default behaviour

On Mon, May 30, 2011 at 03:22:57PM +0200, Dimstar / Dominique Leuenberger wrote: > Now of course I do understand that this patch does bring a change in the > default behavior of svn: so far, we simply ignored system settings and > let the user crawl through a documentation, finding on how to enable

Re: svn client with ssh: data loss in output when both stdout and stderr are redirected to a pipe

On 2011-05-30 09:58:45 -0400, Mark Phippard wrote: > 2011/5/30 Vincent Lefevre : > > I've found the following bug with Subversion 1.6.16: > > > >  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627025 > > > > The problem is: With the svn+ssh scheme, a ssh process is started and > > sets its stder

Re: issue 3899 (copying conflict victims)

On May 27, 2011, at 15:23 , Julian Foad wrote: > > To start simply, I consider a file rather than a directory, on update. > The only relevant tree conflicts are those involving a local file that > exists (because we're talking about copying or moving it), so that's > delete-onto-edited or add-on

Re: svn client with ssh: data loss in output when both stdout and stderr are redirected to a pipe

2011/5/30 Vincent Lefevre : > I've found the following bug with Subversion 1.6.16: > >  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627025 > > The problem is: With the svn+ssh scheme, a ssh process is started and > sets its stderr to non-blocking mode. When executing an API-based svn > client

svn client with ssh: data loss in output when both stdout and stderr are redirected to a pipe

I've found the following bug with Subversion 1.6.16: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627025 The problem is: With the svn+ssh scheme, a ssh process is started and sets its stderr to non-blocking mode. When executing an API-based svn client with both stdout and stderr redirected

[bug 3740] Change of default behaviour

Hi SVN Devs, A while back, I proposed a patch that would make svn transparently use proxy as configured in the session, by relying on ne_neon_system_proxy (which, in turn, uses libproxy in the background). The advantage of this is of course mainly for notebook users / users changing location ever

Re: Bug in exporting externals?

"Bert Huijben" writes: >> -Original Message- >> From: Noorul Islam K M [mailto:noo...@collab.net] >> Sent: maandag 30 mei 2011 12:17 >> To: Subversion >> Subject: Bug in exporting externals? >> >> >> While working on issue 3799, in one of the review comments julianf said >> the followin

Re: possible improvement to svn log with "forward" revision range

For 'svn log -rX:Y PATH@PEG, where Y> PEG, don't croak when PATH@Y doesn't exist. Instead, automatically substitute for Y the last revision in which PATH@THAT-REV *did* exist, and continue the operation. I believe this is something that we can reasonably achieve without too much trouble and, more

RE: Bug in exporting externals?

> -Original Message- > From: Noorul Islam K M [mailto:noo...@collab.net] > Sent: maandag 30 mei 2011 12:17 > To: Subversion > Subject: Bug in exporting externals? > > > While working on issue 3799, in one of the review comments julianf said > the following about number 10 test in extern

Re: [PATCH] Speed-up of libsvn_diff using token counts

On Mon, May 30, 2011 at 08:25:38AM +0200, Markus Schaber wrote: > Hi, Morten, > > > Von: Morten Kloster [mailto:mor...@gmail.com] > > > I haven't changed the index/count types yet. What's the right type to use > > to get signed 32 bit on 32-bit machines and signed 64 bit on 64-bit > > machines? >

Bug in exporting externals?

While working on issue 3799, in one of the review comments julianf said the following about number 10 test in external_tests.py. A/B/gamma is only an external: it does not appear in the WC until Subversion processes the external definitions. It looks to me like that failure was showing us a bug

Re: [PATCH] Speed-up of libsvn_diff using token counts

On 29.05.2011 20:02, Morten Kloster wrote: > Bert informed me that intptr_t might not be work on all systems, so I've > made a new typedef svn_diff__token_index_t and set it to long int for now. You could try apr_uintptr_t. -- Brane