[l10n] Translation status report for trunk r1053795
Translation status report for tr...@r1053795 lang trans untrans fuzzy obs -- de2041 122 227 199 es1978 185 261 338 fr2128 35 60 41 it1827 336 460 162 ja1970 193 332 584 ko2016 147 176 179 nb2031 132 185 307 pl2063 100 134 82 pt_BR1792 371 478 157 sv1748 415 502 163 zh_CN2159 4 36 88 zh_TW1728 435 540 225
[PATCH] make diff against copy-source by default
Hi all,
This patch is a follow up to the patch that I gave last month
(November).
Here is the link to the mail archive...
http://mail-archives.apache.org/mod_mbox/subversion-dev/201011.mbox/%
3c1291110994.4021.66.ca...@prabhugnanasundar%3e
After a few discussions about the inconsistent behaviour of 'svn diff'
in different scenarios, Kamesh suggested that let 'svn diff' be done
against the copy-source by default, making use of the copyfrom info.
Now this patch would do 'diff' against the copy-source by default,
whereas the prevailing default behaviour(of showing a *modified copy* as
all adds) can be achieved by using the '--show-copies-as-adds'
switch(that already exists in the code-base!).
I was quickly in to it and after spending some time in the process I
came to know that several existing 'test cases' *failed* due to the
change in the behaviour of the 'svn diff'. Later found that the 'wc
editor' needs to be taught to handle this behaviour (handling the
copyfrom info and retrieving it from the repository as against working
copy text-base).
This took quite some amount of time...
See [1] below of the mailer.py usecase which tries to get the same
output as my patch do.
May be that's the behaviour of the 'diff' that is prefered ? :)
I have attached the patch and the log message with this mail. Please
review and respond.
[1]
I found the following usecase which is already doing the same as what my
patch intends to do.
The mailer.py script has the same behaviour of 'diff'ing just as this
patch does.
http://mail-archives.apache.org/mod_mbox/subversion-commits/201012.mbox/%3c20101228204459.1e42d2388...@eris.apache.org%3e
snip from the above commit email
Copied:
subversion/branches/1.6.x-svn_fs_commit_txn/subversion/include/private/svn_repos_private.h
(from r1051763,
subversion/trunk/subversion/include/private/svn_repos_private.h)
URL:
http://svn.apache.org/viewvc/subversion/branches/1.6.x-svn_fs_commit_txn/subversion/include/private/svn_repos_private.h?p2=subversion/branches/1.6.x-svn_fs_commit_txn/subversion/include/private/svn_repos_private.hp1=subversion/trunk/subversion/include/private/svn_repos_private.hr1=1051763r2=1053428rev=1053428view=diff
==
--- subversion/trunk/subversion/include/private/svn_repos_private.h
(original)
+++
subversion/branches/1.6.x-svn_fs_commit_txn/subversion/include/private/svn_repos_private.h
Tue Dec 28 20:44:58 2010
@@ -38,53 +38,6 @@ extern C {
/**
- * Permanently delete @a path at revision @a revision in @a fs.
- *
- * Do not change the content of any other node in the repository, even
other
- * nodes that were copied from this one. The only other change in the
- * repository is to copied from pointers that were pointing to the
- * now-deleted node. These are removed or made to point to a previous
- * version of the now-deleted node.
- * (### TODO: details.)
- *
- * @a path is relative to the repository root and must start with /.
- *
- * If administratively forbidden, return @c SVN_ERR_RA_NOT_AUTHORIZED.
If not
- * implemented by the RA layer or by the server, return
- * @c SVN_ERR_RA_NOT_IMPLEMENTED.
- *
- * @note This functionality is not implemented in pre-1.7 servers and
may not
- * be implemented in all 1.7 and later servers.
- *
- * @note TODO: Maybe create svn_repos_fs_begin_obliteration_txn() and
- * svn_repos_fs_commit_obliteration_txn() to enable an obliteration txn
to be
- * constructed at a higher level.
- *
- * @since New in 1.7.
- */
-svn_error_t *
-svn_repos__obliterate_path_rev(svn_repos_t *repos,
- const char *username,
- svn_revnum_t revision,
- const char *path,
- apr_pool_t *pool);
-
-
-/** Validate that property @a name is valid for use in a Subversion
- * repository; return @c SVN_ERR_REPOS_BAD_ARGS if it isn't. For some
- * svn: properties, also validate the @a value, and return
- * @c SVN_ERR_BAD_PROPERTY_VALUE if it is not valid.
- *
- * Use @a pool for temporary allocations.
- *
- * @since New in 1.7.
- */
-svn_error_t *
-svn_repos__validate_prop(const char *name,
- const svn_string_t *value,
- apr_pool_t *pool);
-
-/**
* Given the error @a err from svn_repos_fs_commit_txn(), return an
* string containing either or both of the svn_fs_commit_txn() error
* and the SVN_ERR_REPOS_POST_COMMIT_HOOK_FAILED wrapped error from
/snip
Thanks and regards
Prabhu
Index: build.conf
===
--- build.conf (revision 1053833)
+++ build.conf (working copy)
@@ -336,7 +336,7 @@
description = Subversion Working Copy Library
type = lib
path = subversion/libsvn_wc
-libs = libsvn_delta libsvn_diff libsvn_subr aprutil apriconv apr
+libs = libsvn_ra libsvn_delta libsvn_diff libsvn_subr aprutil apriconv apr
install = lib
msvc-export = svn_wc.h private\svn_wc_private.h
Index: subversion/libsvn_ra/deprecated.c
===
--- subversion/libsvn_ra/deprecated.c
svn upgrade segfaults
Hi All, I did the following. cd /tmp cd svn-1.6 co file:///repo/abc touch abc/test svn-1.6 add abc/test #Make sure below commit fails either by a pre-commit hook or File system perm error, we just need this to fail. svn-1.6 ci -m msg svn-1.7 upgrade Segfaults My svn-1.7 trunk build corresponds to 1053813:1053833 With regards Kamesh Jayachandran
Re: [l10n] Translation status report for trunk r1053795
For the interested, this is the output of tools/po/l10n-report.py. I've set it up as a weekly cron job, emailing the results to d...@. -Hyrum On Wed, Dec 29, 2010 at 11:20 PM, SVN DEV nore...@subversion.apache.org wrote: Translation status report for tr...@r1053795 lang trans untrans fuzzy obs -- de 2041 122 227 199 es 1978 185 261 338 fr 2128 35 60 41 it 1827 336 460 162 ja 1970 193 332 584 ko 2016 147 176 179 nb 2031 132 185 307 pl 2063 100 134 82 pt_BR 1792 371 478 157 sv 1748 415 502 163 zh_CN 2159 4 36 88 zh_TW 1728 435 540 225
Re: [Issue 3770] New - JavaHL method to set binary property is broken
On Wed, Dec 29, 2010 at 4:43 PM, markp...@tigris.org wrote:
http://subversion.tigris.org/issues/show_bug.cgi?id=3770
Issue #|3770
Summary|JavaHL method to set binary property is broken
Component|subversion
Version|1.6.x
Platform|Macintosh
URL|
OS/Version|All
Status|NEW
Status whiteboard|
Keywords|
Resolution|
Issue type|DEFECT
Priority|P2
Subcomponent|bindings_javahl
Assigned to|iss...@subversion
Reported by|markphip
--- Additional comments from markp...@tigris.org Wed Dec 29 13:43:28
-0800 2010 ---
JavaHL has a method to set a property using a byte array. This method
existed so that binary
properties, such as an image thumbnail can be set on a file. If you go back
to the source for SVN 1.2,
this went direct to a native method. Somewhere along the way (probably in
1.5 release) as new method
signatures were added and we sought to reuse those methods we broke this
function. Look at the
current SVN 1.6.x implementation:
/**
* @deprecated Use {...@link #propertySet(String, String, String, int,
* String[], boolean, Map)} instead.
* @since 1.2
*/
public void propertySet(String path, String name, byte[] value,
boolean recurse, boolean force)
throws ClientException
{
propertySet(path, name, new String(value), recurse, force);
}
The incoming byte[] is converted to a String and the common method for using
a String is used. This
causes binary values to be corrupted. I think we need to add a native method
back to the JavaHL library
which receives a pure byte array.
Mark,
Daniel pointed out on IRC that all the revpropTable arguments in the
JavaHL API are MapString, String. Should they be adjusted to
MapString, byte[] ?
-Hyrum
Re: svn commit: r1053915 - in /subversion/trunk/subversion/bindings/javahl: native/ src/org/apache/subversion/javahl/
On 12/30/10 7:24 AM, hwri...@apache.org wrote:
Author: hwright
Date: Thu Dec 30 15:24:02 2010
New Revision: 1053915
URL: http://svn.apache.org/viewvc?rev=1053915view=rev
Log:
Address issue #3670 by providing a byte-array interface for property
setting and creation in JavaHL. This does not include a test (I'm hoping
the bug reporter can provide one).
This introduces overloaded versions of the propertySet() and propertyCreate()
APIs. I'm tempted to remove the originals, but didn't want to update the
tests in this commit.
[ in subversion/bindings/javahl/ ]
* native/SVNClient.h,
native/SVNClient.cpp
(propertySet): Use a byte array in place of a string to constuct the C-API
inputs.
* native/org_apache_subversion_javahl_SVNClient.cpp
(Java_org_apache_subversion_javahl_SVNClient_propertySet): Take a byte array
as input.
* src/org/apache/subversion/javahl/SVNClient.java
(propertySet, propertyCreate): Introduce versions of these APIs which take
byte[] values.
* src/org/apache/subversion/javahl/ISVNClient.java:
(propertySet, propertyCreate): Same.
Modified:
subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp
subversion/trunk/subversion/bindings/javahl/native/SVNClient.h
subversion/trunk/subversion/bindings/javahl/native/org_apache_subversion_javahl_SVNClient.cpp
subversion/trunk/subversion/bindings/javahl/src/org/apache/subversion/javahl/ISVNClient.java
subversion/trunk/subversion/bindings/javahl/src/org/apache/subversion/javahl/SVNClient.java
Modified: subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp?rev=1053915r1=1053914r2=1053915view=diff
==
--- subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp (original)
+++ subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp Thu Dec 30
15:24:02 2010
@@ -870,7 +870,7 @@ void SVNClient::properties(const char *p
}
void SVNClient::propertySet(const char *path, const char *name,
-const char *value, svn_depth_t depth,
+JNIByteArrayvalue, svn_depth_t depth,
StringArraychangelists, bool force,
RevpropTablerevprops, CommitCallback *callback)
{
@@ -879,10 +879,11 @@ void SVNClient::propertySet(const char *
SVN_JNI_NULL_PTR_EX(name, name, );
svn_string_t *val;
-if (value == NULL)
+if (value.isNull())
val = NULL;
else
- val = svn_string_create(value, requestPool.pool());
+ val = svn_string_ncreate((const char *)value.getBytes(),
value.getLength(),
Should this be value.getBytes(UTF-8)?
+public void propertySet(String path, String name, String value,
+Depth depth, CollectionString changelists,
+boolean force,
+MapString, String revpropTable,
+CommitCallback callback)
+throws ClientException
+{
+propertySet(path, name, value != null ? value.getBytes() : null,
+depth, changelists, force, revpropTable, callback);
And here?
According to the Java docs:
Encodes this String into a sequence of bytes using the platform's default
charset, storing the result into a new byte array. The platform's default
may not be UTF-8.
Blair
Re: svn commit: r1053932 - /subversion/trunk/subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java
On 12/30/10 8:33 AM, markp...@apache.org wrote:
Author: markphip
Date: Thu Dec 30 16:32:59 2010
New Revision: 1053932
URL: http://svn.apache.org/viewvc?rev=1053932view=rev
Log:
JavaHL: Followup to r1053915.
Update the properties test to set and get a property with binary data.
* subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java
(testBasicProperties): Set the property value with binary data instead of a
String
Also update other caller in same test to use the new Byte[] method with a
String
wc.setItemPropStatus(iota, Status.Kind.modified);
thisTest.checkStatus();
@@ -705,7 +708,8 @@ public class BasicTests extends SVNTests
itemPath = fileToSVNPath(new File(thisTest.getWCPath(),
/A/B/E/alpha),
false);
-client.propertyCreate(itemPath, cqcq, qrz, Depth.empty, null,
+String alphaVal = qrz;
+client.propertyCreate(itemPath, cqcq, alphaVal.getBytes(),
Depth.empty, null,
Do you need to pass UTF-8 to alphaVal.getBytes?
false, null);
final MapString, MapString, byte[] propMaps =
@@ -719,7 +723,7 @@ public class BasicTests extends SVNTests
for (String key : propMap.keySet())
{
assertEquals(cqcq, key);
-assertEquals(qrz, new String(propMap.get(key)));
+assertEquals(alphaVal, new String(propMap.get(key)));
And here to the String constructor?
Blair
Re: svn commit: r1053915 - in /subversion/trunk/subversion/bindings/javahl: native/ src/org/apache/subversion/javahl/
On Thu, Dec 30, 2010 at 2:18 PM, Blair Zajac bl...@orcaware.com wrote:
On 12/30/10 7:24 AM, hwri...@apache.org wrote:
Author: hwright
Date: Thu Dec 30 15:24:02 2010
New Revision: 1053915
URL: http://svn.apache.org/viewvc?rev=1053915view=rev
Log:
Address issue #3670 by providing a byte-array interface for property
setting and creation in JavaHL. This does not include a test (I'm hoping
the bug reporter can provide one).
This introduces overloaded versions of the propertySet() and
propertyCreate()
APIs. I'm tempted to remove the originals, but didn't want to update the
tests in this commit.
[ in subversion/bindings/javahl/ ]
* native/SVNClient.h,
native/SVNClient.cpp
(propertySet): Use a byte array in place of a string to constuct the
C-API
inputs.
* native/org_apache_subversion_javahl_SVNClient.cpp
(Java_org_apache_subversion_javahl_SVNClient_propertySet): Take a byte
array
as input.
* src/org/apache/subversion/javahl/SVNClient.java
(propertySet, propertyCreate): Introduce versions of these APIs which
take
byte[] values.
* src/org/apache/subversion/javahl/ISVNClient.java:
(propertySet, propertyCreate): Same.
Modified:
subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp
subversion/trunk/subversion/bindings/javahl/native/SVNClient.h
subversion/trunk/subversion/bindings/javahl/native/org_apache_subversion_javahl_SVNClient.cpp
subversion/trunk/subversion/bindings/javahl/src/org/apache/subversion/javahl/ISVNClient.java
subversion/trunk/subversion/bindings/javahl/src/org/apache/subversion/javahl/SVNClient.java
Modified: subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp?rev=1053915r1=1053914r2=1053915view=diff
==
--- subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp
(original)
+++ subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp Thu
Dec 30 15:24:02 2010
@@ -870,7 +870,7 @@ void SVNClient::properties(const char *p
}
void SVNClient::propertySet(const char *path, const char *name,
- const char *value, svn_depth_t depth,
+ JNIByteArrayvalue, svn_depth_t depth,
StringArraychangelists, bool force,
RevpropTablerevprops, CommitCallback
*callback)
{
@@ -879,10 +879,11 @@ void SVNClient::propertySet(const char *
SVN_JNI_NULL_PTR_EX(name, name, );
svn_string_t *val;
- if (value == NULL)
+ if (value.isNull())
val = NULL;
else
- val = svn_string_create(value, requestPool.pool());
+ val = svn_string_ncreate((const char *)value.getBytes(),
value.getLength(),
Should this be value.getBytes(UTF-8)?
+ public void propertySet(String path, String name, String value,
+ Depth depth, CollectionString changelists,
+ boolean force,
+ MapString, String revpropTable,
+ CommitCallback callback)
+ throws ClientException
+ {
+ propertySet(path, name, value != null ? value.getBytes() : null,
+ depth, changelists, force, revpropTable, callback);
And here?
According to the Java docs:
Encodes this String into a sequence of bytes using the platform's default
charset, storing the result into a new byte array. The platform's
default may not be UTF-8.
Thanks for the review, but both of these instances have been removed
in subsequent commits.
-Hyrum
Re: svn commit: r1053915 - in /subversion/trunk/subversion/bindings/javahl: native/ src/org/apache/subversion/javahl/
On 12/30/10 11:25 AM, Hyrum Wright wrote: On Thu, Dec 30, 2010 at 2:18 PM, Blair Zajacbl...@orcaware.com wrote: On 12/30/10 7:24 AM, hwri...@apache.org wrote: Author: hwright Date: Thu Dec 30 15:24:02 2010 New Revision: 1053915 URL: http://svn.apache.org/viewvc?rev=1053915view=rev Log: Address issue #3670 by providing a byte-array interface for property setting and creation in JavaHL. This does not include a test (I'm hoping the bug reporter can provide one) According to the Java docs: Encodes this String into a sequence of bytes using the platform's default charset, storing the result into a new byte array. The platform's default may not be UTF-8. Thanks for the review, but both of these instances have been removed in subsequent commits. Thanks, I see that. Blair
Re: svn commit: r1053932 - /subversion/trunk/subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java
On Thu, Dec 30, 2010 at 2:24 PM, Blair Zajac bl...@orcaware.com wrote: - client.propertyCreate(itemPath, cqcq, qrz, Depth.empty, null, + String alphaVal = qrz; + client.propertyCreate(itemPath, cqcq, alphaVal.getBytes(), Depth.empty, null, Do you need to pass UTF-8 to alphaVal.getBytes? Don't know. Do I? Tests pass. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: [Issue 3770] New - JavaHL method to set binary property is broken
On Thu, Dec 30, 2010 at 2:17 PM, Hyrum K Wright hy...@hyrumwright.org wrote: Mark, Daniel pointed out on IRC that all the revpropTable arguments in the JavaHL API are MapString, String. Should they be adjusted to MapString, byte[] ? What is the rule for revision properties? I thought they had to be UTF-8 strings, in which case the Java String class seems more appropriate than using Byte[] which would imply the user can assign binary values to the property. If Revision properties can contain binary values, then yes we should not be using String here. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: [Issue 3770] New - JavaHL method to set binary property is broken
On Thu, Dec 30, 2010 at 2:57 PM, Mark Phippard markp...@gmail.com wrote: On Thu, Dec 30, 2010 at 2:17 PM, Hyrum K Wright hy...@hyrumwright.org wrote: Mark, Daniel pointed out on IRC that all the revpropTable arguments in the JavaHL API are MapString, String. Should they be adjusted to MapString, byte[] ? What is the rule for revision properties? I thought they had to be UTF-8 strings, in which case the Java String class seems more appropriate than using Byte[] which would imply the user can assign binary values to the property. If Revision properties can contain binary values, then yes we should not be using String here. I don't remember what the repository enforces, but the underlying API contains a hash of const char * revprop names, with values of svn_string_t *, which is our counted string which can contain arbitrary binary data. So the client API allows binary data, but it might be caught further down the library stack. -Hyrum
Re: [Issue 3770] New - JavaHL method to set binary property is broken
Hyrum K Wright wrote on Thu, Dec 30, 2010 at 15:03:04 -0500: On Thu, Dec 30, 2010 at 2:57 PM, Mark Phippard markp...@gmail.com wrote: On Thu, Dec 30, 2010 at 2:17 PM, Hyrum K Wright hy...@hyrumwright.org wrote: Mark, Daniel pointed out on IRC that all the revpropTable arguments in the JavaHL API are MapString, String. Should they be adjusted to MapString, byte[] ? What is the rule for revision properties? I thought they had to be UTF-8 strings, in which case the Java String class seems more appropriate than using Byte[] which would imply the user can assign binary values to the property. If Revision properties can contain binary values, then yes we should not be using String here. I don't remember what the repository enforces, but the underlying API contains a hash of const char * revprop names, with values of svn_string_t *, which is our counted string which can contain arbitrary binary data. So the client API allows binary data, but it might be caught further down the library stack. % $svn ps --revprop -r0 svn-binary -F =svn wc1 property 'svn-binary' set on repository revision 0 % $svn ps --revprop -r0 random-data -F =(head -c 1024 /dev/urandom) wc1 property 'random-data' set on repository revision 0 % $svn pg --revprop -r0 random-data --strict wc1 | xxd -ps -c1 | grep 00 00 00 00 -Hyrum
Re: svn commit: r1053932 - /subversion/trunk/subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java
On 12/30/10 11:54 AM, Mark Phippard wrote: On Thu, Dec 30, 2010 at 2:24 PM, Blair Zajacbl...@orcaware.com wrote: -client.propertyCreate(itemPath, cqcq, qrz, Depth.empty, null, +String alphaVal = qrz; +client.propertyCreate(itemPath, cqcq, alphaVal.getBytes(), Depth.empty, null, Do you need to pass UTF-8 to alphaVal.getBytes? Don't know. Do I? Tests pass. Looks like all the string conversions were remove, so it's moot. But typically, one always wants to pass UTF-8 to String's constructor and getBytes() so you don't have different encodings in different locales. Blair
Re: [RFC] diff-optimizations-bytes branch: avoiding function call overhead (?)
On Tue, Dec 28, 2010 at 7:31 PM, Johan Corveleyn jcor...@gmail.com wrote:
On Fri, Dec 24, 2010 at 3:40 PM, Stefan Fuhrmann eq...@web.de wrote:
On 20.12.2010 02:43, Johan Corveleyn wrote:
On Wed, Dec 15, 2010 at 10:58 AM, Stefan Fuhrmanneq...@web.de wrote:
On 15.12.2010 02:30, Stefan Fuhrmann wrote:
On 14.12.2010 23:35, Johan Corveleyn wrote:
Thoughts?
Two things you might try:
* introduce a local variable for afile[i]
* replace the for() loop with two nested ones, keeping
calls to other functions out of the hot spot:
for (i=0; i file_len;)
That should read:
for (i=0; i file_len; i++)
{
/* hot spot: */
for(; i file_len; i++)
{
curFile = afile[i];
if (curFile-chunk==-1)
curFile-chunk = 0;
else if (curFile-curp != curFile-endp -1)
curFile-curp++;
else
break;
}
if (i file_len)
{
/* the complex, rarely used stuff goes here */
}
}
Ok, I tried this, but it didn't really help. It's still only about as
fast as before. While the macro version is about 10% faster (I made a
cleaner macro version, only macro'ing the hotspot stuff, with a
function call to the complex, rarely used stuff).
For the inline version, I tried several variations (always with
APR_INLINE in the function signature, and with local variable for
file[i]): with or without the nested for loop, with or without the
complex stuff factored out to a separate function, ... it made no
difference.
Maybe I'm still doing something wrong, keeping the compiler from
inlining it (but I'm not really a compiler expert, maybe I have to add
some compiler options or something, ...). OTOH, I now have a macro
implementation which is quite readable (and which uses the do ...
while(0) construct - thanks Peter), and which does the trick. So maybe
I should simply stick with that option ...
The key factor here is that file_len is only 2.
Basically, that will make my optimization a
pessimization.
Assuming that for most calls, curp of *both*
files will be somewhere *between* BOF and
EOF, the unrolling the loop may help:
#define INCREMENT_POINTERS
/* special code for the common case. 10 .. 12 ticks per execution */
static APR_INLINE svn_boolean_t
quickly_increment_pointers(struct file_info *afile[])
{
struct file_info *file0 = afile[0];
struct file_info *file1 = afile[1];
if ((afile0-chunk != -1) (afile1-chunk != -1))
{
/* suitable_type */ nextp0 = afile0-curp + 1;
/* suitable_type */ nextp1 = afile1-curp + 1;
if ((nextp0 != afile0-endp) (nextp1 != afile1-endp))
{
afile0-curp = nextp0;
afile1-curp = nextp1;
return TRUE;
}
}
return FALSE;
}
/* slow code covering all special cases */
static svn_error_t*
slowly_increment_pointers(struct file_info *file[], apr_size_t file_len,
apr_pool_t *pool)
{
for (i = 0; i file_len;i++)
...
}
/* maybe as macro: */
return ((file_len == 2) quickly_increment_pointers (file))
? SVN_NO_ERROR
: slowly_increment_pointers(file, file_len, pool);
Nice! I will try this out sometime soon, but I'm not so sure it will
help more than the current macro version (only macro for the critical
section, calling a function for increment/decrement chunk - see
diff_file.c in HEAD of diff-optimizations-bytes branch). I guess I'll
just have to test it.
With the macro implementation in place my gut feeling is that the
prefix/suffix scanning is reasonably optimal, and that the remaining
time spent in the diff code (70 seconds for my example blame of big
xml file with 2200 changes) is almost all due to the original diff
algorithm (working on the remainder between prefix and suffix). But to
be sure I should probably measure that first.
Hmmm, my gut feeling seems to be a little bit off. I measured this,
and prefix/suffix scanning is still taking 46 - 50 seconds of the
total 70 seconds spent in diff-time during the blame of my example
file (~20 seconds are going to getting tokens and inserting them into
the token tree, and ~5 seconds in the actual LCS algorithm). So
optimizations here will probably still be very useful.
I'm going to let this rest for a while, until I get the prefix/suffix
scanning work for diff3 and diff4. After I get that all working, I
might revisit this for more optimization ...
Cheers,
--
Johan
