Stephen White | 27 Mar 14:02 2015

Subversion checkout issue with certain short names on Windows

If you pass a Windows short-name as the destination to "svn co" then it 
will normally work correctly, unless the short name is actually longer 
than the "long name" in which case the string handling seems to go awry.

First a working example:

 > mkdir ALongName.impl
 > dir /x
...
27/03/2015  12:50    <DIR>          ALONGN~1.IMP ALongName.impl
...
 >svn co --depth=files http://svn.apache.org/repos/asf/subversion/trunk 
ALONGN~1.IMP
A    ALongName.impl\NOTICE
A    ALongName.impl\get-deps.sh
A    ALongName.impl\Makefile.in
A    ALongName.impl\LICENSE
A    ALongName.impl\build.conf
A    ALongName.impl\win-tests.py
A    ALongName.impl\COMMITTERS
A    ALongName.impl\README
A    ALongName.impl\BUGS
A    ALongName.impl\configure.ac
A    ALongName.impl\TODO
A    ALongName.impl\.ycm_extra_conf.py
A    ALongName.impl\INSTALL
A    ALongName.impl\CHANGES
A    ALongName.impl\autogen.sh
A    ALongName.impl\gen-make.py
A    ALongName.impl\aclocal.m4
(Continue reading)

Picon

[l10n] Translation status report for trunk r1668798

Translation status report for trunk <at> r1668798

  lang   trans untrans   fuzzy     obs
--------------------------------------
    de    2927       3       8     504  +++++++++++++++++++++++++++++~ooooo
    es    2283     647     855     530  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2589     341     550     116  ++++++++++++++++++++++UUU~~~~~o
    it    2142     788     975     343  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2272     658     901     767  +++++++++++++++++UUUUU~~~~~~~~oooooo
    ko    2420     510     679     220  ++++++++++++++++++++UUUU~~~~~~o
    nb    2336     594     810     504  ++++++++++++++++++UUUUU~~~~~~~oooo
    pl    2361     569     778     302  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2118     812     988     323  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2757     173     366      84  +++++++++++++++++++++++++U~~~~
 zh_CN    2680     250     426      30  +++++++++++++++++++++++UUU~~~~
 zh_TW    2060     870    1024     379  +++++++++++++++UUUUUUU~~~~~~~~oo

Stefan Fuhrmann | 23 Mar 13:48 2015

FS API changes

Hi there,

As a result of the 1.9 API review, there are two changes,
I'd like to make to the FS API before releasing it.

1. Rename svn_fs_node_same (in svn_fs_node_relation_t)
   to svn_fs_node_unchanged. This captures the API user's
   intention and does not leak FS-internal concepts.

2. Make svn_fs_dir_optimal_order() use 2 pools arguments.
   New functions should comply with the 2-pool paradigm
   and this change is not complex.

If there are no objections, I'll commit those changes around
Thursday this week.

-- Stefan^2.
Chris | 23 Mar 10:43 2015
Picon

diff --summarize --ignore-properties

Hi,

searching for previous information on a problem I'm checking up on, I found the below discusion on this list:

http://subversion.1072662.n5.nabble.com/svn-diff-summarize-with-ignore-properties-or-properties-only-td192046.html
I apologize if this is the wrong list for posting this query, but figured I'd continue on the same list as the
above discussion.

Does the response on that thread indicate that this is not a bug and therefore will not be fixed/changed?
If so, that sounds very unfortunate as this seems to be causing users quite a bit of confusion. I'm admin for a
semi-large (company-internal) project running off subversion and I've had questions many times
related to why users are seeing files listed in the summarize-output and then when re-running the same
command without --summarize, those files don't appear in the diff.

That is, if
  svn diff --ignore-properties --summarize URL1 <at> X URL2 <at> Y
lists 10 files, then users would expect
  svn diff --ignore-properties  URL1 <at> X URL2 <at> Y
to also list those same 10 files and not be down to 1 if the other 9 were only propeties.

If it is so that summarize does not accept -ignore-properties and that's the intended behavior, then why
doesn't it throw an error message at the user when using these two flags together instead of silently
ignoring "--ignore-properties"?
Please consider either adding this "filtering", or an error message in future releases.

BR,
  Chris

James McCoy | 22 Mar 02:41 2015
Picon

[patch] Resolve pod2man warnings

There are a couple warnings in SVN::Core when using pod2man to generate
the man pages.  Patch below fixes this.

[[[
Add missing POD directives to resolve pod2man warnings

* subversion/bindings/swig/perl/native/Core.pm
  (svn_log_entry_t): Add missing "=over 4" and "=back" directives
]]]

[[[
Index: subversion/bindings/swig/perl/native/Core.pm
===================================================================
--- subversion/bindings/swig/perl/native/Core.pm	(revision 1668331)
+++ subversion/bindings/swig/perl/native/Core.pm	(working copy)
 <at>  <at>  -959,6 +959,8  <at>  <at> 

 =head2 svn_log_entry_t

+=over 4
+
 =item $entry-E<gt>revision()

 The revision of the commit.
 <at>  <at>  -988,6 +990,8  <at>  <at> 
 Whether C<$entry-E<gt>revision()> is a merged revision resulting 
 from a reverse merge.

+=back
+
 =cut

 package _p_svn_auth_cred_simple_t;
]]]

