Re: svn commit: r1785754 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_fs_fs/cached_data.c libsvn_fs_fs/cached_data.h libsvn_fs_fs/transaction.c tests/libsvn_fs/fs-test.c

[Daniel Shahaf]

stef...@apache.org wrote on Mon, Mar 06, 2017 at 19:53:55 -:
> Author: stefan2
> Date: Mon Mar  6 19:53:55 2017
> New Revision: 1785754
> 
> URL: http://svn.apache.org/viewvc?rev=1785754=rev
> Log:
> Make FSFS consistency no longer depend on hash algorithms.

First of all, thanks for fixing this.

I didn't do a full review with out-of-diff context, but I did spot two
issues:

> +++ subversion/trunk/subversion/libsvn_fs_fs/transaction.c Mon Mar  6 
> 19:53:55 2017
> @@ -2385,6 +2392,78 @@ get_shared_rep(representation_t **old_re
> +  /* The existing representation may itsel be part of the current

Typo: "itsel".

> +  /* Compare the two representations.
> +   * Note that the stream comparison might also produce MD5 checksum
> +   * errors or other failures in case of SHA1 collisions. */
> +  SVN_ERR(svn_fs_fs__get_contents_from_file(, fs, rep, file,
> +offset, scratch_pool));
> +  SVN_ERR(svn_fs_fs__get_contents(_contents, fs, _rep_norm,
> +  FALSE, scratch_pool));
> +  err = svn_stream_contents_same2(, contents, old_contents,
> +  scratch_pool);
> +
> +  /* Restore FILE's read / write position. */
> +  SVN_ERR(svn_io_file_seek(file, APR_SET, _position, scratch_pool));

Leaks 'err'.

Cheers,

Daniel

Re: svn commit: r1785734 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

[Daniel Shahaf]

stef...@apache.org wrote on Mon, Mar 06, 2017 at 19:05:45 -:
> +static svn_error_t *
> +test_rep_sharing_strict_content_check(const svn_test_opts_t *opts,
> +  apr_pool_t *pool)
> +{
> +  /* Bail (with success) on known-untestable scenarios */
> +  if (strcmp(opts->fs_type, SVN_FS_TYPE_BDB) == 0)
> +return svn_error_create(SVN_ERR_TEST_SKIPPED, NULL,
> +"this will not test BDB repositories");

Minor point: the log message^W^W skip message should answer "Why", not
"What".  Suggestion:

"bdb does not have a rep-cache"

Re: Suspected issue with "remove-zombie-locks.py"?

[Doug Robinson]

Daniel:

https://issues.apache.org/jira/browse/SVN-4674

Thank you.

Doug

On Mon, Mar 6, 2017 at 11:06 AM, Daniel Shahaf 
wrote:

> Doug Robinson wrote on Mon, Mar 06, 2017 at 10:15:04 -0500:
> >
> > Doug Robinson  wrote:
> > > Traceback (most recent call last):
> > >
> > >   File "hook-scripts/remove-zombie-locks.py", line 214, in 
> > >
> > > main()
> > >
> > >   File "hook-scripts/remove-zombie-locks.py", line 208, in main
> > >
> > > remover.run()
> > >
> > >   File "hook-scripts/remove-zombie-locks.py", line 138, in run
> > >
> > > self.unlock_nonexistent_files, self.pool)
> > >
> > >   File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/
> libsvn/fs.py",
> > > line 860, in svn_fs_get_locks2
> > >
> > > return _fs.svn_fs_get_locks2(*args)
> > >
> > > svn.core.SubversionException: 160034 - No username is currently
> associated
> > > with filesystem 'd52a5571-d2a3-4db8-a9e5-a081d6b4b455'
>
> I can reproduce this using the FS API only (without the contrib/ script):
>
> % python2
> >>> from svn.core import *
> >>> from svn.fs import *
> >>> from __future__ import print_function
> >>> fs = svn_fs_open("r/db", None)
> >>> svn_fs_get_locks2(fs, "", svn_depth_infinity, print)
>  >  >
> >>> svn_fs_get_locks2(fs, "", svn_depth_infinity, (lambda lock, pool:
> svn_fs_unlock(fs, lock.path, lock.token, True, pool)))
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/libsvn/fs.py", line 876, in
> svn_fs_get_locks2
> return _fs.svn_fs_get_locks2(*args)
> svn.core.SubversionException: 160034 - No username is currently associated
> with filesystem 'a1257b00-ab15-4056-8430-3a7080d0ccfe'
>
> > I realize that the SHA1-collision issues are consuming most of the duty
> > cycles at this point.  Before I forget about this one - should I file a
> bug?
>
> Yes, please.
>
> Thanks,
>
> Daniel
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: Suspected issue with "remove-zombie-locks.py"?

[Daniel Shahaf]

Stefan Sperling wrote on Mon, Mar 06, 2017 at 17:22:14 +0100:
> On Mon, Mar 06, 2017 at 04:06:44PM +, Daniel Shahaf wrote:
> > I can reproduce this using the FS API only (without the contrib/ script):
> 
> Hmm, looks like the contrib script is using the API wrong.
> Check out what 'svnadmin unlock' does:
> [[[
>   /* Open the repos/FS, and associate an access context containing
>  USERNAME. */
>   SVN_ERR(open_repos(, opt_state->repository_path, opt_state, pool));
>   fs = svn_repos_fs(repos);
>   SVN_ERR(svn_fs_create_access(, username, pool));
>   SVN_ERR(svn_fs_set_access(fs, access));
> 
>   SVN_ERR(svn_utf_cstring_to_utf8(_path_utf8, lock_path, pool));
>   if (opt_state->bypass_hooks)
> SVN_ERR(svn_fs_unlock(fs, lock_path_utf8, lock_token,
>   FALSE, pool));
>   else
> SVN_ERR(svn_repos_fs_unlock(repos, lock_path_utf8, lock_token,
> FALSE, pool));
> ]]]
> 
> The script should probably be doing something like this, too.

I don't think so.  The documentation of svn_fs_unlock() points to
the documentation of svn_fs_unlock_many(), which states:

 * If @a fs has no username associated with it, yield an
 * #SVN_ERR_FS_NO_USER (E160034) unless @a break_lock is specified.

The reproductions pass break_lock=True, so shouldn't get that error.

Cheers,

Daniel

> Doug, I believe filing a bug is entirely appropriate here. Thanks!

Re: Suspected issue with "remove-zombie-locks.py"?

[Stefan Sperling]

On Mon, Mar 06, 2017 at 05:22:14PM +0100, Stefan Sperling wrote:
> On Mon, Mar 06, 2017 at 04:06:44PM +, Daniel Shahaf wrote:
> > I can reproduce this using the FS API only (without the contrib/ script):
> 
> Hmm, looks like the contrib script is using the API wrong.
> Check out what 'svnadmin unlock' does:
> [[[
>   /* Open the repos/FS, and associate an access context containing
>  USERNAME. */
>   SVN_ERR(open_repos(, opt_state->repository_path, opt_state, pool));
>   fs = svn_repos_fs(repos);
>   SVN_ERR(svn_fs_create_access(, username, pool));
>   SVN_ERR(svn_fs_set_access(fs, access));
> 
>   SVN_ERR(svn_utf_cstring_to_utf8(_path_utf8, lock_path, pool));
>   if (opt_state->bypass_hooks)
> SVN_ERR(svn_fs_unlock(fs, lock_path_utf8, lock_token,
>   FALSE, pool));
>   else
> SVN_ERR(svn_repos_fs_unlock(repos, lock_path_utf8, lock_token,
> FALSE, pool));
> ]]]
> 
> The script should probably be doing something like this, too.

This problem with 'svnadmin load' might also be caused by wrong use
of the API: https://issues.apache.org/jira/browse/SVN-4030
I have not checked the details, though. But if anybody is fixing the script,
consider taking a look at issue #4030 as well while the context is fresh.

Re: Suspected issue with "remove-zombie-locks.py"?

[Stefan Sperling]

On Mon, Mar 06, 2017 at 04:06:44PM +, Daniel Shahaf wrote:
> I can reproduce this using the FS API only (without the contrib/ script):

Hmm, looks like the contrib script is using the API wrong.
Check out what 'svnadmin unlock' does:
[[[
  /* Open the repos/FS, and associate an access context containing
 USERNAME. */
  SVN_ERR(open_repos(, opt_state->repository_path, opt_state, pool));
  fs = svn_repos_fs(repos);
  SVN_ERR(svn_fs_create_access(, username, pool));
  SVN_ERR(svn_fs_set_access(fs, access));

  SVN_ERR(svn_utf_cstring_to_utf8(_path_utf8, lock_path, pool));
  if (opt_state->bypass_hooks)
SVN_ERR(svn_fs_unlock(fs, lock_path_utf8, lock_token,
  FALSE, pool));
  else
SVN_ERR(svn_repos_fs_unlock(repos, lock_path_utf8, lock_token,
FALSE, pool));
]]]

The script should probably be doing something like this, too.

Doug, I believe filing a bug is entirely appropriate here. Thanks!

Re: Suspected issue with "remove-zombie-locks.py"?

[C. Michael Pilato]

Yes, please do.

On 03/06/2017 10:15 AM, Doug Robinson wrote:
> Folks:
>
> I realize that the SHA1-collision issues are consuming most of the
> duty cycles at this point.  Before I forget about this one - should I
> file a bug?
>
> Cheers!
>
> Doug
>
> On Thu, Mar 2, 2017 at 8:19 AM, Doug Robinson
> > wrote:
>
> Folks:
>
> The following commands were run on a CentOS 6.x, WANdisco
> Subversion 1.9.5, Python 2.7:
> 
> --
> # svn
> export 
> https://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts
> 
> # svnadmin create repo
> # svn co file:///path/to/repo wc
> # cd wc
> # touch wc/a; svn add wc/a; svn ci -mm wc
> # svn lock wc/a; svn rm wc/a; svn ci -mm --no-unlock wc
> # hook-scripts/remove-zombie-locks.py repo1 all
>
> Removing all zombie locks from repository at /root/repo
>
> This may take several minutes...
>
> /a
>
> Traceback (most recent call last):
>
>   File "hook-scripts/remove-zombie-locks.py", line 214, in 
>
> main()
>
>   File "hook-scripts/remove-zombie-locks.py", line 208, in main
>
> remover.run()
>
>   File "hook-scripts/remove-zombie-locks.py", line 138, in run
>
> self.unlock_nonexistent_files, self.pool)
>
>   File
> "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/libsvn/fs.py",
> line 860, in svn_fs_get_locks2
>
> return _fs.svn_fs_get_locks2(*args)
>
> svn.core.SubversionException: 160034 - No username is currently
> associated with filesystem 'd52a5571-d2a3-4db8-a9e5-a081d6b4b455'
>
> 
> --
>
>
> Is this a known issue?  Or should I file a bug?
>
>
> Thank you.
>
>
> Doug
> -- 
> *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
>
> *T *925-396-1125
> *E* doug.robin...@wandisco.com 
>
> *www.wandisco.com *
> *
> *
> **
>
>
>
>
> -- 
> *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
>
> *T *925-396-1125
> *E* doug.robin...@wandisco.com 
>
> *www.wandisco.com *
> *
> *
> **
>
> Learn how WANdisco Fusion solves Hadoop data protection and
> scalability challenges 
>
> Listed on the London Stock Exchange: WAND
> 
>
> THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND
> MAY BE PRIVILEGED.  If this message was misdirected, WANdisco, Inc.
> and its subsidiaries, ("WANdisco") does not waive any confidentiality
> or privilege.  If you are not the intended recipient, please notify us
> immediately and destroy the message without disclosing its contents to
> anyone.  Any distribution, use or copying of this e-mail or the
> information it contains by other than an intended recipient is
> unauthorized.  The views and opinions expressed in this e-mail message
> are the author's own and may not reflect the views and opinions of
> WANdisco, unless the author is authorized by WANdisco to express such
> views or opinions on its behalf.  All email sent to or from this
> address is subject to electronic storage and review by WANdisco.
>  Although WANdisco operates anti-virus programs, it does not accept
> responsibility for any damage whatsoever caused by viruses being passed.
>

