[l10n] Translation status report for trunk r1663522

Translation status report for trunk <at> r1663522

  lang   trans untrans   fuzzy     obs
    de    2894      28      62     502  +++++++++++++++++++++++++++++~ooooo
    es    2282     640     854     530  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2587     335     548     116  ++++++++++++++++++++++UUU~~~~~o
    it    2141     781     974     342  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2271     651     900     766  +++++++++++++++++UUUUU~~~~~~~~oooooo
    ko    2419     503     678     220  ++++++++++++++++++++UUUU~~~~~~o
    nb    2333     589     807     503  ++++++++++++++++++UUUUU~~~~~~~oooo
    pl    2358     564     775     301  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2117     805     987     323  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2753     169     361      84  +++++++++++++++++++++++++U~~~~
 zh_CN    2675     247     420      29  ++++++++++++++++++++++++UU~~~~
 zh_TW    2059     863    1023     379  +++++++++++++++UUUUUUU~~~~~~~~oo

Evgeny Kotkov | 2 Mar 21:23 2015

[RFC/PATCH] Modifying internal FS transaction properties

I'd like to draw attention to one aspect of the FS API that received a change
in Subversion 1.9.

We have 2 functions, svn_fs_change_txn_prop() and svn_fs_change_txn_props(),
that allow changing properties of the existing transactions in a filesystem.
I think we might want to revisit their behavior in terms of the transaction
properties that we allow to change and in terms of what we do when a caller
attempts to change an internal property like 'svn:check-locks' or

1) Currently we allow changing 'svn:check-ood' and 'svn:check-locks'.  We also
   silently discard a property change whenever it targets 'svn:client-date'.
   I find the first part questionable, because we basically allow a caller to
   mess with our private implementation details.  Existence of the internal
   properties is a consequence of the fact that we use them to persist the
   transaction flags on the disk, but if, for example, we were using another
   way of storing these flags, I doubt that we'd expose an ability to change
   them through our API.

   Apart from what is stated above, I think that silently discarding changes
   to 'svn:client-date' is somewhat broken.  As a caller, I would expect the
   successive call to a function like svn_fs_change_txn_prop() to mean that the
   requested change was applied without any problems.  This is not true with
   'svn:client-date', because doing so doesn't result in an error, but also
   *doesn't change the property*.  In other words, the change goes straight to
   /dev/null, but the API says that the operation completed successfully.

   I propose that we solve this part of the problem with the attached patch.
   Please note that while preparing this patch, I also unveiled that the
   SVN_FS_TXN_CLIENT_DATE flag might not work as expected with BDB.
(Continue reading)

Daniel Shahaf | 28 Feb 23:03 2015

[PATCH] doxygen docs += svn logo

Patch to add the project logo to the top-left of generated doxygen
pages.  Not sure what are the consequences of using a logo larger than
200x55 pixels, so won't commit it for now.

If adding a file external is a problem, it would be straightforward to
avoid that by using 'svn cat ^/subversion/site/...' in the 'doc'
Makefile target; the trade-off is requiring an Internet connection and
an svn binary to be available.

(To test it, run 'make doc', the output will be in ./doc/doxygen/.)


doxygen: include the svn logo at the top of generated documentation pages.

* doc/svn-square.jpg:
    New file.  Alias to site/publish/images/svn-square.jpg, via svn:externals.

* doc/doxygen.conf
  (PROJECT_LOGO): Set to the square logo (was unset).

Index: doc/doxygen.conf
--- doc/doxygen.conf	(revision 1662688)
+++ doc/doxygen.conf	(working copy)
 <at>  <at>  -33,6 +33,13  <at>  <at>  PROJECT_NAME           = Subversion

(Continue reading)

Branko Čibej | 28 Feb 11:54 2015

1.8.x backport conflicts bot is red

The error message is:

1.8.x-r1659867 (Fix reproducable memory corruption and unneeded io
errors on editor abort): Revisions 'r1660091, r1660097' nominated but
not included in branch

I think the fix is obvious; Philip, I think you nominated those two
revisions? Do you want to update the backport branch, too?

-- Brane

Graham Leggett | 25 Feb 17:35 2015

[Patch] Expression support for SVNPath and SVNParentPath

Hi all,

The SVNParentPath directive allows a set of repos to be placed at an URL, but if you have more complex needs
such as providing many customers (with separately mounted home directories) access to many
repositories, this may not be enough.