Cheers,
--

-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan <at> debian.org>
Johan Corveleyn | 20 Mar 10:30 2015
Picon

Handling non-reproducible test failures (was Re: 1.7.20 release candidates up for testing/signing)

On Fri, Mar 20, 2015 at 9:42 AM, Johan Corveleyn <jcorvel <at> gmail.com> wrote:
...
> Unfortunately, I can't verify the rev
> file, since I don't have it anymore, it has been overwritten by trying
> to reproduce it (grrrr, should remember to backup leftover
> repositories and working copies after a failed test run, before trying
> to reproduce it). Whatever I try now, I can't reproduce it anymore
> :-(.

I'm wondering if something can be improved in our test suite to help
diagnosis of hard-to-reproduce test failures. When this happens, you
typically wish you could analyse as much data as possible (i.e. the
potentially corrupt repository, working copy, dump file, ... that was
used in the test).

Currently, I can think of three causes for losing this information:

  1) You run a series of test runs in sequence from a script
(ra_local, ra_svn, ra_serf), all using the same target directory for
running the tests (R:\test in my case, where R: is a ram drive). If
something fails in ra_svn, but succeeds in ra_serf, your broken test
data is overwritten.

  2) You don't know in advance that the failure will turn out to be
non-reproducible. You can't believe your eyes, try to run it again to
be sure, and lo and behold, the test succeeds (and the broken test
data is overwritten), and succeeds ever since.

  3) Your test data is on a RAM drive, and you reboot or something. Or
you copy the data to a fixed disk afterwards, but lose a bit of
information because last-modified timestamps of the copied files are
reset by copying them between disks.

For 1, maybe the outer script could detect that ra_svn had a failure,
and stop there (does win-tests.py emit an exit code != 0 if there is a
test failure? That would make it easy. Otherwise the outer script
would have to parse the test summary output)?

Another option is to let every separate test run (ra_local, ra_svn,
ra_serf) use a distinct target test directory. But if you're running
them on a RAM disk, theoretically you might need three times the
storage (hm, maybe not, because --cleanup ensures that successful test
data is cleaned up, so as long as you don't run the three ways in
parallel, it should be fine). I guess I will do that already, and
adjust my script accordingly.

Addressing 2 seems harder. Can the second test execution, on
encountering stale test data, put that data aside instead of
overwriting it? Or maybe every test execution can use a unique naming
pattern (with a timestamp or a pid) so it doesn't overwrite previous
data? Both approaches would leak data from failed test runs of course,
but that's more or less the point. OTOH, you don't know that stale
test data is from a previous failed run, or from a successful run that
did not use --cleanup.

And 3, well, I already reboot as little as possible, so this is more
just a point of attention.