'svn lock -q' (was: Suspected issue with "remove-zombie-locks.py"?)

[Daniel Shahaf]

Daniel Shahaf wrote on Mon, Mar 06, 2017 at 16:06:44 +:
> I can reproduce this using the FS API only (without the contrib/ script):

While reproducing this I ran into:

% svn lock -q a
Subcommand 'lock' doesn't accept option '-q [--quiet]'
Type 'svn help lock' for usage.

I assume the following will fix it, but I don't have a build environment
so I can't test it.

[[[
Index: subversion/svn/svn.c
===
--- subversion/svn/svn.c(revision 1785678)
+++ subversion/svn/svn.c(working copy)
@@ -807,7 +807,7 @@ const svn_opt_subcommand_desc2_t svn_cl__cmd_table
  "usage: lock TARGET...\n"
  "\n"
  "  Use --force to steal the lock from another user or working copy.\n"),
-{ opt_targets, 'm', 'F', opt_force_log, opt_encoding, opt_force },
+{ opt_targets, 'q', 'm', 'F', opt_force_log, opt_encoding, opt_force },
 {{'F', N_("read lock comment from file ARG")},
  {'m', N_("specify lock comment ARG")},
  {opt_force_log, N_("force validity of lock comment source")}} },
]]]

Cheers,

