Marc Strapetz | 24 Apr 13:59 2015

JavaHL RFE: ISVNRemote should provide API to retrieve a contents of a specific file

To allow users to browse through all contents of a file (as part of an 
interactive blame), it's necessary to have an efficient API to retrieve 
these file contents.

AFAIU, the low-level file_rev_handler already provides this information 
via svn_txdelta_window_handler_t. Unfortunately, in RemoteSettion.cpp 
this information is converted to just a boolean (delta_handler != NULL) 
and passed to the JavaHL callback afterwards.

I don't think it's necessary (or even desirable) to provide the 
patch/stream logic, like svn_stream_open_readonly, as Java API, just a 
way to retrieve complete file contents for all revisions. Suggestion:

interface ISVNRemote {
/**
  *   <at> param RemoteFileContentsCallback may be null
  */
void getFileRevisions(String path,
                       long startRevision, long endRevision,
                       boolean includeMergedRevisions,
                       RemoteFileRevisionsCallback handler
                       RemoteFileContentsCallback contentsHandler)
   throws ClientException;
}

interface RemoteFileContentsCallback {
     void doFileContent(ISVNRemote.FileRevision fileRevision,
                        InputStream content);
}

(Continue reading)

Alexander Thomas | 24 Apr 08:43 2015
Picon

1.9-rc1: Javahl compilation issue in RHEL3

Compiling 1.9.0-rc1 JavaHL in RHEL3 32bit with GCC version 3.2.3-53 and 
libstdc++ version 5.0.3 fails with multiple compilation error in 
javahl/native/EditorProxy.cpp. In addition to line number 213, line 360 
also fails with same error.

However I was able to successfully compile against GCC 4.2.0 with 
libstdc++ 6.0.9.

Is this something we can fix for RHEL3 ?

