Re: Data corruption bug in WC, apparently due to race condition?

2017-07-26 Thread Karl Fogel
A bit more info, following up to my previous mail: In the transcript in my previous mail, at the end I move the corrupt file out of the way and do 'svn up' to restore a good copy from the repository. FWIW, the restoration worked: $ cp main.org real-main.org $ cp was-local-main.org main.org

Data corruption bug in WC, apparently due to race condition?

2017-07-26 Thread Karl Fogel
This is with stock SVN version 1.9.6 (r1800392) as packaged in Debian GNU/Linux 'testing' distro, compiled Jul 22 2017, 06:41:45 on x86_64-pc-linux-gnu. (I dist-upgraded from the Debian package tree this morning, FWIW.) I think I've encountered a data corruption bug due to a race condition som

Re: Checkpointing mock-up option 3 (backed by a local repo)

2017-07-26 Thread Julian Foad
Nathan Hartman wrote: > Julian Foad wrote: > I committed an initial prototype for checkpointing backed by a local > repo embedded in the WC (the "option 3" design), on the > "shelve-checkpoint3" branch. > > http://svn.apache.org/r1803046 and follow-ups. > > Woohoo! Very exciting!

Re: [PATCH] 1.10 relnotes lz4 compatibility summary

2017-07-26 Thread Evgeny Kotkov
Daniel Shahaf writes: > Evgeny, WDYT? > > [[[ > * docs/release-notes/1.10.html > (#new-feature-compatibility-table): Split the lz4 entry to match > the implementation. > ]]] Looks good, +1. Regards, Evgeny Kotkov

[PATCH] 1.10 relnotes lz4 compatibility summary

2017-07-26 Thread Daniel Shahaf
Evgeny, WDYT? [[[ * docs/release-notes/1.10.html (#new-feature-compatibility-table): Split the lz4 entry to match the implementation. ]]] [[[ Index: publish/docs/release-notes/1.10.html === --- publish/docs/release-notes/1.10.h

Re: Checkpointing mock-up option 3 (backed by a local repo)

2017-07-26 Thread Nathan Hartman
On Wed, Jul 26, 2017 at 11:13 AM, Julian Foad wrote: > I committed an initial prototype for checkpointing backed by a local > repo embedded in the WC (the "option 3" design), on the > "shelve-checkpoint3" branch. > > http://svn.apache.org/r1803046 and follow-ups. > Woohoo! Very exciting! I didn

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Philip Martin
Evgeny Kotkov writes: > on my todo list. In the meanwhile, if someone could jump in and help with > the necessary changes to the Makefiles and etc., that would be greatly > appreciated. Patch in preparation... -- Philip

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Evgeny Kotkov
Stefan Sperling writes: > That's not what is being proposed. It's fine if the build can optionally > use a copy provided by the user, or even a copy embedded in our code. > But using that internal copy should not be mandatory. I could have misinterpreted one of the previous e-mails, as I was thi

[ANNOUNCE] Apache Subversion 1.10.0-alpha3 released

2017-07-26 Thread Daniel Shahaf
I'm happy to announce the release of Apache Subversion 1.10.0-alpha3. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download.cgi#pre-releases The SHA1 checksums are: 26522a1fa708ecaa9684b41065db8d6a02dbc098 subversion-1.10.0-alpha3.tar.gz d39ac7b98

Should pre-releases be indicated in doap.rdf?

2017-07-26 Thread Daniel Shahaf
Should 1.10.0-alpha3 be added to ? HACKING doesn't say. Datapoint: the upstream schema has no machine-readable "beta" indicator (that I can see): http://usefulinc.com/ns/doap In the meantime, I _won't_ add alpha3, because of precedent and because I don't wa

Re: 1.10.0-alpha3 queued

2017-07-26 Thread Evgeny Kotkov
Daniel Shahaf writes: > The text LGTM and it fits well in the flow. I might've used a box for it, > but I suppose the tag does the job just as well. (The thinking being > to make the warning stand out for users who skip the #compatibility > section, which hasn't changed in years.) I tend to t

Checkpointing mock-up option 3 (backed by a local repo)

2017-07-26 Thread Julian Foad
I committed an initial prototype for checkpointing backed by a local repo embedded in the WC (the "option 3" design), on the "shelve-checkpoint3" branch. http://svn.apache.org/r1803046 and follow-ups. Here is the help output: [[[ $ svn checkpoint --help checkpoint: Checkpoint the local changes. u

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Philip Martin
Stefan Sperling writes: > Who will be blamed if, in the future, a package manager for some Linux/BSD > system fixes an exploitable bug in lz4, and accidentally leaves some systems > vulnerable because of a missing patch to SVN's internal copy? Let us consider Subversion's embedded utf8proc. How

Re: 1.10.0-alpha3 queued

2017-07-26 Thread Daniel Shahaf
Evgeny Kotkov wrote on Wed, 26 Jul 2017 17:51 +0300: > How about we mention this change in how 'svnadmin create' behaves, > and also duplicate the warning about the no-upgrade-path policy for > pre-releases? > > +++ publish/docs/release-notes/1.10.html(working copy) > @@ -82,6 +82,14 @@ Su

Re: 1.10.0-alpha3 queued

2017-07-26 Thread Evgeny Kotkov
Daniel Shahaf writes: > With my RM hat off, the text LGTM except that I think #fsfs-format8 > should be mentioned under the #compatibility heading or linked from it, > since the behaviour of 'svnadmin create' (without --compatible-version) > has changed even for people who are agnostic to the lz4

Re: 1.10.0-alpha3 queued

2017-07-26 Thread Daniel Shahaf
Evgeny Kotkov wrote on Wed, 26 Jul 2017 17:17 +0300: > Daniel Shahaf writes: > > >> In particular I'd like to call out the FSFS f8 change. The email > >> announcement already mentions that we do not promise an upgrade path for > >> on-disk repositories to 1.10.0, but the release notes do not; I

Re: svn commit: r1803053 - /subversion/trunk/subversion/svn/svn.c

2017-07-26 Thread Stefan Sperling
On Wed, Jul 26, 2017 at 02:14:36PM -, danie...@apache.org wrote: > Author: danielsh > Date: Wed Jul 26 14:14:36 2017 > New Revision: 1803053 > > URL: http://svn.apache.org/viewvc?rev=1803053&view=rev > Log: > * subversion/svn/svn.c > (svn_cl__cmd_table."cleanup"): Edit the help text so it is

Re: 1.10.0-alpha3 queued

2017-07-26 Thread Evgeny Kotkov
Daniel Shahaf writes: >> In particular I'd like to call out the FSFS f8 change. The email >> announcement already mentions that we do not promise an upgrade path for >> on-disk repositories to 1.10.0, but the release notes do not; I think it >> would be good to have the release notes say that. >

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Stefan Sperling
On Wed, Jul 26, 2017 at 03:48:33PM +0300, Evgeny Kotkov wrote: > Stefan Sperling writes: > > >> The way the lz4 code is currently embedded in libsvn_subr makes it > >> awkward to add support for an external liblz4. > > > > I agree that an external library should be used during the build. > > It m

jira filter for 1.10.0-pending issues (was: svn commit: r1803045 - /subversion/trunk/tools/dist/templates/rc-release-ann.ezt)

2017-07-26 Thread Daniel Shahaf
danie...@apache.org wrote on Wed, 26 Jul 2017 13:37 +: > +++ subversion/trunk/tools/dist/templates/rc-release-ann.ezt Wed Jul 26 > 13:37:18 2017 > @@ -31,7 +31,7 @@ Apache Subversion open source version co > - > http://subversion.tigris.org/issues/buglist.cgi?component=subversion&issue_sta

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Daniel Shahaf
Evgeny Kotkov wrote on Wed, 26 Jul 2017 15:48 +0300: > And building using an embedded copy of the source isn't something new, > as we already do that for utf8proc and with sqlite-amalgamation. utf8proc is indeed a precedent, but sqlite is not. - We support linking against an external sqlite lib t

Re: 1.10.0-alpha3 queued

2017-07-26 Thread Daniel Shahaf
Daniel Shahaf wrote on Tue, 25 Jul 2017 12:27 +: > In particular I'd like to call out the FSFS f8 change. The email > announcement already mentions that we do not promise an upgrade path for > on-disk repositories to 1.10.0, but the release notes do not; I think it > would be good to have the

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Evgeny Kotkov
Stefan Sperling writes: >> The way the lz4 code is currently embedded in libsvn_subr makes it >> awkward to add support for an external liblz4. > > I agree that an external library should be used during the build. > It makes life a lot easier for packagers on Unix-style systems, > and is the expe

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Stefan Sperling
On Wed, Jul 26, 2017 at 12:36:05PM +0100, Philip Martin wrote: > Philip Martin writes: > > > $ pkg-config lz4 --libs > > -llz4 > > Typo, that should be > > pkg-config liblz4 --libs > > The way the lz4 code is currently embedded in libsvn_subr makes it > awkward to add support for an

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Stefan Sperling
On Wed, Jul 26, 2017 at 02:41:31PM +0300, Evgeny Kotkov wrote: > Stefan Sperling writes: > > > Sounds like we're headed in a good direction :-) > > One particular thing that bothers me about using LZ4 as the new default > is that I think that a decision like that goes a bit against the usual pol

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Evgeny Kotkov
Stefan Sperling writes: > Sounds like we're headed in a good direction :-) One particular thing that bothers me about using LZ4 as the new default is that I think that a decision like that goes a bit against the usual policy (add new optional feature, switch the default in the next minor release

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Philip Martin
Philip Martin writes: > $ pkg-config lz4 --libs > -llz4 Typo, that should be pkg-config liblz4 --libs The way the lz4 code is currently embedded in libsvn_subr makes it awkward to add support for an external liblz4. -- Philip

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Stefan Sperling
On Wed, Jul 26, 2017 at 01:18:00PM +0300, Evgeny Kotkov wrote: > Stefan Sperling writes: > > > Does mod_dav_svn really need an option for this? > > > > Can't lz4 (svndiff2) be negotiated as a mutual protocol capability of > > client and server? Why won't a simple logic such as the following work:

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Philip Martin
kot...@apache.org writes: > Author: kotkov > Date: Fri Jul 14 11:13:47 2017 > New Revision: 1801940 > > URL: http://svn.apache.org/viewvc?rev=1801940&view=rev > Log: > fsfs: Add initial support for LZ4 compression. > * build.conf > (libsvn_subr): Build LZ4 library sources. Why do we have an em

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Evgeny Kotkov
Stefan Sperling writes: > Does mod_dav_svn really need an option for this? > > Can't lz4 (svndiff2) be negotiated as a mutual protocol capability of > client and server? Why won't a simple logic such as the following work: > > If the client announces lz4 compression level 1 support, use it. >

Re: LZ4 compression

2017-07-26 Thread Stefan Sperling
On Mon, Jul 17, 2017 at 02:54:59PM +0200, Evgeny Kotkov wrote: > https://svn.apache.org/r1801974 adds negotiation and support for LZ4 in > mod_dav_svn and in ra_serf. Except for the PUT requests, which require a > couple of tweaks to the negotiation scheme, with this change svndiff2 with > LZ4 wil

Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/ subversion/include/ subversion/include/private/ subversion/libsvn_delta/ subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/li

2017-07-26 Thread Stefan Sperling
On Mon, Jul 24, 2017 at 07:19:09PM +0300, Evgeny Kotkov wrote: > However, there are a couple of difficulties with porting this approach to > mod_dav_svn, i.e., if we introduce the SVNCompression directive. There > are clients that don't use LZ4, so, presumably, this options would require > specify