Daniel

Re: Suspected issue with "remove-zombie-locks.py"?

[Daniel Shahaf]

Doug Robinson wrote on Mon, Mar 06, 2017 at 10:15:04 -0500:
> 
> Doug Robinson  wrote:
> > Traceback (most recent call last):
> >
> >   File "hook-scripts/remove-zombie-locks.py", line 214, in 
> >
> > main()
> >
> >   File "hook-scripts/remove-zombie-locks.py", line 208, in main
> >
> > remover.run()
> >
> >   File "hook-scripts/remove-zombie-locks.py", line 138, in run
> >
> > self.unlock_nonexistent_files, self.pool)
> >
> >   File 
> > "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/libsvn/fs.py",
> > line 860, in svn_fs_get_locks2
> >
> > return _fs.svn_fs_get_locks2(*args)
> >
> > svn.core.SubversionException: 160034 - No username is currently associated
> > with filesystem 'd52a5571-d2a3-4db8-a9e5-a081d6b4b455'

I can reproduce this using the FS API only (without the contrib/ script):

% python2
>>> from svn.core import *
>>> from svn.fs import *
>>> from __future__ import print_function
>>> fs = svn_fs_open("r/db", None)
>>> svn_fs_get_locks2(fs, "", svn_depth_infinity, print) 
 
