Re: svn commit: r1834628 - /subversion/trunk/subversion/tests/cmdline/patch_tests.py

Julian Foad wrote on Sun, 01 Jul 2018 12:38 +0100: > Thanks for pointing this out. This was copied from elsewhere in our test > suite. Fixed throughout, [...] Thanks, Julian. Daniel

Re: svn commit: r1834628 - /subversion/trunk/subversion/tests/cmdline/patch_tests.py

julianf...@apache.org wrote on Thu, 28 Jun 2018 17:25 +: > +unidiff_patch += ['\ No newline at end of property\n'] The sequence will be a SyntaxError in a future version of Python: [[[ % curl https://docs.python.org/3/reference/lexical_analysis.html#literals | me Changed in version

API compatibility promises in light of biannual releases (was: Re: Intentions for 1.11 release timing)

Julian Foad wrote on Fri, Jun 22, 2018 at 14:26:53 +0100: > Another angle on this: I interpret what we are doing as inserting extra > mini-feature-releases into the existing cycle, rather than compressing the > existing cycle to happen four times faster. I wonder what our API compatibility

Re: change release signature requirements?

Julian Foad wrote on Mon, 25 Jun 2018 11:33 +0100: > Johan Corveleyn wrote on 2018-06-25: > > On Sun, Jun 24, 2018 at 8:20 AM, Stefan Sperling wrote: > > > While we're on the subject of changing the supported release > > > process, we could use this opportunity to lower the number of > > >

Re: Intentions for 1.11 release timing

Julian Foad wrote on Mon, 25 Jun 2018 11:31 +0100: > Daniel Shahaf wrote: > > Julian Foad wrote on Fri, 22 Jun 2018 14:26 +0100: > >> That is why I think we should keep the support period for 1.9 as one > >> release (until 1.10) for general fixes plus 2 years (being ro

Re: Intentions for 1.11 release timing

Julian Foad wrote on Fri, 22 Jun 2018 14:26 +0100: > Daniel Shahaf wrote: > > Julian Foad wrote on Fri, Jun 22, 2018 at 12:27:21 +0100: > > > Done in http://svn.apache.org/r1834111, > > > "Publish our new 6-month standard and 2-year LTS release schedule." >

Re: Intentions for 1.11 release timing

Julian Foad wrote on Fri, Jun 22, 2018 at 12:27:21 +0100: > Julian Foad wrote on 2018-05-20: > > I suggest our next step should be updating the Subversion web pages to > > state (clearly) this new policy. We should not yet delete the statements > > about the old policy. > > > > Does anyone want

Re: shelf-tests failure on macOS

Julian Foad wrote on Thu, 14 Jun 2018 16:06 +0100: > Branko Čibej wrote on 2018-06-14: > > A sync (which forces a write to disk) should not be necessary in cases > > like this one, as long as we close the file in Python — that should > > ensure a write to the OS buffers. If this were the problem,

Re: shelf-tests failure on macOS

Branko Čibej wrote on Thu, 14 Jun 2018 04:04 +0200: > ... on the other hand, making this suggested change won't hurt, as long > as our required Python version for tests supports the 'with' statement, > which I believe it does. In fact we already use the 'with' statement in > our test suite. Since

Re: handling of reparse points

Stefan Küng wrote on Fri, 25 May 2018 17:37 +0200: > Can anyone comment on this please? I'm not familiar with the Windows side of things, but I gave the patch a spin. If I do 'mv .svn x; ln -s x .svn', things seem to work. However, if the target of the '.svn' symlink isn't in the same directory

Re: Intentions for 1.11 release timing

> > LTS release: > > * full backports for at least 2 years, and at least until the next LTS > > release > > * security/corruption fixes for at least 4 years, and at least until the > > next-but-one LTS release > > Sorry, no. No one can plan with the words "at least". This isn't a >

Re: Intentions for 1.11 release timing

Julian Foad wrote on Fri, 18 May 2018 14:54 +0100: > standard release: > * full backports at least until the next standard release > * security/corruption fixes at least until the next-but-one standard release Nitpick, but: s/until the next standard release/until the next release/ (whether

Re: Wiki migration complete -- new wiki is now live

Johan Corveleyn wrote on Fri, 20 Apr 2018 15:20 +0200: > BTW: the new wiki doesn't send notifications to commits@a.o. However, > you can set up notifications for yourself from within the wiki: > > - [...instructions...] This is a regression. I'm glad there's a workaround, but would it be

Re: How to disable lz4 support when library is installed in system?

Philip Martin wrote on Tue, Apr 17, 2018 at 09:50:14 +0100: > Daniel Shahaf <d...@daniel.shahaf.name> writes: > > > In principle, if svn were built without lz4 (which isn't supposed to be > > allowed by the stock configure) then it won't be able to read or produce &g

Re: release.py create-tag failed to update STATUS

Julian Foad wrote on Sat, 14 Apr 2018 18:21 +0100: > Daniel Shahaf wrote on 2018-04-14: > > > It's because it uses "svnmucc -r put <...>" but STATUS has already > > > been modified between r and HEAD. > > > > Agreed. It's perfectly possible for

Re: release.py create-tag failed to update STATUS

Julian Foad wrote on Wed, Apr 11, 2018 at 08:21:19 +0100: > Running "release.py create-tag" just now failed: > > + release.py --base-dir /opt/svnrm create-tag 1.10.0 r1827917 > INFO:root:Creating tag for 1.10.0 > r1828867 committed by julianfoad at 2018-04-11T07:00:33.547290Z > INFO:root:Bumping

Re: How to disable lz4 support when library is installed in system?

> > What should I pass to "configure" to PREVENT detection & usage of lz4 > > library installed in system? `--without-lz4' doesn't work. Yes, I can reproduce this. '--without-lz4' results in: configure: lz4 configuration via prefix checking for LZ4_compress_default in -llz4... yes which is

Fwd: [wuzhouhui: Re: width of output of 'svn shelves' is too large]

We're getting feedback on 'svn shelve' on users@. Does anyone want to follow up? - Forwarded message from wuzhouhui <1530108...@qq.com> - > Date: Sat, 31 Mar 2018 18:17:17 +0800 > From: wuzhouhui <1530108...@qq.com> > To: Daniel Shahaf <d...@daniel.shahaf.na

Re: Wiki migration to Confluence: test conversion ready for review

Johan Corveleyn wrote on Mon, 26 Mar 2018 00:49 +0200: > Sorry, this should have long been done by now, but things got in the > way and I lost focus. > > I'll try to pick up the pieces again and get this done sometime during > next week. No problem; we need it to eventually happen but we needn't

Re: Script to obliterate the most recent revision(s)

Johan Corveleyn wrote on Mon, 26 Mar 2018 00:32 +0200: > During the Aachen hackathon we brainstormed a bit about obliterate, > and figured it would be wonderful if a client, acting on a working > copy, could detect that "history has been changed". Even if only to > give an fatal error message

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

julianf...@apache.org wrote on Thu, 22 Feb 2018 11:02 +: > +++ subversion/trunk/subversion/svn/svn.c Thu Feb 22 11:02:02 2018 > @@ -1831,7 +1831,7 @@ const svn_opt_subcommand_desc2_t svn_cl_ > "\n" > " To bring back a shelved change, use 'svn unshelve NAME'.\n" > "\n" > -

rep-cache sanity checks Re: Script to obliterate the most recent revision(s)

Julian Foad wrote on Fri, Mar 23, 2018 at 17:30:14 +: > Nathan Hartman wrote: > > It just occurred to me that because correct operation of the rep- > > cache is so crucial to the reliability of the system, perhaps it > > would be a good idea to make sure the rep-cache does not contain too- > >

Re: Script to obliterate the most recent revision(s)

C. Michael Pilato wrote on Fri, Mar 23, 2018 at 08:46:16 -0400: > On 03/23/2018 02:04 AM, Daniel Shahaf wrote: > > Julian Foad wrote on Thu, 22 Mar 2018 22:24 +: > >> This question keeps coming up and I feel we should provide an accurate > >> answer, even if the

Re: Script to obliterate the most recent revision(s)

Daniel Shahaf wrote on Fri, 23 Mar 2018 06:04 +: > I wonder if it would be possible to say: Run 'svnadmin freeze $SHELL'; > therein delete 'db/current', the revision files, and txns; restart all > reader processes; exit that subshell and run 'svnadmin recover'. This > would save th

Re: Script to obliterate the most recent revision(s)

Julian Foad wrote on Thu, 22 Mar 2018 22:24 +: > This question keeps coming up and I feel we should provide an accurate > answer, even if the procedure is not "supported". > > Any corrections to my current best effort, below? > As a first step: Check $REPOS/format, $REPOS/db/fs-type,

Re: svn commit: r1827100 - /subversion/branches/1.10.x/STATUS

Branko Čibej wrote on Sun, Mar 18, 2018 at 16:40:45 +0100: > +++ svn_ra_svn.h (working copy) > @@ -179,7 +179,9 @@ typedef svn_error_t *(*svn_ra_svn_edit_callback)(v > * Either @a sock or @a in_stream/@a out_stream must be set, not both. > * @a compression_level specifies the desired

Re: svn commit: r1827100 - /subversion/branches/1.10.x/STATUS

Branko Čibej wrote on Sat, 17 Mar 2018 20:27 +0100: > On 17.03.2018 20:24, br...@apache.org wrote: > > > > + * r1825979 > > + Minor clarification to docstring. > > + Justification: > > + Trivial documentation fix. > > + Votes: > > + +1: danielsh, jamessan > > + -1: brane (the

fsfs 'structure' terminology: length/size v. size/expanded-size (was: Re: E130003: The XML response contains invalid XML - Follow-up)

[ cc += dev@ ] NOCERA, ANDY wrote on Thu, 15 Mar 2018 22:35 +: > Folks, > > I used dump and load to debug the malformed node revision ID. Here are > my steps and what learned. Looks like the revs' file text: entry has > a zero instead of size. To be clear, you mean the fourth field.

Re: Warnings for experimental functions [was: svn commit: r1826864 ...]

Julian Foad wrote on Fri, 16 Mar 2018 10:12 +: > I'll comment out the SVN_EXPERIMENTAL tag, as that's easy and not > necessary during development as we would expect to review new API > functions before releasing 1.11, and also expect to change this before > then anyway. Sounds good to me,

Re: svn commit: r1826928 - /subversion/trunk/subversion/libsvn_client/shelf.c

Branko Čibej wrote on Fri, 16 Mar 2018 10:14 +0100: > On 16.03.2018 10:05, danie...@apache.org wrote: > > Author: danielsh > > Date: Fri Mar 16 09:05:45 2018 > > New Revision: 1826928 > > > > URL: http://svn.apache.org/viewvc?rev=1826928=rev > > Log: > > * subversion/libsvn_client/shelf.c: Add

Re: svn commit: r1826907 - /subversion/trunk/subversion/libsvn_fs_fs/cached_data.c

phi...@apache.org wrote on Fri, 16 Mar 2018 00:00 +: > Fix issue 4727 which is a bug in the fix for issue 4725. > > * subversion/libsvn_fs_fs/cached_data.c > (cache_windows): Move auto_read_diff_version() call before the loop. > +++ subversion/trunk/subversion/libsvn_fs_fs/cached_data.c >

Re: Rolling 1.10.0-rc2

Johan Corveleyn wrote on Thu, Mar 15, 2018 at 12:00:57 +0100: > C:\>python tools\dist\release.py write-changelog > --include-unlabeled-summaries branches/1.10.x tags/1.10.0-rc1 > * Merge r1825045 from trunk: (r1825285) > * Merge r1825215 from trunk: (r1825286) > * Merge r1825306 from

Re: svn commit: r1826864 - in /subversion/trunk/subversion: include/svn_client.h libsvn_client/layout.c svn/cl.h svn/info-cmd.c svn/svn.c

Good morning Julian, julianf...@apache.org wrote on Thu, 15 Mar 2018 20:43 +: > Author: julianfoad > Date: Thu Mar 15 20:43:30 2018 > New Revision: 1826864 > > URL: http://svn.apache.org/viewvc?rev=1826864=rev > Log: > Viewspec: Add an experimental viewspec output command. > > This reports

Re: svn commit: r1826912 - /subversion/site/publish/mailing-lists.html

phi...@apache.org wrote on Fri, 16 Mar 2018 01:39 +: > Author: philip > Date: Fri Mar 16 01:39:21 2018 > New Revision: 1826912 > > URL: http://svn.apache.org/viewvc?rev=1826912=rev > Log: > * publish/mailing-list.html: Add new Apache links, remove broken mbox links. > > Modified: >

Re: svn commit: r1826328 - in /subversion/trunk/subversion: include/svn_opt.h libsvn_subr/opt.c

julianf...@apache.org wrote on Fri, 09 Mar 2018 11:06 +: > * subversion/include/svn_opt.h, > subversion/libsvn_subr/opt.c > (SVN_OPT_MAX_PARAGRAPHS, >svn_opt_subcommand_desc3_t, >svn_opt_get_canonical_subcommand3, >svn_opt_get_option_from_code3, >

Re: [PATCH] Split long strings into paragraphs to ease translation

Mattias Engdegård wrote on Wed, 07 Mar 2018 16:35 +0100: > The gettext manual recommends: > > Translatable strings should be limited to one paragraph; don’t let a single > message be longer than ten lines. The reason is that when the translatable > string changes, the translator is faced

Re: svn commit: r1825981 - /subversion/site/staging/docs/release-notes/1.10.html

Could I get a second pair of eyes on this please. I was wondering whether we should point out that svn+ssh:// may do its own compression (as in, 'ssh -C'). Daniel danie...@apache.org wrote on Tue, 06 Mar 2018 12:58 +: > * staging/docs/release-notes/1.10.html > (#lz4-over-the-wire):

[PATCH] fsfs: Better 'parse error' error message

[[[ * subversion/libsvn_fs_fs/id.c (svn_fs_fs__id_parse): Include more information in an error message. ]]] [[[ Index: subversion/libsvn_fs_fs/id.c === --- subversion/libsvn_fs_fs/id.c(revision 1825746) +++

Re: svn commit: r1825435 - /subversion/site/publish/docs/community-guide/releasing.part.html

julianf...@apache.org wrote on Tue, 27 Feb 2018 09:34 +: > +++ subversion/site/publish/docs/community-guide/releasing.part.html Tue > Feb 27 09:34:04 2018 > @@ -1100,6 +1100,9 @@ releases using: > +Submit the version number of the new release on

Re: svn commit: r1825449 - /subversion/site/staging/docs/release-notes/1.10.html

gst...@apache.org wrote on Tue, 27 Feb 2018 13:46 +: > Author: gstein Welcome back! > Date: Tue Feb 27 13:46:48 2018 > New Revision: 1825449 > > URL: http://svn.apache.org/viewvc?rev=1825449=rev > Log: > rewrite unclear sentence. fix typo. > > +++

Re: [PATCH] Better error message for svn bindings import in mailer.py.

Karl Fogel wrote on Sat, Feb 17, 2018 at 16:52:39 -0600: > Daniel Shahaf <d...@daniel.shahaf.name> writes: > >It would be useful to also print the caught exception in case it contains > >more > >specific information about the cause of the problem… > > > >… b

Re: Backward or forward deltas, backend, FSX

you'll have operated on 1.000400MB of input (200B in the delta combiner and 1.000200MB in the delta applier). > Daniel Shahaf: > > FSFS and FSX are designed around the assumption that the storage backing > > older revisions is immutable. > > Older revisions (older than

Re: Backward or forward deltas, backend, FSX

Nathan Hartman wrote on Thu, 15 Feb 2018 22:01 -0500: > On Feb 15, 2018, at 4:11 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > > > Péter wrote on Thu, 15 Feb 2018 19:47 +0100: > > I'm not sure why you say "at least" 17 deltas. The default value

Re: Backward or forward deltas, backend, FSX

Péter wrote on Thu, 15 Feb 2018 19:47 +0100: > [I am not a list member] > > In the proposed FSX backend, > [ https://subversion.apache.org/docs/release-notes/1.9.html#fsx ] > what type of deltas is planned? Deltas against an older - or newer revision? > [

Re: Relaxed STATUS voting rules for experimental features?

Branko Čibej wrote on Mon, 12 Feb 2018 23:11 +0100: > Backporting experimental features isn't crucial, surely? Yet if there > are changes in trunk, they _might_ affect other code; in that case, more > eyes is better. So perhaps something like 'two +1s and one "I verified no non- experimental code

Relaxed STATUS voting rules for experimental features?

The shelving functionality is experimental: /** Shelve a change. ⋮ * @since New in 1.10. * @warning EXPERIMENTAL. */ SVN_EXPERIMENTAL svn_error_t * svn_client_shelve(const char *name, const apr_array_header_t *paths,

Re: svn commit: r1823966 - in /subversion/trunk/subversion/svn: shelf-cmd.c shelve-cmd.c

julianf...@apache.org wrote on Mon, 12 Feb 2018 13:17 +: > +++ subversion/trunk/subversion/svn/shelf-cmd.c Mon Feb 12 13:17:16 2018 > @@ -71,6 +71,36 @@ friendly_duration_str(apr_time_t duratio > +#ifndef WIN32 > +/* Run CMD with ARGS. > + * Send its stdout to the parent's stdout. Disconnect

Re: mailer.py commit says TypeError: must be unicode, not str

Troy Curtis Jr wrote on Sun, 11 Feb 2018 14:27 +: > All this being said, I'm fine reverting the import swap if that is what is > desired, as all indications are that it works either way now. I simply > liked the communication of intent better with this order. I think the primary reason for

Re: mailer.py commit says TypeError: must be unicode, not str

Troy Curtis Jr wrote on Sun, 11 Feb 2018 02:28 +: > I committed the fix to the bindings in > https://svn.apache.org/viewvc?view=revision=1823802 . In addition > to Kenneth's suggestion of opening in binary mode, I switched the imports > so that the python2-future's implementation would not

Re: mailer.py commit says TypeError: must be unicode, not str

Troy Curtis Jr wrote on Sun, 11 Feb 2018 03:36 +: > I believe that Subversion has an internal diff generation utility, could > someone point me in the right direction? tools/diff/diff svn_diff_diff_2() > I think just changing the implementation to using an internal diff > would make this

Re: svn commit: r1823791 - /subversion/trunk/Makefile.in

s...@apache.org wrote on Sat, 10 Feb 2018 19:26 +: > +++ subversion/trunk/Makefile.in Sat Feb 10 19:26:03 2018 > @@ -872,9 +872,7 @@ $(SWIG_PL_DIR)/native/Makefile: $(SWIG_P > -swig-pl_DEPS = autogen-swig-pl libsvn_swig_perl \ > - $(SWIG_PL_DIR)/native/Makefile > -swig-pl: $(swig-pl_DEPS) >

Re: mailer.py commit says TypeError: must be unicode, not str

Kenneth Porter wrote on Wed, 07 Feb 2018 09:35 -0800: > The overload of type was happening due to the unprefix stuff in fs.py. Red > herring, though interesting. This should only happen with 1.7 and earlier, see https://subversion.apache.org/docs/release-notes/1.8#swig-py-star Cheers, Daniel

Re: Bad error message when the URL doesn't point to a repository

Branko Čibej wrote on Tue, 06 Feb 2018 22:10 +0100: > The error message now looks like this: > > $ svn ls http://svn.apache.org/foo > svn: E170013: Unable to connect to a repository at URL > 'http://svn.apache.org/foo' > svn: E175003: The server does not support the HTTP/DAV protocol > > >

Re: swig-py3 branch review for trunk merge

Troy Curtis Jr wrote on Wed, 31 Jan 2018 04:30 +: > I'm now asking for swig-py3 merge to trunk review with fewer caveats. > > [...] The biggest update is addition of Windows support with the new py3c > dependency. Thanks for looking into the windows build! > So if you get a chance, take a

Re: SVN-4709 shelve: deleted file becomes 'replaced'

Julian Foad wrote on Wed, 24 Jan 2018 21:32 +: > When 'svn patch' applies an 'add file' patch onto a WC path whose local > schedule is 'delete', it changes the schedule to 'replace'. > > Sequences such as this... > > > svn rm foo > > svn diff > rm-foo.diff > > svn patch --reverse-diff

Re: mod_lua + mod_authz_svn: Problem with authenticating user and mod_authz_svn behaviour

Torsten Krah wrote on Wed, 24 Jan 2018 15:49 +0100: > Hi dev folks, > Welcome! > I'll recompiled the module and did run the basic_tests.py suite against > it - same results - with and without those header checks. But i am not > sure if there is even a test which checks that detail. > I've

Re: Reviewing 1.10 APIs & compatibility

Julian Foad wrote on Tue, 16 Jan 2018 13:09 +: > Philip Martin wrote: > >> Julian Foad wrote: > >>> Another possible approach is to look for compatibility breakage by > >>> running the 1.9 client and test suite against the 1.10 libraries, > >>> and indeed different client/server version

Re: A rational svn shelve/checkpoint CLI

Julian Foad wrote on Tue, 09 Jan 2018 13:31 +: > Anyway the main point here is: we have in principle a set of tree > snapshots (no matter that each one is stored in the form of a difference > against the base); and we use revision specifiers to refer to the > working and base versions: ...

Should 'svn patch' say nothing when it does nothing?

I tried to commit r1820518 by extracting the patch from the mail to a file and using 'svn patch': % svn patch /tmp/patch % svn status % Now, in this situation, should 'svn patch' have said something to the effect of "svn: No patch found in input"? I'm aware of "Nothing done, nothing said", but

Re: [PATCH] swig-py svn_stream_t read() glue

Thanks for the reviews; committed in r1820518 and nominated for backport for 1.10.x and for 1.9.x as well (although I can see that the risk/benefit balance could be different for the two). Daniel

[PATCH] swig-py svn_stream_t read() glue

svn_swig_py_make_stream() is a function that wraps a PyObject in an svn_stream_t. Its read implementation, read_handler_pyio(), just calls the PyObject's .read() method. According to , the read() method of "raw" file-like objects makes

Re: Tree conflict 'svn merge' message

Stefan Sperling wrote on Sat, 30 Dec 2017 17:58 +0100: > This could be a bug. Perhaps the wrong message is selected for some > reason. Can you please file an issue? I cannot look closely right now. Sure, https://issues.apache.org/jira/browse/SVN-4717. Excuse brevity. Daniel

Re: svnignore?

Daniel Shahaf wrote on Sat, 30 Dec 2017 10:00 +: > We've got an off-by-one somewhere. And here's a regression test. It passes if the expectation is "foo ar az" but fails if the expectation is "foo bar baz". The patch is attached (rather than inline) because it adds

Re: svnignore?

Branko Čibej wrote on Sat, 30 Dec 2017 10:09 +0100: > Don't know what you were trying [[[ % cat ~/.subversion/config [miscellany] global-ignores = bar foo % touch foo bar ]]] > but see parse_option() and > parse_value_continuation_lines() in subversion/libsvn_subr/config_file.c. (lldb) p

Tree conflict 'svn merge' message

I just tried to merge the swig-py3 branch into trunk [not in order to commit the merge, but only in order to run 'svn diff' on its result], and got the following output from 'svn merge': [[[ Summary of conflicts: Tree conflicts: 1 Searching tree conflict details for

Re: svn commit: r1813665 - in /subversion/branches/swig-py3: ./ build/ac-macros/ subversion/bindings/swig/ subversion/bindings/swig/include/ subversion/bindings/swig/python/libsvn_swig_py/

troycurti...@apache.org wrote on Sun, Oct 29, 2017 at 03:37:38 -: > On branch swig-py3: Use py3c library in Python swig bindings. > > Add the py3c Python compatibility library and update the python swig bindings > to use the compatibility functions that it provides. This is the first step to

Re: svn commit: r1819391 - /subversion/site/staging/docs/release-notes/1.10.html

Nathan Hartman wrote on Thu, 28 Dec 2017 23:50 -0500: > On Dec 28, 2017, at 5:59 PM, Stefan wrote: > > > > Suggestion for a different phrasing: > > > > section id: svn-1.9-old-stable > > > > The Subversion 1.9.x line is now the old stable version. This means > > that

Re: subversion support for APR 1.6 missing for windows?

Barry wrote on Thu, 28 Dec 2017 21:47 +: > Is there a plan to fix this in the svn code do you need a ticket? Tickets aren't required; posting on dev@ suffices to draw the right people's attention. (Though some of them may be on vacation) If you wish to write a patch please develop it

Re: svn commit: r1819391 - /subversion/site/staging/docs/release-notes/1.10.html

Stefan wrote on Thu, Dec 28, 2017 at 18:19:12 +0100: > On 28/12/2017 04:52, danie...@apache.org wrote: > > Author: danielsh > > Date: Thu Dec 28 03:52:02 2017 > > New Revision: 1819391 > > > > URL: http://svn.apache.org/viewvc?rev=1819391=rev > > Log: > > * docs/release-notes/1.10.html > >

Re: svn commit: r1819110 - /subversion/branches/swig-py3/subversion/bindings/swig/include/proxy.swg

Troy Curtis Jr wrote on Wed, 27 Dec 2017 02:48 +: > In taking another look at why hasattr() seeming fails in certain cases on > SWIG generated new style classes under python2, I ran across this article, > https://hynek.me/articles/hasattr/, which confirms that python 2's > hasattr() can

Re: svn commit: r1819207 - /subversion/trunk/tools/dist/edit-N-log-messages

danie...@apache.org wrote on Sun, 24 Dec 2017 08:54 +: > * tools/dist/edit-N-log-messages: New. > +++ subversion/trunk/tools/dist/edit-N-log-messages Sun Dec 24 08:54:08 > 2017 > @@ -0,0 +1,89 @@ > +usage() { > + echo "usage: $NAME -r N:M" > + echo " will retrieve all log messages in the

Re: svn commit: r1819110 - /subversion/branches/swig-py3/subversion/bindings/swig/include/proxy.swg

Troy Curtis Jr wrote on Sat, 23 Dec 2017 15:27 +: > On Fri, Dec 22, 2017 at 11:11 PM Daniel Shahaf <d...@daniel.shahaf.name> > wrote: > > > troycurti...@apache.org wrote on Sat, 23 Dec 2017 04:43 +: > > > Author: troycurtisjr > > > Date: Sat

Re: svn commit: r1819110 - /subversion/branches/swig-py3/subversion/bindings/swig/include/proxy.swg

troycurti...@apache.org wrote on Sat, 23 Dec 2017 04:43 +: > Author: troycurtisjr > Date: Sat Dec 23 04:43:26 2017 > New Revision: 1819110 > > URL: http://svn.apache.org/viewvc?rev=1819110=rev > Log: > On branch swig-py3: Replace hasattr check for a method with try-except. > > *

Re: Swig py3 branch

Troy Curtis Jr wrote on Sat, 23 Dec 2017 02:58 +: > I am currently having some home internet problems, so replying to Daniel's > irc query here via mobile. Thanks for this! For context, I asked about the state of the swig-py3 branch in relation to the backporting-non-bugfixes-to-1.10.0

Re: 1.10 tasks: update CHANGES and roll RC1 or beta1

Julian Foad wrote on Fri, 22 Dec 2017 15:08 +: > * Does the CHANGES file need to be updated before we can roll RC1? > > In my opinion this is a "documentation change" and we can release an RC1 > with incomplete CHANGES for the first 3 weeks of soak period, and > release RC2 with completed

Re: 1.10 tasks: update CHANGES and roll RC1 or beta1

Julian Foad wrote on Fri, 22 Dec 2017 15:08 +: > * What do we know about the current up-to-date-ness of CHANGES? > > It looks like a lot of changes are listed already. Do we have to review > every change since 1.9 or is there some subset of that work that we can > accept as having been done

Re: svn commit: r1818724 - /subversion/site/staging/faq.html

Stefan wrote on Tue, 19 Dec 2017 23:39 +0100: > On 19/12/2017 23:35, luke1...@apache.org wrote: > Originally I only intended to unbreak the links in the CVSSv2 section > but then decided to update the documentation to CVSSv3 which we are > using meanwhile. Ah, thanks! > Since I never calculated

Re: svn propchange: r1818584 - svn:log

danie...@apache.org wrote on Mon, 18 Dec 2017 18:12 +: > +++ svn:log Mon Dec 18 18:12:57 2017 > @@ -2,7 +2,11 @@ Fix a refcounting / cleanup race in svn_ > -https://lists.apache.org/thread.html/41ca5579bf7add3cb751234ea039fda531c1d22ffbed8cb2ec699e42@%3Cdev.subversion.apache.org%3E > +URL:

Re: svn commit: r1818578 - /subversion/trunk/subversion/libsvn_repos/list.c

Good morning Stefan, stef...@apache.org wrote on Mon, 18 Dec 2017 14:41 +: > Fix svn_repos_stat() implemention for directories to match the svn_dirent_t > docstring. > > * subversion/libsvn_repos/list.c > (fill_dirent): Make sure SIZE is 0 for directories. > > +++

Re: list --search matching and Windows *-expansion

Branko Čibej wrote on Mon, 18 Dec 2017 16:24 +0100: > On 18.12.2017 15:33, Stefan Fuhrmann wrote: > > On 18.12.2017 15:20, Johan Corveleyn wrote: > >> Spinning off this discussion from the "Subversion 1.10 RC1?" thread ... > >> > >> Do we still want to fix this somehow for 1.10? > >> > >> Doug

Re: svn commit: r1818496 - /subversion/site/staging/docs/release-notes/1.10.html

Stefan wrote on Sun, 17 Dec 2017 23:34 +0100: > On 17/12/2017 23:12, Evgeny Kotkov wrote: > > Daniel Shahaf <d...@daniel.shahaf.name> writes: > > > >> This language implies that we made a backwards incompatible change in 1.6, > >> which is not precisely

Re: svn commit: r1818496 - /subversion/site/staging/docs/release-notes/1.10.html

kot...@apache.org wrote on Sun, 17 Dec 2017 17:19 +: > +++ subversion/site/staging/docs/release-notes/1.10.html Sun Dec 17 17:19:23 > 2017 > @@ -692,6 +692,25 @@ or power loss, e.g. when loading a dump > + > +New --normalize-props option for svnadmin load > + + title="Link to this

Re: 1.10 task: error leaks

Julian Foad wrote on Fri, 15 Dec 2017 19:51 +: > r1818320. > > That's the lot. Thanks, Julian!

Re: Refreshing / redesigning our website

Branko Čibej wrote on Wed, Dec 13, 2017 at 16:24:34 +0100: > - Stop using server-side includes. As it is, Infra has to be reminded to > turn on SSI whenever they migrate our site to a new server. I don't deny the need to be practical, but the fact that infra made this mistake in past migrations

Re: [PATCH] release.py: write-changelog function (POC)

Johan Corveleyn wrote on Mon, Dec 04, 2017 at 12:16:37 +0100: > As promised on IRC last Friday, here is a POC implementation of the > "generate changelog from commit messages" functionality, We had some more discussion about this on IRC last Monday¹; I'll try to summarize. Goal: reduce the

Re: svn commit: r1817837 - in /subversion/trunk: CHANGES subversion/bindings/javahl/src/org/apache/subversion/javahl/NativeResources.java subversion/include/svn_version.h subversion/tests/cmdline/svnt

julianf...@apache.org wrote on Mon, 11 Dec 2017 21:18 +: > Increment the trunk version number, and introduce a new CHANGES > section for the upcoming 1.10.0 release. > +++ > subversion/trunk/subversion/bindings/javahl/src/org/apache/subversion/javahl/NativeResources.java > Mon Dec 11

Re: 1.10 task: error leaks

Julian Foad wrote on Mon, 11 Dec 2017 19:51 +: > Daniel Shahaf wrote: > > I think we should enable this warning by default in maintainer mode in > > supporting compilers, but that's a separate discussion to just fixing > > these error leaks in trunk (& 1.10.x). &g

1.10 task: error leaks

The release branch creation checkpoints calls for checking for error leaks, so here's the output of tools/dev/warn-unused-result.sh (after removing the __attribute__ from svn_error__malfunction()): [[[ subversion/libsvn_delta/branch.c:485:11: warning: ignoring return value of function declared

Re: svn commit: r1817775 - /subversion/site/publish/docs/community-guide/releasing.part.html

julianf...@apache.org wrote on Mon, 11 Dec 2017 13:41 +: > Modified: > subversion/site/publish/docs/community-guide/releasing.part.html Could you backport this to staging/ so future changes to staging don't merge conflict when they are published? > +++

Re: svn commit: r1817718 - /subversion/site/staging/docs/index.html / Reinstate 1.6 API docu

Stefan wrote on Sun, 10 Dec 2017 17:00 +0100: > Note that I'd reinstate the old 1.6 docus directly on publish (rather > than on staging) since this would be easier to do (i.e. reverting the > corresponding changes from r1696552 which obviously were done on publish). Given that staging/ is a

Re: svn commit: r1817713 - in /subversion/site/staging/docs/release-notes: 1.6.html 1.6.zh.html

Stefan wrote on Sun, 10 Dec 2017 15:15 +0100: > On 10/12/2017 15:06, luke1...@apache.org wrote: > > +++ subversion/site/staging/docs/release-notes/1.6.zh.html Sun Dec 10 > > 14:06:19 2017 > > @@ -698,7 +698,7 @@ href="https://svn.apache.org/repos/asf/s > >

Re: Authz - paths with trailing slash isn't supported - right?

Paul Hammant wrote on Sat, 09 Dec 2017 21:54 -0500: > > > > The cause of the 403 should be logged on the server side. > >> > > > > It was: > > > > [Sat Dec 09 22:24:47.803767 2017] [authz_svn:error] [pid 13] [client > > 172.17.0.1:35066] Failed to load the mod_authz_svn config: Section name > >

Re: Authz - paths with trailing slash isn't supported - right?

Paul Hammant wrote on Sat, 09 Dec 2017 16:22 -0500: > So, administrators of Svn installs should *not* create paths in authz files > with *trailing slashes* - like [/foo/] - right? I say that because my > attempts to do so yields plenty of unexplainable 403 responses in ordinary > clients like web

zsh completion updates (was: Re: Bash completion updates)

Julian Foad wrote on Fri, Dec 08, 2017 at 12:55:02 +: > Anyone fancy updating the completions for 'svnlook' and 'svnsync' which are > still out of date, and 'svnrdump' which is missing? I'll take this opportunity to point out that svn* completion for zsh is maintained in the zsh repository

1.10-dev doxygen not rebuilt recently

https://subversion.apache.org/docs/#next-release links to https://people.apache.org/~brane/svndocs/capi/ which was last rebuilt in March 2016. Could we get the cron job running again? I guess we should migrate it to svn-qavm since minotaur(people) is to be decommissioned. Brane — was there more

Re: Subversion 1.10 RC1?

Evgeny Kotkov wrote on Wed, Dec 06, 2017 at 00:12:55 +0300: > Unfortunately, on Windows both `--search M*` and (quoted) `--search "M*"` > would expand the asterisk. While this is not the default shell behavior, > currently it's enabled for svn and a couple of other binaries by linking > to

Re: [PATCH] release.py: write-changelog function (POC)

Johan Corveleyn wrote on Tue, 05 Dec 2017 00:04 +0100: > On Mon, Dec 4, 2017 at 11:01 PM, Julian Foad wrote: > > Johan Corveleyn wrote: > >> Just thinking out loud here ... > > > > [...]> H > > > > Now you're over-thinking it. What you said first, what you use at work,

Re: svn commit: r1816774 - /subversion/site/staging/mailing-lists.html

Stefan wrote on Thu, 30 Nov 2017 23:52 +0100: > On 30/11/2017 23:47, luke1...@apache.org wrote: > > Author: luke1410 > > Date: Thu Nov 30 22:47:41 2017 > > New Revision: 1816774 > > > > URL: http://svn.apache.org/viewvc?rev=1816774=rev > > Log: > > Drop links to gmane archive which is no longer

Re: svn commit: r1816596 - /subversion/branches/swig-py3/Makefile.in

Troy Curtis Jr wrote on Thu, 30 Nov 2017 02:20 +: > On Wed, Nov 29, 2017, 10:08 AM Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > troycurti...@apache.org wrote on Wed, 29 Nov 2017 03:50 +: > > > * Makefile.in > > > (EXTRACLEAN_SWIG_PY): Chan

Re: svn commit: r1816596 - /subversion/branches/swig-py3/Makefile.in

troycurti...@apache.org wrote on Wed, 29 Nov 2017 03:50 +: > Author: troycurtisjr > Date: Wed Nov 29 03:50:09 2017 > New Revision: 1816596 > > URL: http://svn.apache.org/viewvc?rev=1816596=rev > Log: > On branch swig-py3: Fix clean-swig-py for out-of-source builds. > > * Makefile.in >

<    5   6   7   8   9   10   11   12   13   14   >