Hello, Daniel and all, > In other words, merging changes from file.c@BRANCH to trunk should > detect that file@trunk and file@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.krue...@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...@daniel.shahaf.name] Sent: Saturday, January 15, 2011 1:34 AM To: Johan Corveleyn Cc: krueger, Andreas (Andreas Krüger, DV-RATIO); users@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@BRANCH to trunk should detect that file@trunk and file@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. :-)