>>> svn_fs_get_locks2(fs, "", svn_depth_infinity, (lambda lock, pool: 
>>> svn_fs_unlock(fs, lock.path, lock.token, True, pool)))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/libsvn/fs.py", line 876, in 
svn_fs_get_locks2
return _fs.svn_fs_get_locks2(*args)
svn.core.SubversionException: 160034 - No username is currently associated with 
filesystem 'a1257b00-ab15-4056-8430-3a7080d0ccfe'

> I realize that the SHA1-collision issues are consuming most of the duty
> cycles at this point.  Before I forget about this one - should I file a bug?

Yes, please.

Thanks,

Daniel

Re: Suspected issue with "remove-zombie-locks.py"?

[Doug Robinson]

Folks:

I realize that the SHA1-collision issues are consuming most of the duty
cycles at this point.  Before I forget about this one - should I file a bug?

Cheers!

Doug

On Thu, Mar 2, 2017 at 8:19 AM, Doug Robinson 
wrote:

> Folks:
>
> The following commands were run on a CentOS 6.x, WANdisco Subversion
> 1.9.5, Python 2.7:
> 
> --
> # svn export https://svn.apache.org/repos/asf/subversion/trunk/con
> trib/hook-scripts
> # svnadmin create repo
> # svn co file:///path/to/repo wc
> # cd wc
> # touch wc/a; svn add wc/a; svn ci -mm wc
> # svn lock wc/a; svn rm wc/a; svn ci -mm --no-unlock wc
> # hook-scripts/remove-zombie-locks.py repo1 all
>
> Removing all zombie locks from repository at /root/repo
>
> This may take several minutes...
>
> /a
>
> Traceback (most recent call last):
>
>   File "hook-scripts/remove-zombie-locks.py", line 214, in 
>
> main()
>
>   File "hook-scripts/remove-zombie-locks.py", line 208, in main
>
> remover.run()
>
>   File "hook-scripts/remove-zombie-locks.py", line 138, in run
>
> self.unlock_nonexistent_files, self.pool)
>
>   File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/libsvn/fs.py",
> line 860, in svn_fs_get_locks2
>
> return _fs.svn_fs_get_locks2(*args)
>
> svn.core.SubversionException: 160034 - No username is currently associated
> with filesystem 'd52a5571-d2a3-4db8-a9e5-a081d6b4b455'
>
> 
> --
>
>
> Is this a known issue?  Or should I file a bug?
>
>
> Thank you.
>
>
> Doug
> --
> *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
>
> *T *925-396-1125
> *E* doug.robin...@wandisco.com
>
> *www.wandisco.com *
>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: 1.10.0-alpha2 is up for signing

