Yasuhito FUTATSUKI wrote on Thu, 22 Nov 2018 08:05 +0900:
> On 11/22/18 3:22 AM, Yasuhito FUTATSUKI wrote:
> > Here is a patch against typemap file core.i, try to change
> > svn_stream_read*() and svn_stream_write() interface to use
> > bytes object.
>
> Even with this patch,
Julian Foad wrote on Wed, 21 Nov 2018 16:00 +:
> The top-of-loop comment says:
> "/* Whenever we are at the top of this loop:
> - HERE is our current directory, ..."
>
> As HERE is apparently NOT a directory in this case, I wonder if the
> comment simply should say something like
Daniel Shahaf wrote on Tue, Nov 20, 2018 at 09:28:19 +:
> Julian Foad wrote on Tue, 20 Nov 2018 08:38 +:
> > Daniel Shahaf wrote:
> > > Could you please clarify whether the bug reproduces under other backends
> > > (FSX and BDB)?
> >
> > I found
Julian Foad wrote on Tue, 20 Nov 2018 08:38 +:
> Daniel Shahaf wrote:
> > Could you please clarify whether the bug reproduces under other backends
> > (FSX and BDB)?
>
> I found that the test passes under FSX and BDB; it only fails under FS
Dmitry Pavlenko wrote on Mon, Nov 19, 2018 at 17:05:16 +0300:
> Hello Subversion community!
> I've run into an error: when performing 2 specially constructed updates one
> after another
> within the same session, SVN fails with
>
> $ ./ra-test 15
> svn_tests: E160016: Can't get entries of
Branko Čibej wrote on Sun, Nov 11, 2018 at 12:02:14 +0100:
> On 11.11.2018 10:54, Daniel Shahaf wrote:
> > It wasn't clear to me what you were proposing.
> >
> > It still isn't, actually. Have I overlooked a commit or email where you
> > spelled out what the ne
Branko Čibej wrote on Sun, Nov 11, 2018 at 07:47:18 +0100:
> On 11.11.2018 07:29, Daniel Shahaf wrote:
> > Branko Čibej wrote on Sat, Nov 10, 2018 at 15:12:48 +0100:
> >> On 10.11.2018 01:31, Daniel Shahaf wrote:
> >>> Branko Čibej wrote on Fri, 09 Nov 2018 12:56 +01
Branko Čibej wrote on Sat, Nov 10, 2018 at 15:12:48 +0100:
> On 10.11.2018 01:31, Daniel Shahaf wrote:
> > Branko Čibej wrote on Fri, 09 Nov 2018 12:56 +0100:
> >> On 09.11.2018 12:54, br...@apache.org wrote:
> >>> Author: brane
> >>> Date: Fri Nov 9
Julian Foad wrote on Fri, 09 Nov 2018 10:56 +:
> It is really quite important for the feasibility of writing higher level
> code such as shelving, that WC modifications can be read and written by
> a common, abstract, interface. That is, an interface definition which
> enables a 'copy'
Julian Foad wrote on Fri, 09 Nov 2018 12:47 +:
> == What to Do? ==
>
> I am not currently planning to make such a change, just pointing it out
> for when and if we do make changes to the editor API.
Might want to record this idea in jira, notes/, or subversion/include/
so we don't forget
Branko Čibej wrote on Fri, 09 Nov 2018 12:56 +0100:
> On 09.11.2018 12:54, br...@apache.org wrote:
> > Author: brane
> > Date: Fri Nov 9 11:54:21 2018
> > New Revision: 1846237
> >
> > URL: http://svn.apache.org/viewvc?rev=1846237=rev
> > Log:
> > More tests for peg revision parsing.
> [...]
> >
Branko Čibej wrote on Wed, 31 Oct 2018 21:10 +0100:
> On 31.10.2018 21:08, Daniel Shahaf wrote:
> > Other issue: In the three months centered on the 1.12.0 release we'll be
> > supporting 1.9, 1.10, 1.11, 1.12, and trunk in parallel, so I think we
> > should reduce the CHAN
br...@apache.org wrote on Wed, 31 Oct 2018 19:42 +:
> +++ subversion/trunk/CHANGES Wed Oct 31 19:42:05 2018
> @@ -26,6 +26,7 @@ https://svn.apache.org/repos/asf/subvers
> +* Storing passowrds in plain text on disk is disabled by default
> (r1845377)
Typo "passwords"
Other issue: In the
Good morning Ruediger,
rpl...@apache.org wrote on Wed, 31 Oct 2018 06:45 +:
> Adjust grep syntax to be able to run it with Perl 5.16.3.
>
> * tools/dist/backport.pl
> (vote) Adjust grep syntax to be able to run it with Perl 5.16.3.
>
> [D:other] backport.pl: Make it run with Perl 5.16.3.
Ruediger Pluem wrote on Tue, Oct 30, 2018 at 19:57:58 -:
> BTW, I had to apply the following patch to nominate.pl to get it running with
> perl 5.16.3 on CentOS 7:
>
> Index: tools/dist/backport.pl
> ===
> ---
Ruediger Pluem wrote on Tue, Oct 30, 2018 at 20:00:01 -:
>
>
> On 2018/10/30 18:09:42, Daniel Shahaf wrote:
> > Branko Čibej wrote on Tue, 30 Oct 2018 10:22 +0100:
> > > It's important enough to be added to CHANGES, in the server-side
> > > bugfi
Branko Čibej wrote on Tue, 30 Oct 2018 10:22 +0100:
> It's important enough to be added to CHANGES, in the server-side
> bugfixes section, so please add a line there, for 1.12.0.
Since we'll have to add this revision four times to CHANGES (on for each
of 1.9, 1.10, 1.11, 1.12), perhaps we should
Branko Čibej wrote on Tue, 30 Oct 2018 01:04 +0100:
> On 29.10.2018 19:08, Daniel Shahaf wrote:
> > Good morning Brane,
> >
> > br...@apache.org wrote on Sun, 28 Oct 2018 10:40 +:
> >> Add XFAIL tests for issue #4530.
> >>
> >> +++ subversion/t
julianf...@apache.org wrote on Mon, Oct 29, 2018 at 17:29:37 -:
> In 'staging': stage the changes for 1.11.0 release.
That's a good use of staging ☺
It does make me wonder if we need staging/ to have a different robots.txt than
publish/, though? We've linked to staging/ on this mailing list
Good morning Brane,
br...@apache.org wrote on Sun, 28 Oct 2018 10:40 +:
> Add XFAIL tests for issue #4530.
>
> +++ subversion/trunk/subversion/tests/cmdline/basic_tests.py Sun Oct 28
> 10:40:04 2018
> @@ -3050,6 +3050,33 @@ def peg_rev_on_non_existent_wc_path(sbox
> +def
Branko Čibej wrote on Sat, 27 Oct 2018 23:19 +0200:
> $ touch wc/foo/@bar
> $ svn add wc/foo/@bar
> svn: E29: 'wc/foo@bar': a peg revision is not allowed here
>
> Oh really? Since when are we allowed to ignore directory separators in
> paths?
wc/foo/@bar is parsed as path="wc/foo/",
Eric S. Raymond wrote on Fri, 26 Oct 2018 12:09 -0400:
> Julian Foad :
> > Eric S. Raymond wrote on 2018-10-26:
> > > Would someone please do the right magic?
> >
> > Your last commit was r1547712 on 2013-12-04, which is since we moved to
> > ASF, so try https://id.apache.org/ for password reset
br...@apache.org wrote on Sun, 14 Oct 2018 02:53 +:
> Author: brane
> Date: Sun Oct 14 02:53:08 2018
> New Revision: 1843807
>
> URL: http://svn.apache.org/viewvc?rev=1843807=rev
> Log:
> Restrict the loaded-library list on Linux to shared libraries.
>
> * subversion/libsvn_subr/sysinfo.c
Julian Foad wrote on Wed, 10 Oct 2018 18:01 +0100:
> I think 'release.py' should error out when it cannot find the signature files.
r1843479.
Branko Čibej wrote on Sun, 07 Oct 2018 22:08 +0200:
> svn diff http://svn.apache.org/repos/asf/subversion/trunk
> http://svn.apache.org/repos/asf/subversion/branches/multi-wc-format
Better:
svn diff http://svn.apache.org/repos/asf/subversion/trunk@r1843079
Daniel Shahaf wrote on Fri, 05 Oct 2018 14:28 +:
> It should instead do two things: one, fetch the log message of the
> mentioned revision(s) (r1842260) and pass it through the existing
> "Extract CHANGES summary" logic; two, parse the STATUS entry embedded i
'release.py write-changelog --include-unlabeled-summaries' generates
CHANGES text from 'svn mergeinfo' output on the stable branch. For
merge revisions (such as those committed by svn-role), it currently
picks the first line of the log message, e.g., "Merge r1842260 from
trunk:".
It should
Johan Corveleyn wrote on Tue, 02 Oct 2018 02:38 +0200:
> Running the entire conflicts-test.exe (on a ramdisk):
Running «make {check,davautocheck,svnserveautocheck}
TESTS=subversion/tests/…/conflicts-test APACHE_MPM=event» with the build tree
in a ramdisk, I get (average of three runs in each
Julian Foad wrote on Mon, 01 Oct 2018 15:43 +0100:
> We should stop making a distinction between "private" and "experimental"
> and just say that everything not declared as public is in the same
> bucket, available for interested developers to look at and use -- that's
> the nature of open
The 1.11 release notes have several sections tagged "experimental":
https://subversion.apache.org/docs/release-notes/1.11#checkpointing
https://subversion.apache.org/docs/release-notes/1.11#shelving
https://subversion.apache.org/docs/release-notes/1.11#viewspec-output
Should we apply some CSS to
When I run:
.
% ./subversion/svn/svn mkdir -qmm https://dist.apache.org/repos/dist/test
.
it hangs with no output, until I «pkill pinentry» from another terminal,
at which point I get the built-in password prompt.
I bisected this to the gpg-agent changes in r1794166+r1795087 [1]: in r1794165
Julian Foad wrote on Fri, 28 Sep 2018 16:52 +0100:
> Other ideas or starting points, anyone?
Would it help to have a non-publicly-archived feedback channel? I'm
thinking of, say, some feedback@subversion.a.o mailing list, privately
archived and with moderated subscriptions.
What do other ASF
julianf...@apache.org wrote on Fri, 24 Aug 2018 10:48 +:
> Author: julianfoad
> Date: Fri Aug 24 10:48:37 2018
> New Revision: 1838813
>
> URL: http://svn.apache.org/viewvc?rev=1838813=rev
> Log:
> Let 'svnadmin recover' prune the rep-cache even if it is disabled.
>
> Part of issue #4077:
Jim Jagielski wrote on Wed, 26 Sep 2018 11:09 -0400:
> At ApacheCon's welcoming event last night, Greg, Sander and I were
> chatting and Greg reminded us that the Subversion project "learned a lot
> about using APR pools" and it seems to me that a lot of that knowledge
> is likely missing in
Branko Čibej wrote on Sat, 22 Sep 2018 16:59 +0200:
> On 22.09.2018 16:43, Daniel Shahaf wrote:
> > Yes, we can remove it now.. but, frankly, I'd rather keep it, so we
> > don't have to look up the syntax the next time we need it. It sounds like
> > we could add a comment, t
Branko Čibej wrote on Sat, 22 Sep 2018 16:29 +0200:
> On 22.09.2018 16:22, Branko Čibej wrote:
> > On 22.09.2018 16:13, Daniel Shahaf wrote:
> >> Please don't download the artifacts from www*.apache.org but from a
> >> mirror. I think there is a redirector CGI s
Julian Foad wrote on Wed, 19 Sep 2018 18:11 +0100:
> There was some good discussion on IRC today about the rules for
> experimental APIs.
> http://colabti.org/irclogger/irclogger_log/svn-dev?date=2018-09-19
>
> I'll get ideas from this incorporated in the wiki page tomorrow.
>
Julian Foad wrote on Wed, 19 Sep 2018 13:46 +0100:
> I have written my proposal and rationale at
> https://cwiki.apache.org/confluence/display/SVN/LTS+and+regular+releases
About LTS v. experimental: LTS promises shouldn't apply to experimental
API's; an experimental API is always covered by the
Julian Foad wrote on Mon, 17 Sep 2018 20:39 +0100:
> Daniel Shahaf wrote:
> > From subversion/svn/info-cmd.c:
> >272if (TRUE)
> >274/* svn-viewspec.py format */
> >281else
> >283/* svn command-line format */
&
>From subversion/svn/info-cmd.c:
246 cl_layout_list(apr_array_header_t *targets,
⋮
272if (TRUE)
273 {
274/* svn-viewspec.py format */
275llb.vs_py_format = 2;
276
277SVN_ERR(svn_client_layout_list(list_abspath,
278
Julian Foad wrote on Mon, 17 Sep 2018 15:47 +0100:
> Daniel Shahaf wrote:
> > [...] I suspect it won't be uncommon for an svn_x_foo() to be graduated
> > to a stable svn_foo() with little or no incompatible changes to its
> > signature and semantics. In such cases, cou
Julian Foad wrote on Mon, 17 Sep 2018 12:36 +0100:
> Branko Čibej wrote:
> > Consequently, releasing experimental features to the stable set implies
> > removing [the experimental API] — and yes, this *will* create ABI
> > incompatibilities. If we decide that we cannot allow that and that ABI
> >
Branko Čibej wrote on Mon, 17 Sep 2018 12:57 +0200:
> A corollary of the above is that we should never have aliases for
> experimental bits in another namespace: for example, if there is an 'svn
> x-shelve' command it should not have an 'svn shelve' alias, since that
> could lead users to believe
Nathan Hartman wrote on Sun, 16 Sep 2018 15:04 -0400:
> I think there is no reason to add a unique error code for each removed
> function because those would accumulate forever as well. Instead,
> I'd create only one systemwide error code for this purpose.
Agreed. "One systemwide error code" is
Greg Stein wrote on Sun, 16 Sep 2018 04:16 -0500:
> On Sat, Sep 15, 2018 at 8:48 AM Greg Stein wrote:
> >...
>
> > No no no... I agree with Brane above. It is confusing, and if people
> > mistakenly mix/match releases things will Just Break. Mysteriously. And
> > horribly. And possibly
Julian Foad wrote on Thu, Sep 13, 2018 at 09:44:47 +0100:
> Daniel Shahaf wrote:
> > Julian Foad wrote:
> >> We recently decided that only APIs released in an LTS release will be
> >> subject to our compatibility guarantees. As 1.11 is not an LTS release,
> >>
Julian Foad wrote on Wed, 12 Sep 2018 20:21 +0100:
> The following public APIs are new or revved since 1.10:
>
> svn_client_layout_func_t
> svn_client_layout_list
> - New for 'viewspec' output; marked 'experimental'.
> > svn_client_diff7
> svn_client_diff_peg7
> - Adds a
Julian Foad wrote on Wed, 12 Sep 2018 20:39 +0100:
> I will plan to release 1.11 on 2018-10-17 which is a Wednesday 5 weeks
> from today. I have to enter a planned release date in the CHANGES file,
I'm not sure you do, not yet. The tarball you'll soon be rolling will
be called 1.11.0-rc1, not
julianf...@apache.org wrote on Wed, 12 Sep 2018 15:48 +:
> + Developer-visible changes:
> + - General:
> +* new tool to automate steps in branching a minor release (r1817962...)
> +* Add write-changelog command to release.py (r1818988)
> +* Split long help strings into paragraphs
C. Michael Pilato wrote on Wed, 05 Sep 2018 15:39 -0400:
> To be clear, red-bean.com is happy to continue hosting the book's
> HTML/PDF builds. The source lives at SourceForge these days, and I can
> grant commit permissions (or transfer ownership) as needed. Moreover,
> there's no deadline
so brief. I do have more to say but don't have time to
edit it into coherency (something unexpected has come up). Thanks for
your detailed response.
Daniel
Stefan Sperling wrote on Fri, 31 Aug 2018 11:41 +0200:
> On Thu, Aug 30, 2018 at 10:08:36PM +0000, Daniel Shahaf wrote:
> > Stefan
Karl Fogel wrote on Fri, 31 Aug 2018 14:06 -0500:
> Daniel Shahaf writes:
> >This is exactly how one adds or edits a symlink on !HAVE_SYMLINK
> >platforms, including Windows. (You can get this behaviour on Unix if
> >you get configure to lie about the HAVE_SYMLINK tes
rhuij...@apache.org wrote on Thu, 30 Aug 2018 21:18 +:
> Author: rhuijben
> Date: Thu Aug 30 21:18:31 2018
> New Revision: 1839703
>
> URL: http://svn.apache.org/viewvc?rev=1839703=rev
> Log:
> Mark 2 tests as skipped when we test using an python that contains
> an sqlite that is unable to
Karl Fogel wrote on Thu, Aug 30, 2018 at 00:22:16 -0500:
> echo "### 'new-foo' is still a symlink, by the way:"
> echo ""
> ls -l new-foo
⋮
> echo "### Okay, ready for the *real* weirdness? Good. Let's first do"
> echo "### an 'svn status -q' just to see things are:"
> echo ""
> svn status -q
>
sebb AT ASF wrote on Tue, 28 Aug 2018 11:45 +0100:
> OK, so how do I do the merge?
>
> I tried using the following in a fresh checkout of the staging branch:
>
> svn merge ^/subversion/site/publish
>
> However it showed changes I have not made, so I am loath to commit them:
>
> $ svn -u st
>
Branko Čibej wrote on Mon, 27 Aug 2018 13:44 +0200:
> On 24.08.2018 13:55, Julian Foad wrote:
> > Brane, this one's yours:
> >
> > https://ci.apache.org/buildslaves/svn-x64-macosx-dgvrs
> >
> > The new tests for #4077 are failing on at least this buildbot-slave.
> >
> > "Can't read rep-cache
Stefan wrote on Sat, 25 Aug 2018 15:42 +0200:
> On 25/08/2018 15:21, Daniel Shahaf wrote:
> > luke1...@apache.org wrote on Sat, 25 Aug 2018 12:48 +:
> >> +++ subversion/site/staging/download.html Sat Aug 25 12:48:24 2018
> >> @@ -258,7 +258,8 @@ Other mirrors:
>
luke1...@apache.org wrote on Sat, 25 Aug 2018 12:48 +:
> +++ subversion/site/staging/download.html Sat Aug 25 12:48:24 2018
> @@ -258,7 +258,8 @@ Other mirrors:
>
> Alternatively, you can verify the checksums on the files.
[preëxisting issue] This sentence is misleading to people not
Julian Foad wrote on Fri, 24 Aug 2018 12:17 +0100:
> Julian Foad:
> > Committed in http://svn.apache.org/r1838813
>
> And nominated for backport to 1.10.x and 1.9.x.
>
> The tests are failing on some buildbots:
>
> "Can't read rep-cache schema 2 using old Python-SQLite version (3, 7,
> 13) <
C. Michael Pilato wrote on Thu, 23 Aug 2018 14:59 -0400:
> On 08/23/2018 09:52 AM, Daniel Shahaf wrote:
> > We also have a subversion_logo.svg under site/publish/. I'm not sure
> > why, but the one in notes/ was larger so I chose it.
>
> The one under site/publish was a
Julian Foad wrote on Thu, 23 Aug 2018 13:38 +0100:
> If you have or know of a high resolution or scalable version of your
> project's logo (or logos!), if you could please do the following, that
> would be really helpful:
>
> - Either commit your logo to
>
Julian Foad wrote on Thu, Aug 23, 2018 at 10:21:17 +0100:
> +++ subversion/libsvn_fs_fs/recovery.c(working copy)
> @@ -468,15 +468,15 @@ recover_body(void *baton, apr_pool_t *po
>/* Prune younger-than-(newfound-youngest) revisions from the rep
> - cache if sharing is enabled taking
Julian Foad wrote on Wed, 22 Aug 2018 22:20 +0100:
> Julian Foad wrote:
> > It looks like r1213716 ("also prune the rep-cache when it's present but
> > reportedly not being used") was reverted by r1367674, apparently
> > unintentionally.
>
> Well, with some degree of intention, judging by the
Julian Foad wrote on Tue, 21 Aug 2018 16:19 +0100:
> However, a process of marking all new APIs as experimental in regular
> releases, and ensuring we review them for LTS releases, might be a good
> way to satisfy both Semantic Versioning and experimental APIs.
+1
Julian Foad wrote on Tue, 21 Aug 2018 16:27 +0100:
> Agreed. Also we might like to teach "svnadmin verify" to check whether
> the cache is complete.
>
Well, a missing 'rep-cache' is not a correctness problem, but merely an
efficiency problem (which the admin may have explicitly opted into), so
Julian Foad wrote on Tue, 21 Aug 2018 14:12 +0100:
> * We could ignore the rep cache during commit-txn (in existing API:
> set fs_fs_data.rep_sharing_allowed = FALSE), then make a separate call
> to update the rep cache afterwards.
>
"A separate call to update the rep cache afterwards" ---
Julian Foad wrote on Mon, 13 Aug 2018 15:28 +0100:
> Daniel Shahaf wrote:
> > Thank you! Documented in the 1.11 release notes in r1837957.
>
> Thanks. Maybe change the rationale:
>
> - We consider the SHA-1 cryptographic hash function too weak for our needs.
> + Thi
Julian Foad wrote on Mon, 13 Aug 2018 14:33 +0100:
> Daniel Shahaf wrote:
> > Daniel Shahaf wrote:
> > > Correct me if I'm wrong, but wouldn't reverting the first hunk of
> > > r1837939 and making it conditional upon [...]
> >
> > 'args.version < Vers
Thomas Singer wrote on Mon, 13 Aug 2018 14:56 +0200:
> The user ensured to have used the same working copy. Is there some way
> to debug it to find out why his SVN binary behaves different then ours?
> Thanks in advance.
The simplest explanation is that it's a cygwin svn.exe v. a windows
Daniel Shahaf wrote on Mon, 13 Aug 2018 12:54 +:
> Correct me if I'm wrong, but wouldn't reverting the first hunk of
> r1837939 and making it conditional upon a 'version < Version(1,11,0)'
Sorry, that would be a RuntimeError. The condition should be
'args.version < Version(&q
Julian Foad wrote on Mon, 13 Aug 2018 13:32 +0100:
> Daniel Shahaf wrote:
> > Julian Foad wrote on Mon, 13 Aug 2018 12:59 +0100:
> > > * stop producing *.sha1 files and stop listing SHA1 on the 'downloads'
> > > page
> > >
> > > -- http:/
Julian Foad wrote on Mon, 13 Aug 2018 12:59 +0100:
> We "SHOULD NOT" any longer publish SHA1 checksums for new releases, according
> to
> https://www.apache.org/dev/release-distribution#sigs-and-sums
>
> So I have done this:
>
> * remove references to SHA1 from the documentation
>
> --
Nikita Slyusarev wrote on Sat, 04 Aug 2018 17:47 +0300:
> For everyone's sanity I'd better not only bump the thread, but also
> resend the patch and the log message I had prepared back then.
>
Filed SVN-4768. If anyone could review the patch, that'd be great;
it's a one-liner fix with a
Folker Schamel wrote on Fri, 03 Aug 2018 14:20 +0200:
> From my perspective, all these changes would be fine.
Is anyone working on a patch to revise the release notes and FAQ along these
lines?
julianf...@apache.org wrote on Thu, Aug 02, 2018 at 14:44:02 -:
> +++ subversion/site/publish/docs/release-notes/1.10.html Thu Aug 2 14:44:02
> 2018
> @@ -353,6 +353,43 @@ In particular, the behaviour of builds <
>
>
>
> +
> +New CA keys may be required
> + +title="Link to this
Folker Schamel wrote on Thu, 02 Aug 2018 15:34 +0200:
> On 2018-08-01 19:19, Daniel Shahaf wrote:
> > Folker Schamel wrote on Wed, 01 Aug 2018 17:51 +0200:
> >> Hi Julian,
> >>
> >> Draft which may save you some time:
> >>
> >> First patc
Folker Schamel wrote on Wed, 01 Aug 2018 17:51 +0200:
> Hi Julian,
>
> Draft which may save you some time:
>
> First patch against trunk:
> [[[
> * site/staging/faq.html:
>Add entry for "An error occurred during SSL communication" error.
> ]]]
>
> Second patch against trunk:
> [[[
> *
Julian Foad wrote on Tue, 31 Jul 2018 22:27 +0100:
> Daniel Shahaf wrote:
> >Add the "work in progress" notice (r1780199)?
>
> Yes please!
Sure, r1837213.
(Would've committed it myself but I had already missed the first act of the
first dream...)
julianf...@apache.org wrote on Tue, 31 Jul 2018 15:31 +:
> Author: julianfoad
> Date: Tue Jul 31 15:31:37 2018
> New Revision: 1837159
>
> URL: http://svn.apache.org/viewvc?rev=1837159=rev
> Log:
> * publish/docs/release-notes/1.11.html: New file.
Add the "work in progress" notice
Folker Schamel wrote on Tue, Jul 31, 2018 at 17:42:10 +0200:
> On 2018-07-31 17:04, Philip Martin wrote:
> > Folker Schamel writes:
> > > For the broken setup, the client reports:
> > > svn: E120171: Error running context: An error occurred during SSL
> > > communication
> > > And the server
Branko Čibej wrote on Tue, Jul 31, 2018 at 13:43:57 +0200:
> On 31.07.2018 13:04, Julian Foad wrote:
> > However, this does not only convert old to new format, but could also make
> > textual changes to the string if the revprop value is not already
> > canonical. Dump should carefully output
Julian Foad wrote on Tue, Jul 31, 2018 at 12:04:23 +0100:
> https://issues.apache.org/jira/browse/SVN-4767
>
> Running tests with the '--dump-load-cross-check' option revealed a minor
> discrepancy between the dump files produced by 'svnadmin dump' and 'svnrdump
> dump' in some test cases.
>
>
Philip Martin wrote on Mon, Jul 30, 2018 at 13:51:06 +0100:
> @@ -820,6 +833,13 @@ add_access_entry(ctor_baton_t *cb, svn_stringbuf_t
>
>SVN_ERR_ASSERT(acl != NULL);
>
> + if (svn_hash_gets(cb->rule_entries, name))
> +return svn_error_createf(SVN_ERR_AUTHZ_INVALID_CONFIG, NULL,
> +
Branko Čibej wrote on Mon, 30 Jul 2018 03:07 +0200:
> On 30.07.2018 02:38, Philip Martin wrote:
> > Branko Čibej writes:
> >
> >> It's worth working on a fix, IMO. My suggestion would be:
> >>
> >> * Keep the single-rule behaviour as it turned up in 1.10, just
> >> document it. It's
Philip Martin wrote on Wed, 25 Jul 2018 15:08 +0100:
> I've noticed a feature that seems to be have been lost when we switched
> from neon to serf: serf doesn't store the client cert creds. There are
> two bits of data, the path to the pkcs12 file and the password for the
> private key. The
Philip Martin wrote on Tue, 24 Jul 2018 23:37 +0100:
> Branko Čibej writes:
> > It describes designed behaviour. If we change it, we should do it
> > carefully, as I wrote above. Also I think it turns out that the authz
> > section in the release notes misses a behaviour change or two. It should
Dmitry Pavlenko wrote on Thu, Jul 19, 2018 at 19:03:30 +0200:
> I'm attaching a reproducing test.
>
Thanks for the test!
> I'm not 100% sure that
>
> [
> 'Index: %s\n' % sbox.path('iota'),
> '===\n',
> '---
Johan Corveleyn wrote on Mon, 16 Jul 2018 21:46 +0200:
> (why would CHANGES in a 1.9.x tarball need to contain changes of the
> 1.8 line?)
I see no reason for a 1.9.x tarball to contain the CHANGES stanzas of
1.8.y with y>1, since the contents of those sections are repeated under
1.9.x sections,
Julian Foad wrote on Mon, 16 Jul 2018 17:49 +0100:
> Actually the "sync merge" way isn't as automatic as I would like. The
> merge always conflicts when there is a new or modified trunk CHANGES
> entry for 1.10.x. Maybe --accept=mine-conflict would completely solve
> that. Haven't tested that.
Johan Corveleyn wrote on Mon, 16 Jul 2018 00:46 +0200:
> It seems something went wrong with the "Post-release housekeeping"
> commits on the 1.10.x branch, r1835806 (post 1.10.1) and r1835936
> (post 1.10.2): they contain an empty diff for svn_version.h ... weird.
An empty diff is the result of
URL: https://issues.apache.org/jira/browse/INFRA-16692
> > Project: Infrastructure
> > Issue Type: Project
> > Components: Wilderness
> >Reporter: Daniel Shahaf (äñ§€¥£¢)
> >Assignee: Chris Lambertus
> >Priori
Nikita Slyusarev wrote on Sat, Jul 14, 2018 at 13:19:54 +0300:
> Hello. This patch fixes svn copy behaviour. Let's discuss.
> What are my next steps here? Can I help somehow with patch acceptance?
The submission includes a log message and an explanation of the problem. In
that regard it is
Julian Foad wrote on Fri, 13 Jul 2018 17:20 +0100:
> Daniel Shahaf wrote:
> > > The 'CHANGES' file in the 1.10.1 tarball is missing the last two
> > > changes, that were merged last night:
> >
> > The CHANGES file in 1.10.1 also has a "Version 1.11.0&
Julian Foad wrote on Fri, 13 Jul 2018 17:12 +0100:
> $ svn ls ^/subversion
> README
> branches/
> developer-resources/
> site/
> site-ng/
> svn-logos/
> tags/
> trunk/
> upstream/
>
> Brane's suggestion of locating CHANGES in the web site tree makes quite
> good sense to me too, although as long
Julian Foad wrote on Fri, 13 Jul 2018 14:28 +0100:
> Julian Foad wrote:
> > The 1.10.1 release artifacts are now available for testing/signing.
>
> The 'CHANGES' file in the 1.10.1 tarball is missing the last two
> changes, that were merged last night:
The CHANGES file in 1.10.1 also has a
Julian Foad wrote on Thu, 12 Jul 2018 22:35 +0100:
> Philip Martin wrote:
> > [...] a user recently reported another regression
> > [...] I'd like to delay 1.10.1 for a few days [...]
>
> My time is currently allocated to rolling a release of the good fixes we
> already have. In a few days I
Jan Palus wrote on Thu, 12 Jul 2018 20:23 +0200:
> On 12.07.2018 15:08, Daniel Shahaf wrote:
> > Thanks for the patch; however, I don't think that's the correct fix.
>
> To be honest I wasn't sure of that either but on the other hand I thought that
> having initialize
Jan Palus wrote on Wed, Jul 11, 2018 at 13:46:35 +0200:
> [[[
> Fix segfault when subversion is built with gnome keyring support and keyring
> password lookup fails.
>
> * subversion/libsvn_subr/simple_providers.c
> (svn_auth__simple_creds_cache_get): Initialize 'done' with FALSE since ie
>
luke1...@apache.org wrote on Thu, Jul 05, 2018 at 21:13:37 -:
> +++ subversion/site/publish/docs/community-guide/releasing.part.html Thu Jul
> 5 21:13:36 2018
> @@ -975,22 +975,19 @@ in the same directory as the tarballs. +policy, we require testing and signatures from at least [one] PMC
Julian Foad wrote on Mon, 02 Jul 2018 12:20 +0100:
> Philip Martin wrote:
> > I did also worry about thread safety: it's not safe to modify the
> > context like that if the context can be shared across multiple threads.
> > However the context also includes batons and those typically point to
> >
801 - 900 of 4504 matches
Mail list logo
