Geoffrey Alary | 20 Dec 02:40 2014
Picon

[PATCH] svn_load_dirs.pl: fix rm temporary folder

Hello,

I am contacting you to propose 2 patch files for the script
svn_load_dirs.pl located at the URL below:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/svn_load_dirs.pl.in

This email discusses the first patch, which avoids failing to delete
the temporary folder with an error like this one:
"cannot remove path when cwd is
/tmp/svn_load_dirs_ATrGGCJoWv/my_import_wc for
/tmp/svn_load_dirs_ATrGGCJoWv"

The error has also been reported at the following link:
http://www.wandisco.com/svnforum/threads/40434-Import-snapshot-folders-requesting-step-by-step-guide-for-using-svn_load_dirs-pl?p=116340&viewfull=1#post116340

I propose a really simple patch, as pasted below (I also send it
attached if you prefer).

Best regards,
Geoffrey

--- contrib/client-side/svn_load_dirs/svn_load_dirs.pl.in
+++ contrib/client-side/svn_load_dirs/svn_load_dirs.pl.in
 <at>  <at>  -2052,6 +2052,7  <at>  <at> 

 sub DESTROY
 {
   print "Cleaning up $temp_dir\n";
+  chdir( $temp_dir . "/.." );
   File::Path::rmtree([$temp_dir], 0, 0);
(Continue reading)

Geoffrey Alary | 20 Dec 02:40 2014
Picon

[PATCH] svn_load_dirs.pl: hide passwords printed to screen

Hello,

I often use svn_load_dirs.pl in a script to load several huge third
party libraries into our SVN repo. This repository uses LDAP
authentication with https and I do not want my password popping up at
times on the console executing the script (for several hours).

Hence my second patch, that hides the password printed to screen with
stars (*). It does that by passing the array of arguments containing
the password to a function sanitize_pwd before printing it. This
function searches for '--password' and hides the following word.

I digress a bit, but my scripts using svn_load_dirs.pl (themselves in
a SVN repo) ask for username/password so that they do not expose
sensitive information. Password is prompted either with `read -s` for
the bash script, or with this SO answer for the batch version:
http://stackoverflow.com/a/20343074/3628160

Please find my patch below. Besides defining sanitize_pwd and changing
the print call sites the attached version of the patch also replaces
the few tabs in source by spaces (as I realized gmail edits the tabs I
omitted this part from the version below, which apart from that
fulfils its duty).

Best regards,
Geoffrey

--- contrib/client-side/svn_load_dirs/svn_load_dirs.pl.in
+++ contrib/client-side/svn_load_dirs/svn_load_dirs.pl.in
 <at>  <at>  -1499,6 +1499,18  <at>  <at>  sub file_info
(Continue reading)

Ivan Zhakov | 19 Dec 15:37 2014

FSFS caching and apr_thread_rwlock_t performance on Windows

Originally FSFS caching implementation was using apr_thread_mutex_t to
serialize access to shared data. In r1346122 [1] implementation was
switched to apr_thread_rw_lock_t to improve performance. This change
was released in Subversion 1.8.0

Unfortunately current apr_thread_rwlock_t implementation is very slow
on Windows. As quick workaround FSFS code was patched to select
apr_thread_mutex_t or apr_thread_rwlock_t() depending of platform on
compile time (r1611380 [2]).

In further investigation Bert found why apr_thread_rwlock_t() so slow
on Windows: implementation uses kernel level mutex object instead of
lightweight critical section (critical sections are also used in
apr_thread_mutex_t in most cases).

The simple patch to switch apr_thread_rwlock_t() implementation to use
critical sections (through apr_thread_mutex_t) was proposed on APR
development mailing list [3], but patch was not commited nor reviewed.

So the current situation is:
1. APR has performance problem on Windows that hurts Subversion 1.8.x and trunk
2. Subversion trunk has workaround for this specific problem at compile time
3. Patch proposed to APR mailing list, without any reaction for three months

From my point of view the proposed patch is straightforward and Bert
stated that it makes apr_thread_rwlock_t 10 to 140 times more
efficient on Windows. So the best option will be to commit Bert's
patch, but I cannot do this since I'm not APR committer :(

Thoughts?
(Continue reading)

Julian Foad | 19 Dec 13:23 2014

Symmetry between dump and load

I believe the following symmetries should be true, and testable, and we should test them.

For any valid repository:

  * we can dump it
  * we can load the dump file into a new repository
  * the new repo is equivalent to the old repo

For any valid dump file:

  * we can load it into a new repository
  * we can dump that repository
  * the new dump file is equivalent to the old dump file

WHY?

This thought was triggered after noticing that we keep finding more and more asymmetries (that is, bugs) in
dump and load. Most of the ones I have paid attention to are related to mergeinfo. Examples:

  #3912 svnadmin load does fail to process dumps with non UTF-8 path names
  #4414 dump/load with invalid mergeinfo
  #4476 Mergeinfo containing r0 makes svnsync and dump and load fail
  #4492 svnrdump load assertion failure if Node-path starts with a slash
  #4538 'load' strips r1 references in mergeinfo
  #4539 Need a way to 'load' a dump without munging mergeinfo
  #4573 mergeinfo parsing inconsistency: empty path

Why does this matter? Users care about stability. Waiting for a bug to show up, fixing it, and adding a
regression test for that particular case gets us only so far. We could be pro-active, and go looking for
these sorts of bugs much more aggressively. I think we should.
(Continue reading)

Julian Foad | 17 Dec 13:56 2014

Test suite doesn't detect httpd crashes

I have found that Apache 2.4.7 with the 'event' MPM sometimes crashes while running our test suite. I
discussed with Philip and Ben yesterday and they let me know that this a known issue with several 2.4.x
versions, and is fixed in later versions (>= 2.4.10 ?). The Subversion I'm currently testing with is trunk <at> 1646184.

The problem I want to highlight here is that our test suite doesn't report these crashes. On some runs it
reports that some individual tests failed, and overall failure, but on other runs it reports no
individual tests failed, and overall success, even though Apache crashed.

Do we want to make our test suite detect these crashes, and report overall failure even if each of the
individual test scenarios completed successfully?

It seems to me we should. What do you think?

DETAILS

After a run of externals_tests.py --parallel that reported success on all tests, the error_log first
contains this:

[mpm_event:error] ... AH00484: server reached MaxRequestWorkers setting, consider raising the
MaxRequestWorkers setting

which doesn't seem to be a problem in itself, as I always get this even if it doesn't go on to crash, and also get
a similar message when using 'worker' MPM and that doesn't go on to crash either.

Then it may contain one or more messages like this:

[core:notice] ... AH00051: child pid 23555 exit signal Segmentation fault (11)...

At the moment I don't know if any error indication is being returned to some part of the test runner and then
not reported as test failure, or if searching the error_log is the only way to detect these crashes.
(Continue reading)

Radjino Bholanath | 17 Dec 11:43 2014
Picon
Picon

Questions about code reviews and static analysis tools for TU Delft research

Hi,

 

I'm doing research on code reviews and static analysis tools at the SERG group (http://swerl.tudelft.nl/bin/view/Main/WebHome) of the Delft University of Technology. Currently, we want to give an overview of the usage of code review and static analysis tools in open source projects. Therefore, I would be very happy to know a little bit more about how code reviews are used in Subversion and if (and maybe how) static analysis tools are used. I have a couple of questions for anyone willing to answer:


1. Do all developers (contributors and core developers) have to submit a code review for every change? I’m asking because many projects only review changes made by contributors.

2. Which code review tools are used (just the mailing list, or maybe other tools)?

3. Are static analyzers used? If they are used:

a. Is passing the checks of the static analyzers necessary for a change to be accepted?

b. Which static analyzers are used?

 

Thanks,

Radjino

Picon

[l10n] Translation status report for trunk r1645839

Translation status report for trunk <at> r1645839

  lang   trans untrans   fuzzy     obs
--------------------------------------
    de    2872       2       6     489  +++++++++++++++++++++++++++++~ooooo
    es    2264     610     828     527  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2568     306     516     112  ++++++++++++++++++++++UUU~~~~~
    it    2123     751     951     340  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2254     620     877     763  ++++++++++++++++++UUUU~~~~~~~~oooooo
    ko    2400     474     649     217  ++++++++++++++++++++UUUU~~~~~~o
    nb    2314     560     779     500  +++++++++++++++++++UUUU~~~~~~~oooo
    pl    2339     535     746     297  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2099     775     964     321  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2731     143     313      78  +++++++++++++++++++++++++UU~~~
 zh_CN    2651     223     385      21  ++++++++++++++++++++++++UU~~~~
 zh_TW    2040     834    1001     377  +++++++++++++++UUUUUUU~~~~~~~~oo

Ben Reser | 15 Dec 22:13 2014
Picon

Apache Subversion 1.7.19 released

I'm happy to announce the release of Apache Subversion 1.7.19.

This release addresses two security issues:
    CVE-2014-3580: mod_dav_svn DoS from invalid REPORT requests.
    CVE-2014-8108: mod_dav_svn DoS from use of invalid transaction names.

Please choose the mirror closest to you by visiting:

    http://subversion.apache.org/download/#supported-releases

The SHA1 checksums are:

    3681b967d1c154b2aa4ccb63984d89aedafc488b subversion-1.7.19.zip
    bb3cd135bbd856e7f0f2d59313f075b9bbec9848 subversion-1.7.19.tar.gz
    a662721a3a1da70c4b0732d0bde5008ce8873575 subversion-1.7.19.tar.bz2

PGP Signatures are available at:

    http://www.apache.org/dist/subversion/subversion-1.7.19.tar.bz2.asc
    http://www.apache.org/dist/subversion/subversion-1.7.19.tar.gz.asc
    http://www.apache.org/dist/subversion/subversion-1.7.19.zip.asc

For this release, the following people have provided PGP signatures:

   Ben Reser [4096R/16A0DE01] with fingerprint:
    19BB CAEF 7B19 B280 A0E2  175E 62D4 8FAD 16A0 DE01
   Bert Huijben [4096R/CCC8E1DF] with fingerprint:
    3D1D C66D 6D2E 0B90 3952  8138 C4A6 C625 CCC8 E1DF
   Ivan Zhakov [4096R/F6AD8147] with fingerprint:
    4829 8F0F E47F 4B8A 43FD  6525 919F 6F61 F6AD 8147
   Julian Foad [4096R/4EECC493] with fingerprint:
    6011 63CF 9D49 9FD7 18CF  582D 1FB0 64B8 4EEC C493
   Paul T. Burba [4096R/56F3D7BC] with fingerprint:
    1A0F E7C6 B3C5 F8D4 D0C4  A20B 64DD C071 56F3 D7BC
   Philip Martin [2048R/ED1A599C] with fingerprint:
    A844 790F B574 3606 EE95  9207 76D7 88E1 ED1A 599C
   Stefan Fuhrmann [4096R/57921ACC] with fingerprint:
    056F 8016 D9B8 7B1B DE41  7467 99EC 741B 5792 1ACC
   Stefan Sperling [2048R/9A59B973] with fingerprint:
    8BC4 DAE0 C5A4 D65F 4044  0107 4F7D BAA9 9A59 B973

Release notes for the 1.7.x release series may be found at:

    http://subversion.apache.org/docs/release-notes/1.7.html

You can find the list of changes between 1.7.19 and earlier versions at:

    http://svn.apache.org/repos/asf/subversion/tags/1.7.19/CHANGES

Questions, comments, and bug reports to users <at> subversion.apache.org.

Thanks,
- The Subversion Team

Ben Reser | 15 Dec 22:13 2014
Picon

Apache Subversion 1.8.11 released

I'm happy to announce the release of Apache Subversion 1.8.11.

This release addresses two security issues:
    CVE-2014-3580: mod_dav_svn DoS from invalid REPORT requests.
    CVE-2014-8108: mod_dav_svn DoS from use of invalid transaction names.

Please choose the mirror closest to you by visiting:

    http://subversion.apache.org/download/#recommended-release

The SHA1 checksums are:

    2fe09670b21fcd7e083b10f088dedcd3252e8e16 subversion-1.8.11.tar.gz
    161edaee328f4fdcfd2a7c10ecd3fbcd51c61275 subversion-1.8.11.tar.bz2
    bb43d38c98d6c84197ec71d1bf4f03c6bf38d14c subversion-1.8.11.zip

PGP Signatures are available at:

    http://www.apache.org/dist/subversion/subversion-1.8.11.tar.bz2.asc
    http://www.apache.org/dist/subversion/subversion-1.8.11.tar.gz.asc
    http://www.apache.org/dist/subversion/subversion-1.8.11.zip.asc

For this release, the following people have provided PGP signatures:

   Ben Reser [4096R/16A0DE01] with fingerprint:
    19BB CAEF 7B19 B280 A0E2  175E 62D4 8FAD 16A0 DE01
   Bert Huijben [4096R/CCC8E1DF] with fingerprint:
    3D1D C66D 6D2E 0B90 3952  8138 C4A6 C625 CCC8 E1DF
   Ivan Zhakov [4096R/F6AD8147] with fingerprint:
    4829 8F0F E47F 4B8A 43FD  6525 919F 6F61 F6AD 8147
   Julian Foad [4096R/4EECC493] with fingerprint:
    6011 63CF 9D49 9FD7 18CF  582D 1FB0 64B8 4EEC C493
   Paul T. Burba [4096R/56F3D7BC] with fingerprint:
    1A0F E7C6 B3C5 F8D4 D0C4  A20B 64DD C071 56F3 D7BC
   Philip Martin [2048R/ED1A599C] with fingerprint:
    A844 790F B574 3606 EE95  9207 76D7 88E1 ED1A 599C
   Stefan Fuhrmann [4096R/57921ACC] with fingerprint:
    056F 8016 D9B8 7B1B DE41  7467 99EC 741B 5792 1ACC
   Stefan Sperling [2048R/9A59B973] with fingerprint:
    8BC4 DAE0 C5A4 D65F 4044  0107 4F7D BAA9 9A59 B973

Release notes for the 1.8.x release series may be found at:

    http://subversion.apache.org/docs/release-notes/1.8.html

You can find the list of changes between 1.8.11 and earlier versions at:

    http://svn.apache.org/repos/asf/subversion/tags/1.8.11/CHANGES

Questions, comments, and bug reports to users <at> subversion.apache.org.

Thanks,
- The Subversion Team

Julian Foad | 15 Dec 18:13 2014

FAIL: basic_tests.py 38 "use folders with names like 'c:hi'"

I see a test failure on current trunk over HTTP:

$ basic_tests.py ... 38
...
CMD: svnmucc ... put .../C</C< ...
exited with 1
.../subversion/svnmucc/svnmucc.c:225,
.../subversion/libsvn_ra_serf/xml.c:915: (apr_err=SVN_ERR_RA_DAV_MALFORMED_DATA)
svnmucc: E175009: The XML response contains invalid XML
.../subversion/libsvn_ra_serf/xml.c:915: (apr_err=SVN_ERR_XML_MALFORMED)
svnmucc: E130003: Malformed XML: not well-formed (invalid token)
FAIL:  basic_tests.py 38: use folders with names like 'c:hi'

I understand from Philip and Ben on IRC that this is a known bug with some versions of httpd. On our end we 

<philipm> Brane added a check the knows about the broken versions in some distributions (OS X and RedHat
possibly) but not all the broken version.
[...]
<breser> Yeah and he said something to me about looking at the list and I forgot to do it.
<philipm> Ben added a configure check that prevents building with some broken versions, Brane added an
XFAIL for other broken versions.
 Ben's regex in apache.m4 is 2.4.[56], Brane's blacklist is 2.4.9.

Can we consolidate this? Do we really need two different mechanisms? How about we get rid of the XFAIL check
and just have the 'configure' check, and if somebody overrides it (or if there's a broken version that
'configure' doesn't catch) then we see test failures?

- Julian

Stefan Fuhrmann | 11 Dec 10:39 2014

'svn up' may cause inconsistent mergeinfo

Hi,

There is yet another problem with sub-tree mergeinfo:

(1) User A performs a sub-tree merge causing the mi property
  to be added to the sub-node. No commit, yet.
(2) User B commits a merge at the branch root, modifying its m/i.
(3) User A updates and commits their merge.

Now, the sub-tree mergeinfo does not reflect the changes
made to the root node m/i. If the latter are operative on that
sub-tree, the data is inconsistent and can create conflicts.

The attached script demonstrates the problem.

-- Stefan^2.

Gmane