Maybe addressing all three at the same time could also be: after a
failed test run, automatically zip the test data and copy it to a safe
location (e.g. the user's home dir).

Thoughts?

--

-- 
Johan

Branko Čibej | 20 Mar 08:34 2015

Copyright year displayed by command-line tools

I just noticed that we forgot to bump the displayed copyright year.
Fixed in r1667941 and nominated for backport to 1.9.x, 1.8.x and 1.7.x.
I also vetoed the 1.7.20 and 1.8.13 releases because of the wrong year
... we really shouldn't release with wrong legalese, and we already
allowed 1.9.0-beta1 to slip through with that buglet.

Sorry about not noticing this earlier, I realize we already have enough
votes tor 1.7.20 and 1.8.13; but I really think we should pull these
tarballs.

-- Brane

Marc Strapetz | 19 Mar 11:43 2015

1.9 JavaHL memory leak in ISVNRemote#status

Attached example performs an endless series of remote status against the 
Subversion repository. When invoked with -Xmx24M, the VM will run out of 
memory soon. Monitoring with jvisualvm shows that the used heap size 
constantly grows. Monitoring with the Task Manager shows that the 
allocated memory grows even more (significantly). Looks like a memory 
leak, for which a large amount of native memory is involved, too.

Tested on Windows 8.1 with almost latest Subversion 1.9 JavaHL builds.

-Marc

import java.io.*;

import org.apache.subversion.javahl.*;
import org.apache.subversion.javahl.callback.*;
import org.apache.subversion.javahl.remote.*;
import org.apache.subversion.javahl.types.*;

public class RemoteStatusMain {

	// Static =================================================================

	public static void main(String[] args) throws Exception {
		final RemoteFactory remoteFactory = new RemoteFactory();
		for (;;) {
			System.out.println("\n\n\n");
			final ISVNRemote remote = remoteFactory.openRemoteSession("http://svn.apache.org/repos/asf/subversion/branches/1.8.x");
			try {
				final ISVNReporter status = remote.status("/", Revision.SVN_INVALID_REVNUM, Depth.infinity,
new MyRemoteStatus());
				try {
					status.setPath("", 1660000, Depth.infinity, false, null);
					status.finishReport();
				}
				finally {
					status.dispose();
				}
			}
			finally {
				remote.dispose();
			}
		}
	}

	// Inner Classes ==========================================================

	private static class MyRemoteStatus implements RemoteStatus {
		 <at> Override
		public void addedDirectory(String relativePath) {
			System.out.println("A D " + relativePath);
		}

		 <at> Override
		public void addedFile(String relativePath) {
			System.out.println("A F " + relativePath);
		}

		 <at> Override
		public void addedSymlink(String relativePath) {
			System.out.println("A S " + relativePath);
		}

		 <at> Override
		public void modifiedDirectory(String relativePath, boolean childrenModified, boolean
propsModified, Entry nodeInfo) {
			System.out.println("M D " + relativePath + " " + childrenModified + " " + propsModified);
		}

		 <at> Override
		public void modifiedFile(String relativePath, boolean textModified, boolean propsModified, Entry
nodeInfo) {
			System.out.println("M F " + relativePath + " " + textModified + " " + propsModified);
		}

		 <at> Override
		public void modifiedSymlink(String relativePath, boolean targetModified, boolean propsModified,
Entry nodeInfo) {
			System.out.println("M S " + relativePath + " " + relativePath + " " + targetModified);
		}

		 <at> Override
		public void deleted(String relativePath) {
			System.out.println("D   " + relativePath);
		}
	}
}
Ben Reser | 19 Mar 04:57 2015
Picon

Apache Subversion 1.9.0-beta1 released

I'm happy to announce the release of Apache Subversion 1.9.0-beta1.
Please choose the mirror closest to you by visiting:

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

The SHA1 checksums are:

    cbc62b682e69254f57e40da316ebb7fcf998f56e subversion-1.9.0-beta1.tar.bz2
    57142f460c51f334429569757974006f275240e8 subversion-1.9.0-beta1.tar.gz
    66d84c7818d05141e795ed090dba3044c880f6ca subversion-1.9.0-beta1.zip

PGP Signatures are available at:

    http://www.apache.org/dist/subversion/subversion-1.9.0-beta1.tar.bz2.asc
    http://www.apache.org/dist/subversion/subversion-1.9.0-beta1.tar.gz.asc
    http://www.apache.org/dist/subversion/subversion-1.9.0-beta1.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
   Branko Čibej [4096R/A347943F] with fingerprint:
    BA3C 15B1 337C F0FB 222B  D41A 1BCA 6586 A347 943F
   Julian Foad [4096R/4EECC493] with fingerprint:
    6011 63CF 9D49 9FD7 18CF  582D 1FB0 64B8 4EEC C493
   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

This is a pre-release for what will eventually become Apache Subversion
1.9.0.  It may contain known issues, a complete list of
1.9.0-blocking issues can be found here:

http://subversion.tigris.org/issues/buglist.cgi?component=subversion&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&target_milestone=1.9.0

A pre-release means the Subversion developers feel that this release
is ready for widespread testing by the community.  There are known issues
(and unknown ones!), so please use it at your own risk, though we do
encourage people to test this release thoroughly.  Of particular note, please
remember than persistent data, such as the working copy or repository
formats may change before the final release, and there may not be an
upgrade path from the pre-releases to the final.

As a note to operating system distro packagers: while we wish to have this
release candidate widely tested, we do not feel that it is ready for packaging
and providing to end-users through a distro package system.  Packaging a
release candidate poses many problems, the biggest being that our policy lets
us break compatibility between the release candidate and the final release, if
we find something serious enough.  Having many users depending on a release
candidate through their distro would cause no end of pain and frustration that
we do not want to have to deal with.  However, if your distro has a branch that
is clearly labeled as containing experimental and often broken software, and
explicitly destined to consenting developers and integrators only, then we're
okay with packaging the release candidate there.  Just don't let it near the
end users please.

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

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

You can find the list of changes between 1.9.0-beta1 and earlier versions at:

    http://svn.apache.org/repos/asf/subversion/tags/1.9.0-beta1/CHANGES

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

Thanks,
- The Subversion Team

Stefan Sperling | 18 Mar 15:09 2015
Picon

1.7.20 release candidates up for testing/signing

The 1.7.20 release is now up for testing/signing at
https://dist.apache.org/repos/dist/dev/subversion
Please add your signatures there.

The anticipated release day is March 31.

Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures
(segfaults) due to a one-byte read past a string buffer (which cause a crash
on OpenBSD and maybe on other platforms as well).
This is not a regression from 1.7.19 where the problem already existed.

Stefan Sperling | 18 Mar 15:04 2015
Picon

1.8.13 release up for testing/signing

The 1.8.13 release is now up for testing/signing at
https://dist.apache.org/repos/dist/dev/subversion
Please add your signatures there.
The anticipated release day is March 31.

Note that the 1.8.12 release was tagged and then skipped because of failures
in diff_tests.py. These are resolved in 1.8.13.


Gmane