[Stefan Sperling]

On Mon, Mar 06, 2017 at 01:19:00PM +, Daniel Shahaf wrote:
> I think there are two separate questions here:
> 
> - Should we release alpha2
> 
> - Should we release alpha3 with sha1 fixes
> 
> I'm happy to join the consensus and +1 the latter.  However, I also +1
> the former.  I don't see a reason to hold alpha2: it is rolled, it is
> voted on, and being an alpha it comes with no compatibility strings
> attached.  So I lean on the side on releasing alpha2 and indicating in
> the release announcement (the mail to announce@ and the index.html
> blurb) and an alpha3 is expected within ${timeframe} that will include
> sha1 fixes.

Yes, we could do this, but...

The alpha release should be very attractive so that people will be
inclined to test it. Release announcements are the largest part of
our communication to the public. I believe the public is waiting for
SHA1 fixes from us because that problem was the latest thing they saw
in the news. An outdated alpha 2 release today would seem disappointing
compared to an alpha 3 next month which contains the same nice things
and contains SHA1 fixes, too.

> > Apart from the server-side fix(es), I was under the impression that
> > the working copy also needed fixing (being able to store collisions in
> > the pristine store), and perhaps the ra_serf protocol?
> 
> And 'svnadmin load' — but why should we wait for all these to be
> written?  It's not a release candidate, it's just an alpha, and we do

Agreed that for an alpha it does not matter how many SHA1 issues we fix.
But I hope we can manage to provide a set of fixes in the next 1.8/1.9
patch releases to eliminate most concerns users may have about SHA1 issues.

The fact that 'svnadmin load' breaks if someone manages to commit these
PDF files makes me nervous because many users rely on 'svnadmin load' to
restore backups. SVN's reliability track record is a very strong selling
point and we should not gamble with that.