[[[
  subversion/bindings/javahl/native/EditorProxy.cpp: In static member 
function
    `static svn_error_t* EditorProxy::cb_add_file(void*, const char*, const
    svn_checksum_t*, svn_stream_t*, apr_hash_t*, long int, apr_pool_t*)':
subversion/bindings/javahl/native/EditorProxy.cpp:213: `Env' specified as
    declarator-id
subversion/bindings/javahl/native/EditorProxy.cpp:213: multiple 
declarations `
    int' and `Java::RuntimeException'
subversion/bindings/javahl/native/EditorProxy.cpp:213: `int Java::Env()' 
should
    have been declared inside `Java'
subversion/bindings/javahl/native/EditorProxy.cpp:213: syntax error 
before `.'
    token
subversion/bindings/javahl/native/EditorProxy.cpp:213: `Env' specified as
    declarator-id
subversion/bindings/javahl/native/EditorProxy.cpp:213: multiple 
declarations `
(Continue reading)

Marc Strapetz | 23 Apr 16:44 2015

1.9: javahl.ISVNClient#cleanup(String) always fails with "Attempted to lock an already-locked dir"

cleanup-related code which is working fine with 1.8 JavaHL starts 
failing with 1.9 JavaHL.

According to the docs, ISVNClient#cleanup(String) does not break locks, 
which seems to cause the problems:

   /**
    * Recursively cleans up a local directory, finishing any
    * incomplete operations, removing lockfiles, etc.
    * <p>
    * Behaves like the 1.9 version with <code>breakLocks</code> and
    * <code>includeExternals</code> set to <code>false<code>, and the
    * other flags to <code>true</code>.
    *  <at> param path a local directory.
    *  <at> throws ClientException
    */

When using ISVNClient.cleanup(path, *true*, true, true, true, false) 
code works.

-Marc

Marc Strapetz | 22 Apr 20:28 2015

RFE: copy with metadataOnly should allow removed/replaced sources and added/replaced targets

Using copy with the new metadataOnly option (through the API) only 
allows to "move" or "copy" a missing file onto an unversioned file. It 
could also be helpful to copy/move metadata from a removed (or replaced) 
source to an already added (or replaced) target.

Use case 1: the user has removed file "a" and moved file "b" to file "a" 
without using SVN:

$ svn status
M a
! b

Goal is to preserve "b"'s history for the new "a" and have the history 
of the old "a" being ended. With metadataOnly being more tolerant, this 
could then be done by:

$ svn rm --keep-local a
$ svn add a
$ svn cp --metadata-only b a

Use case 2: the user has moved file "a" to file "b" and created a new 
file "a" without using SVN:

$ svn status
M a
? b

Goal is to preserve old "a"'s history for "b" and start a new history 
for new "a". With metadataOnly being more tolerant, this could then be 
done by:
(Continue reading)

Marc Strapetz | 22 Apr 19:58 2015

Subversion 1.9: svn cp --pin-externals may produce dummy log entries

After invoking following series of commands:

   svnadmin create repo
   svn checkout file://localhost/d:/temp/externals/repo wc

   mkdir wc
   cd wc
   mkdir ext
   touch ext\file

   mkdir src\dir
   svn add *
   svn propset svn:externals "^/ext ext" src
   svn propset svn:externals "^/ext <at> 1 ext" src\dir
   svn commit -m "initial import"

   svn up
   svn cp --pin-externals src ^^/dst -m "copy"
   svn log -r2 -v
   svn proplist -r2 -R -v ^^/
   svn proplist -r1 -R -v ^^/

The final log output shows /dst/dir as modified:

-------------------------
r2 | marc | 2015-04-22...
Changed paths:
    A /dst (from /src:1)
    M /dst/dir

(Continue reading)

Stefan Hett | 22 Apr 16:35 2015

[PATCH] small INSTALL file corrections

Hi,

following the INSTALL documentation I took the chance to correct a few 
minor things I spotted.
Here's a patch containing the changes, in case you want to apply it to 
the source (patch against trunk):

[[[
Several small updates/corrections to the INSTALL file:
- mention VS 2010 compatibility
- case-correction for February
- replaced dead-link to Platform SDK for VC6 with link to still 
available instructions
- replaced redirection URL zlib.org with direct URL zlib.net
- update VS build instructions to be suitable for VS >= 2010
- added missing compatibility note for VS 2008

* INSTALL
     documentation updated
]]]

Regards,
Stefan
Index: INSTALL
===================================================================
--- INSTALL	(revision 1675365)
+++ INSTALL	(working copy)
 <at>  <at>  -751,13 +751,13  <at>  <at>  II.   INSTALLATION
(Continue reading)

Stefan Fuhrmann | 22 Apr 04:07 2015

Re: 1.9.0-rc1 up for testing/signing

On Tue, Apr 21, 2015 at 10:09 PM, Ben Reser <ben <at> reser.org> wrote:
The 1.9.0-rc1 release artifacts are now available for testing/signing.
Please get the tarballs from
  https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there.

This being a rc1 it means that our soak period for 1.9.0 has begun as described
here:
http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization

Summary:

  +1 to release

Platform

  Ubuntu 14.04.1 x64, Linux 3.16.0-31-generic SMP

  Standard dependencies:
    APR 1.5.0
    APR-Util 1.5.3
    BDB 5.3.28
    GCC 4.8.2
    httpd 2.4.7, worker MPM
    JUnit 4.11
    libmagic 5.14
    libtool 2.4.2
    neon 0.30.0
    OpenJDK-7 7u51
    OpenSSL 1.0.1f
    Perl 5.18.2
    Python 2.7.5
    Ruby 1.9.3
    SQLite 3.8.2
    Swig 2.0.11
    zlib 1.2.8

  Manually installed and in-tree dependencies:
    Serf 1.3.8
    ctypesgen svn-r151

Verified:

  Tarball contents and signatures

  (fsfs, bdb, fsx) x (local, svnserve, serf)
  check-swig-py
  check-swig-pl
  check-swig-rb
  check-javahl
  check-ctypes-python

  ./get-deps.sh

Results:

  All tests passed.

GPG Signatures committed to the dist/dev/subversion repository.

-- Stefan^2.
Sivaram Iyer | 21 Apr 18:37 2015
Picon

SVN Passwd | Authentication issue

We use plan text passwd file for authentication of users on our SVN server. This was working fine until few days ago, then I had to add a few new users to the system, and during the process I accidentally deleted the passwd file, but managed to recreated the file with all the users in it. 

Post the above change, the users are not able to interact with SVN, not able to perform any actions on the SVN servers (like Checkout / Commit /etc). I have restarted the svnserve daemon after recreating the passwd file, but users get the error: "Unable to connect to repository at URL" ... "Authentication Failed". 

We directly reach the repository over svn:// protocol, (no http/s), and this used to work fine for us, until the above change. 

Any help, much appreciated. 

Best,
Sivaram 
Ben Reser | 21 Apr 22:09 2015

1.9.0-beta1 up for testing/signing

The 1.9.0-rc1 release artifacts are now available for testing/signing.
Please get the tarballs from
  https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there.

This being a rc1 it means that our soak period for 1.9.0 has begun as described
here:
http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization

Picon

[l10n] Translation status report for trunk r1675026

Translation status report for trunk <at> r1675026

  lang   trans untrans   fuzzy     obs
--------------------------------------
    de    2935       0       4     504  +++++++++++++++++++++++++++++~ooooo
    es    2285     650     857     529  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2592     343     553     115  ++++++++++++++++++++++UUU~~~~~
    it    2144     791     977     342  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2274     661     903     766  +++++++++++++++++UUUUU~~~~~~~~ooooo
    ko    2422     513     681     219  ++++++++++++++++++++UUUU~~~~~~o
    nb    2338     597     812     503  ++++++++++++++++++UUUUU~~~~~~~oooo
    pl    2363     572     780     301  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2120     815     990     322  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2760     175     369      84  +++++++++++++++++++++++++U~~~~
 zh_CN    2683     252     429      30  +++++++++++++++++++++++UUU~~~~
 zh_TW    2062     873    1026     378  +++++++++++++++UUUUUUU~~~~~~~~oo

Julian Foad | 20 Apr 16:08 2015
Picon

svnmover -- merging with subbranches

Hi Brane. You asked me on IRC about a week ago if/how svnmover handled
merging with subbranches.

I added a test

  svnmover_tests.py 12: subbranches1

that exercises a merge with subbranches.

Please could you take a look and see if it does what you expect?

Maybe you could add something to the test that you also expect?

Thank you.

As always, any comments are welcome.

- Julian


Gmane