The attached patch brings httpd v2.4 expression support to the SVNPath and SVNParentPath directories
through the addition of an optional second parameter, which allows you to do stuff like this:

    <LocationMatch ^/svn/(?<CUSTOMERNAME>[^/]+)/>

        # customer has their own partition, inside is an “svn” directory with repos in it
        SVNParentPath /home/partition %{env:MATCH_CUSTOMERNAME}/svn

        # customer repos are protected by this group
        require ldap-group cn=https://svn.${SERVER_SUFFIX}/%{env:MATCH_CUSTOMERNAME},ou=svn,ou=Groups,o=Somewhere


Or perhaps this based on the HOST header (and a wildcard SSL cert):

    <Location />

        # customer has their own partition, inside is an “svn” directory with repos in it
        SVNParentPath /home/svn %{HTTP_HOST}

        # customer repos are protected by this group
        require ldap-group cn=%{HTTP_HOST},ou=svn,ou=Groups,o=Somewhere

(Continue reading)

Ben Reser | 24 Feb 18:55 2015

1.9.0-beta1 do we need it?

I'm still working on the CHANGES file for 1.9, it's taking longer than I
anticipated since it's been roughly 9 months since we last did a major update
(and I forgot how long that one took me).

The original thinking for a beta was to get something moving while we finished
up a few things we knew we wanted in 1.9 (svn info --show-item, external
pinning).  But I'm starting to think these things are close enough that given
the time it's taking me to finish up CHANGES we may be ready for a rc1 as soon
as those are done.


Ben Reser | 24 Feb 18:52 2015

Catchup merge of trunk onto 1.9 branch?

I know that Bert has made a lot of changes he'd like to include in 1.9 on
trunk.  At this point since we haven't cut a release candidate I'd like to
propose that we just do a catchup merge excluding anything we really don't
want.  I believe at this point that would just be the version bumpage.



[l10n] Translation status report for trunk r1661837

Translation status report for trunk <at> r1661837

  lang   trans untrans   fuzzy     obs
    de    2890      21      42     496  +++++++++++++++++++++++++++++~ooooo
    es    2279     632     848     530  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2583     328     539     115  ++++++++++++++++++++++UUU~~~~~o
    it    2138     773     970     342  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2268     643     895     766  +++++++++++++++++UUUUU~~~~~~~~oooooo
    ko    2415     496     670     220  ++++++++++++++++++++UUUU~~~~~~o
    nb    2330     581     801     503  ++++++++++++++++++UUUUU~~~~~~~oooo
    pl    2354     557     767     301  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2114     797     983     323  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2749     162     341      80  +++++++++++++++++++++++++U~~~~
 zh_CN    2669     242     410      26  ++++++++++++++++++++++++UU~~~~
 zh_TW    2056     855    1019     379  +++++++++++++++UUUUUUU~~~~~~~~oo

Julian Foad | 19 Feb 13:18 2015

Issue sweep

We have the following open issues that have a target milestone set.

  1.6.x          1 (1 defect)   REVIEW

  1.7.x          4 (4 defect)   REVIEW
  1.7-consider  23 (13 defect)

  1.8.1          2 (2 defect)   REVIEW
  1.8.x          1 (1 defect)   REVIEW
  1.8-consider  24 (22 defect)

  1.9.0          1 (1 defect)
  1.9.x          0
  1.9-consider  52 (1 defect)

  1.10-consider 11 (7 defect)

I suggest we should:

  * Review each of the eight issues marked 'REVIEW' above to see if the milestone still should be set to a
specific old release series. If not, change it to 'unscheduled'.

  * Bulk reassign every 1.[789]-consider issue to 'unscheduled'. If we didn't fix it for 1.7 or 1.8 or 1.9
there is no particular reason why we should *automatically* prioritize it over any other unscheduled
issue for the 1.10 development period.

Thoughts? Volunteers?

- Julian

(Continue reading)

kay | 18 Feb 23:38 2015

subversion error m:human-readable errcode="200001

I configured subversion + apache and created a repository with FSFS backend.
I am getting the following error when I tried to access the newly created
repository via the apache. Please help:

<m:human-readable errcode="200001">
Could not open the requested SVN filesystem

View this message in context: http://subversion.1072662.n5.nabble.com/subversion-error-m-human-readable-errcode-200001-tp192121.html
Sent from the Subversion Dev mailing list archive at Nabble.com.

Julian Foad | 18 Feb 13:30 2015

1.8.x backport - r1536854 "Make 'svnadmin verify' detect inconsistencies"

Stefan and Ben, how did you test this backport proposal?


 * r1536854
   Make 'svnadmin verify' detect inconsistencies that will prevent loading
   dump files.
     Some users rely on dump files as a means of repository backup.  Without
     this patch, there is no way except of 'svnadmin load' to know that these
     dump files will load at all.  With this patch, a successful verify run
     should guarantee loadable dump files.
     +1: stefan2, breser
     -0: julianfoad (test is missing from branch -- how do we know it works?)

- Julian