Hello, Daniel and all,
> In other words, merging changes from file.c_at_BRANCH to trunk should
> detect that file_at_trunk and file_at_BRANCH@BRANCH-CREATION are the same
> node-revision?
I think that my intended optimization should work in this case.
But I don't think that's the condition I mean.
It does not feel general enough.
But then, I also don't think this has to be discussed in the context
of this optimization proposal. After all, there is some condition
already implemented. SVN already knows how to check
whether a merge is possible or not in the binary case.
That condition IS what I want.
If a binary merge would be possible, be fast and do the binary merge
and don't bother with text diffs.
> but giving the question more
> visibility (as opposed to burying it in the middle of a paragraph on
> users@) might help you get an answer. :-)
Thanks for the hint!
I'd be more than willing to convert this to an issue at
http://subversion.tigris.org/issues .
Writing a self-contained script that demonstrates the performance
problem (starting with the creation of a scratch SVN repository) -
would that be a good next step?
Regards, Andreas
--
Dr. Andreas Krüger, Senior Developer
Tel. (+49) (211) 280 69-1132
andreas.krueger_at_hp.com
DV-RATIO NORDWEST GmbH, Habsburgerstraße 12, 40547 Düsseldorf, Germany
für
Hewlett-Packard GmbH H Herrenberger Str. 140 71034 Böblingen www.hp.com/de
Geschäftsführer: Volker Smid (Vorsitzender), Michael Eberhardt, Thorsten Herrmann,
Martin Kinne, Heiko Meyer, Ernst Reichart, Rainer Sterk
Vorsitzender des Aufsichtsrates: Jörg Menno Harms
Sitz der Gesellschaft: Böblingen S Amtsgericht Stuttgart HRB 244081 WEEE-Reg.-Nr. DE 30409072
-----Original Message-----
From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
Sent: Saturday, January 15, 2011 1:34 AM
To: Johan Corveleyn
Cc: krueger, Andreas (Andreas Krüger, DV-RATIO); users_at_subversion.apache.org
Subject: Re: Trival merge of big text file: Dismal performance, 540x faster if binary.
Johan Corveleyn wrote on Fri, Jan 14, 2011 at 23:52:10 +0100:
> Ok, after rereading this thread, I'm starting to understand what you
> mean: why would "merge" perform an expensive diffing algorithm while
> it can just be 100% sure that it can simply copy the contents from the
> source to the target (because the target file has not had any changes
> since it was branched)?
>
> I think it's a good suggestion, but I can't really comment more on
> (the feasibility of) it, because I'm not that familiar with that part
> of the codebase. I've only concentrated on the diff algorithm itself
> (and how it's used by "svn diff" and "svn merge" (for text files)).
> Maybe someone else can chime in to comment on that?
In other words, merging changes from file.c_at_BRANCH to trunk should
detect that file_at_trunk and file_at_BRANCH@BRANCH-CREATION are the same
node-revision?
I don't know whether it does that... but giving the question more
visibility (as opposed to burying it in the middle of a paragraph on
users@) might help you get an answer. :-)
Received on 2011-01-17 17:31:56 CET