Performance of 'svnlook changed' is O(revsize)

2024-10-18 Thread Johan Corveleyn
Haven't looked into the code yet, but this might be an nice
"bite-sized" issue to investigate, if someone has time and inclination
to do so:

Seen on a FSFS f8 repository (on Linux) with a 200 MB revision:

Apparently 'svnlook changed -r $REV' gets slow if $REV is large (as in
"lots of MB", not in amount of changed files -- it can be seen on a
commit with a single large file). OTOH, 'svnlook author' or 'svnlook
filesize' of that same revision+file will be almost instant.

Interestingly 'svn log -v -r $REV $URL' is much faster (not dependent
on the revision size), and shows the same information as 'svnlook
changed -r $REV'. This to me is a clear indication that 'svnlook
changed' is doing something sub-optimal, making it perform O(revsize)
instead of O(1).

Note: 'svnlook changed' is often used in hook scripts. In a pre-commit
hook one would run 'svnlook changed -t $TXN' on the transaction if one
would like to validate some things -- at that point 'svn log -v'
cannot be used as an alternative because there is no revision yet. I
would hope that any possible improvement would also apply to
transactions as well as to revisions.

-- 
Johan


Re: check-swig-rb failures with SWIG 4.3.0

2024-10-18 Thread Andreas Stieger

Hi,

On 2024-10-18 07:57, Jun Omae wrote:

On 2024/10/14 16:37, Yasuhito FUTATSUKI wrote:

On 2024/10/14 12:37, Yasuhito FUTATSUKI wrote:

It seems it is caused by backward incompatible change of SWIG,
even it may be a bug.

It turned out this is not a bug of SWIG, but intentional, for
the purpose to fix another problem, incompatible change of
SWIG_Ruby_AppendOutput, SWIG_Python_AppendOutput (and it affect
the process how we construct result objects).

Thanks,

SWIG 4.3.0-beta1 doesn't work with swig-rb and swig-py bindings, for our use
case that the svn_error_t * return value is not used as a return value on
success and is raised as an exception on error. Also, our %typemap(out) which
uses %append_output for swig-rb has issues.

I created patches and tested with SWIG 3.0.12, 4.2.1, 4.3.0-beta1.

  - swig-4.3.0-swig-rb.patch.txt(swig-rb for trunk and 1.14.x)
  - swig-4.3.0-swig...@trunk.patch.txt  (swig-py for trunk)
  - swig-4.3.0-swig...@1.14.x.patch.txt (swig-py for 1.14.x)

Could anybody please test the patches?



Builds and tests (testsuite) fine for me on:

* trunk x {4.2.1,4.3.0-beta1} * 1.14.3 x {4.2.1,4.3.0-beta1}

Andreas