> have features that we want users to test (stsp's conflicts work).

We don't need these test results tomorrow. Within the next 2 or 3 months
works just fine. I think the SHA1 issues require more immediate attention
because they negatively affect the public's perception of Subversion.
The conflict code won't run away and will improve over time in any case.

Re: 1.10.0-alpha2 is up for signing

[Daniel Shahaf]

Johan Corveleyn wrote on Mon, Mar 06, 2017 at 12:52:03 +0100:
> On Mon, Mar 6, 2017 at 12:39 PM, Branko Čibej  wrote:
> > On 06.03.2017 12:27, Stefan Fuhrmann wrote:
> >> On 06.03.2017 10:38, Stefan Sperling wrote:
> >>> On Tue, Feb 21, 2017 at 01:54:15PM +0100, Stefan Sperling wrote:
>  The new 1.10.1-alpha2 release is up for signing.
> 
>  The proposed 1.10.0-alpha1 release had a compilation problem on
>  Windows.
>  The alpha2 release should fix this problem. It is based on
>  trunk@r1783880.
> 
>  Full committers, please get this release from
>  https://dist.apache.org/repos/dist/dev/subversion
>  and add your signatures there.
> 
>  Thank you!
> >>> I am on the fence about actually releasing 1.10.0-alpha2.
> >>>
> >>> I am a bit worried about announcing a new 1.8/1.9/1.10 release which
> >>> does
> >>> not address any SHA1 issues. And I believe that 1.10 should do something
> >>> meaningful about SHA1 so the alpha is not feature complete and feels
> >>> premature.
> >>>
> >>> Does anyone share these concerns? If not, I can release alpha2 this
> >>> week.
> >>>
> >> FWIW, the server-side fixes for FSFS should go up tonight.
> >> FSX should follow soon and BDB is not affected, IIRC.
> >
> > We never implemented rep sharing for BDB.
> >
> >> I think alpha3 would be a good idea. It would also fix the
> >> svnconflict.c compilation issue making this a more
> >> "rounded" release.
> >
> > +1
> 
> Agreed, addressing the SHA1 issues sounds important enough to wait
> with the alpha until we have some meaningful fixes in there.
> 

I think there are two separate questions here:

- Should we release alpha2

- Should we release alpha3 with sha1 fixes

I'm happy to join the consensus and +1 the latter.  However, I also +1
the former.  I don't see a reason to hold alpha2: it is rolled, it is
voted on, and being an alpha it comes with no compatibility strings
attached.  So I lean on the side on releasing alpha2 and indicating in
the release announcement (the mail to announce@ and the index.html
blurb) and an alpha3 is expected within ${timeframe} that will include
sha1 fixes.

> Apart from the server-side fix(es), I was under the impression that
> the working copy also needed fixing (being able to store collisions in
> the pristine store), and perhaps the ra_serf protocol?

And 'svnadmin load' — but why should we wait for all these to be
written?  It's not a release candidate, it's just an alpha, and we do
have features that we want users to test (stsp's conflicts work).

Cheers,

Daniel

Re: 1.10.0-alpha2 is up for signing

[Johan Corveleyn]

On Mon, Mar 6, 2017 at 12:39 PM, Branko Čibej  wrote:
> On 06.03.2017 12:27, Stefan Fuhrmann wrote:
>> On 06.03.2017 10:38, Stefan Sperling wrote:
>>> On Tue, Feb 21, 2017 at 01:54:15PM +0100, Stefan Sperling wrote:
 The new 1.10.1-alpha2 release is up for signing.

 The proposed 1.10.0-alpha1 release had a compilation problem on
 Windows.
 The alpha2 release should fix this problem. It is based on
 trunk@r1783880.

 Full committers, please get this release from
 https://dist.apache.org/repos/dist/dev/subversion
 and add your signatures there.

 Thank you!
>>> I am on the fence about actually releasing 1.10.0-alpha2.
>>>
>>> I am a bit worried about announcing a new 1.8/1.9/1.10 release which
>>> does
>>> not address any SHA1 issues. And I believe that 1.10 should do something
>>> meaningful about SHA1 so the alpha is not feature complete and feels
>>> premature.
>>>
>>> Does anyone share these concerns? If not, I can release alpha2 this
>>> week.
>>>
>> FWIW, the server-side fixes for FSFS should go up tonight.
>> FSX should follow soon and BDB is not affected, IIRC.
>
> We never implemented rep sharing for BDB.
>
>> I think alpha3 would be a good idea. It would also fix the
>> svnconflict.c compilation issue making this a more
>> "rounded" release.
>
> +1

Agreed, addressing the SHA1 issues sounds important enough to wait
with the alpha until we have some meaningful fixes in there.

Apart from the server-side fix(es), I was under the impression that
the working copy also needed fixing (being able to store collisions in
the pristine store), and perhaps the ra_serf protocol?

-- 
Johan

Re: 1.10.0-alpha2 is up for signing

[Branko Čibej]

On 06.03.2017 12:27, Stefan Fuhrmann wrote:
> On 06.03.2017 10:38, Stefan Sperling wrote:
>> On Tue, Feb 21, 2017 at 01:54:15PM +0100, Stefan Sperling wrote:
>>> The new 1.10.1-alpha2 release is up for signing.
>>>
>>> The proposed 1.10.0-alpha1 release had a compilation problem on
>>> Windows.
>>> The alpha2 release should fix this problem. It is based on
>>> trunk@r1783880.
>>>
>>> Full committers, please get this release from
>>> https://dist.apache.org/repos/dist/dev/subversion
>>> and add your signatures there.
>>>
>>> Thank you!
>> I am on the fence about actually releasing 1.10.0-alpha2.
>>
>> I am a bit worried about announcing a new 1.8/1.9/1.10 release which
>> does
>> not address any SHA1 issues. And I believe that 1.10 should do something
>> meaningful about SHA1 so the alpha is not feature complete and feels
>> premature.
>>
>> Does anyone share these concerns? If not, I can release alpha2 this
>> week.
>>
> FWIW, the server-side fixes for FSFS should go up tonight.
> FSX should follow soon and BDB is not affected, IIRC.

We never implemented rep sharing for BDB.

> I think alpha3 would be a good idea. It would also fix the
> svnconflict.c compilation issue making this a more
> "rounded" release.

+1


-- Brane

Re: 1.10.0-alpha2 is up for signing

[Stefan Fuhrmann]

On 06.03.2017 10:38, Stefan Sperling wrote:

On Tue, Feb 21, 2017 at 01:54:15PM +0100, Stefan Sperling wrote:

The new 1.10.1-alpha2 release is up for signing.

The proposed 1.10.0-alpha1 release had a compilation problem on Windows.
The alpha2 release should fix this problem. It is based on trunk@r1783880.

Full committers, please get this release from
https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there.

Thank you!

I am on the fence about actually releasing 1.10.0-alpha2.

I am a bit worried about announcing a new 1.8/1.9/1.10 release which does
not address any SHA1 issues. And I believe that 1.10 should do something
meaningful about SHA1 so the alpha is not feature complete and feels premature.

Does anyone share these concerns? If not, I can release alpha2 this week.


FWIW, the server-side fixes for FSFS should go up tonight.
FSX should follow soon and BDB is not affected, IIRC.

I think alpha3 would be a good idea. It would also fix the
svnconflict.c compilation issue making this a more
"rounded" release.

-- Stefan^2.

Re: 1.10.0-alpha2 is up for signing

[Stefan Sperling]

On Tue, Feb 21, 2017 at 01:54:15PM +0100, Stefan Sperling wrote:
> The new 1.10.1-alpha2 release is up for signing.
> 
> The proposed 1.10.0-alpha1 release had a compilation problem on Windows.
> The alpha2 release should fix this problem. It is based on trunk@r1783880.
> 
> Full committers, please get this release from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
> 
> Thank you!

I am on the fence about actually releasing 1.10.0-alpha2.

I am a bit worried about announcing a new 1.8/1.9/1.10 release which does
not address any SHA1 issues. And I believe that 1.10 should do something
meaningful about SHA1 so the alpha is not feature complete and feels premature.

Does anyone share these concerns? If not, I can release alpha2 this week.