On Fri, Aug 20, 2010 at 9:11 PM, Johan Corveleyn jcor...@gmail.com wrote:
On Fri, Aug 20, 2010 at 1:40 PM, Johan Corveleyn jcor...@gmail.com wrote:
After eliminating antivirus, and running with a release build instead
of a debug build, svn diff is just about on par with GNU diff. So this
On Tue, Aug 17, 2010 at 3:26 PM, Johan Corveleyn jcor...@gmail.com wrote:
Another thing that occurred to me: since most time of the current
blame implementation is spent on diff (svn_diff_file_diff_2), maybe
a quick win could be to simply (?) optimize the diff code? Or write a
specialized
On Fri, Aug 20, 2010 at 1:40 PM, Johan Corveleyn jcor...@gmail.com wrote:
After eliminating antivirus, and running with a release build instead
of a debug build, svn diff is just about on par with GNU diff. So this
eliminates the option of optimizing diff ...
Unless ...
For every diff during
On Thu, Aug 12, 2010 at 5:30 PM, Greg Hudson ghud...@mit.edu wrote:
On Thu, 2010-08-12 at 10:57 -0400, Julian Foad wrote:
I'm wary of embedding any client functionality in the server, but I
guess it's worth considering if it would be that useful. If so, let's
take great care to ensure it's
On Tue, 2010-08-17 at 09:26 -0400, Johan Corveleyn wrote:
Greg, could you explain a bit more what you mean with
edit-stream-style binary diffs, vs. the binary deltas we have now?
Could you perhaps give an example similar to Julian's? Wouldn't you
have the same problem with pieces of the source
On Thu, 2010-08-12, C. Michael Pilato wrote:
In times past, I've wondered if the server couldn't just store line-delta
information -- as a comparison between each FS DAG node and its immediate
predecessor -- similar to the way that CVS does (and in addition to the
stuff it already stores, of
On Thu, 2010-08-12 at 10:57 -0400, Julian Foad wrote:
I'm wary of embedding any client functionality in the server, but I
guess it's worth considering if it would be that useful. If so, let's
take great care to ensure it's only lightly coupled to the core server
logic.
Again, it's possible
On Wed, 2010-08-11, Johan Corveleyn wrote:
Hi all,
Other priorities have unfortunately kept me from focusing on the
project of speeding up blame. But recently I've spent some time
thinking about it, reading the other mail threads, studying the code
and profiling a little bit. I hope I can
On Wed, 2010-08-11 at 19:14 -0400, Johan Corveleyn wrote:
I naively thought that the server, upon being called get_file_revs2,
would just supply the deltas which it has already stored in the
repository. I.e. that the deltas are just the native format in which
the stuff is kept in the back-end
Hi all,
Other priorities have unfortunately kept me from focusing on the
project of speeding up blame. But recently I've spent some time
thinking about it, reading the other mail threads, studying the code
and profiling a little bit. I hope I can still do something useful for
blame, whether it be
Hello Julian,
On Montag, 22. März 2010, Julian Foad wrote:
Hi Philipp. What do you mean exactly? I wonder if you misunderstood
when I said, we read in the blamed file's text (just that one revision
of it). I meant just the working revision of the file (or whichever
revision the blame
On Mon, Mar 22, 2010 at 11:51 AM, Julian Foad julian.f...@wandisco.com wrote:
On Sun, 2010-03-21, Johan Corveleyn wrote:
[ ... ]
(http://subversion.tigris.org/issues/show_bug.cgi?id=3074#desc5):
[[[
My idea for client-side improvement:
The client, while receiving binary diffs for successive
On Mon, Mar 22, 2010 at 12:29 PM, Philipp Marek
philipp.ma...@emerion.com wrote:
Hello Julian,
Hello Johan,
Hi Philipp,
Thanks for joining the discussion. All input is really welcome. Julian
has already responded to your suggestions, but it got me thinking ...
see below.
On Montag, 22. März
On Mon, Mar 22, 2010 at 5:25 PM, Johan Corveleyn jcor...@gmail.com wrote:
However, looking at Julian's binary blame algorithm, I can't help but
wonder why this binary structure couldn't be calculated on the server
just as well. This would save a lot of network roundtrips (5999 in my
case
Hi all,
I'm very much looking forward to the performance (and other)
improvements wc-ng will bring us. But there's more to svn performance
than wc stuff :-). In our company, svn annotate/blame/praise is a
known offender (people who attended subconf 2009 may remember me as
the guy who complained
15 matches
Mail list logo
