Re: Subversion Exception!

rt(). Now the user lost the other 10 images as well because abort() ends the application with NO possibility to either save changes first. Sorry if this message seems rude - but I'm tired of arguing the same over and over again. Stefan -- ___ oo // \\ "De Chelo

Re: Time for new patch releases: 1.11.1, 1.10.4, 1.9.10

On Mon, Dec 10, 2018 at 03:09:46PM +, Julian Foad wrote: > More than 10 fixes have been back-ported to *each* of 1.11, 1.10, 1.9 since > their last releases. Looks like it's time to make new patch releases. > > In addition, there are a few outstanding backport nominations for each. > Please

Re: Support character classes in glob authz rules

On Mon, Dec 03, 2018 at 09:30:53AM +0100, Stefan Sperling wrote: > On Mon, Dec 03, 2018 at 08:15:24AM +, Julian Foad wrote: > > Branko Čibej wrote: > > > The proposed change in the parser is only enabled for parsing authz and > > > global group files, other Subversi

Re: Support character classes in glob authz rules

On Mon, Dec 03, 2018 at 08:15:24AM +, Julian Foad wrote: > Branko Čibej wrote: > > The proposed change in the parser is only enabled for parsing authz and > > global group files, other Subversion configuration files will use the > > current semantics. > > These sorts of quirks tend to make a s

Re: Fwd: [Daniel Shahaf: [PATCH] Re: [PATCH] A test for "Can't get entries" error]

On 21.11.18 16:00, Daniel Shahaf wrote: Good morning Stefan, Forwarding from dev@. tl;dr: False positive SVN_ERR_FS_NOT_DIRECTORY error, with test¹, workaround, analysis, and patch. The error doesn't happen with caches disabled so I thought you might be interested. Cheers, Daniel

Re: truncated author names in 'svn ls -v' output

On Mon, Nov 26, 2018 at 04:30:27PM +0100, Vincent Lefevre wrote: > On 2018-11-26 15:18:47 +0100, Branko Čibej wrote: > > Do please read the rest of the thread. A solution has already been > > implemented on trunk. > > Except that this solution is not satisfactory for me. I guess that > the ultimat

Re: truncated author names in 'svn ls -v' output

On Sun, Nov 25, 2018 at 06:06:20AM +0100, Branko Čibej wrote: > On 23.11.2018 18:47, Branko Čibej wrote: > > On 23.11.2018 10:40, Daniel Shahaf wrote: > >> Branko Čibej wrote on Fri, 23 Nov 2018 10:15 +0100: > >>> On 23.11.2018 09:10, Stefan Sperling wrote: > >

truncated author names in 'svn ls -v' output

nventional usernames follow a FirstName.LastName style. Under this scheme, my own name would be indistinguishable from that of Eastern European soccer players Stefan Spremo and Stefan Spirovski. While I find this flattering, I don't think these soccer players would enjoy getting mixed up with each

Re: [PATCH] svn/conflict-callbacks.c indentation fix

On Fri, Nov 02, 2018 at 10:49:23AM +0100, Branko Čibej wrote: > On 02.11.2018 10:44, Stefan Sperling wrote: > > I confirm that your patch is correct. I mis-indented these blocks. > > Time to start using a real editor, I guess? :) The further I progress into adulthood, th

Re: [PATCH] svn/conflict-callbacks.c indentation fix

On Fri, Nov 02, 2018 at 09:39:47AM +, Joe Orton wrote: > There are two gcc 8.x (I'm using 8.2.1) warnings from which catch those: > > if (foo) > bar; > baz; > > type of errors. I fixed one case which looks obviously like a false > positive in r1845556, but I'm not sure about the

Re: [PATCH] Suppress conflict resolver in dry-run merge

On Thu, Nov 01, 2018 at 05:38:48PM +0100, Branko Čibej wrote: > On 01.11.2018 17:25, Stefan Sperling wrote: > > While many SVN operations support a dry-run mode, at present the conflict > > resolver does not. It might actually be nice to see what the resolver would > > do whi

Re: [PATCH] Suppress conflict resolver in dry-run merge

On Thu, Nov 01, 2018 at 05:25:10PM +0100, Stefan Sperling wrote: > Until the resolver grows such a dry-run mode I think your patch makes sense. > Do we agree here? Committed in https://svn.apache.org/r1845557 with small whitespace adjustments to keep lines below 80 columns in length. I hav

Re: [PATCH] Suppress conflict resolver in dry-run merge

On Thu, Nov 01, 2018 at 10:32:56AM +, Jonathan Guy wrote: > Ok I looked into this a bit more and I see what's going on now. > The post merge conflict resolver runs because the merge operation reported > conflicts (via the conflict stats). > This calls > svn_client_conflict_walk > which

Re: [PATCH] Suppress conflict resolver in dry-run merge

On Wed, Oct 31, 2018 at 09:46:23AM +, Jonathan Guy wrote: > Hi Stephan > Thanks for the reply. > I did see code section you refer to however the svn_client__resolve_conflicts > will only be called if you have ctx->conflict_func2. > That function (AFAIK) is only installed if an “accept” option

Re: [PATCH] Suppress conflict resolver in dry-run merge

ctx, iterpool)); if (conflicts_remain) break; So your patch is redundant and we don't need to apply it. I should have tested the current behaviour before recommending that you send a patch. Regardless, thank you for your contribution! Stefan

Re: Disabling plain-text password storage by defult

On Wed, Oct 31, 2018 at 02:49:57AM +0100, Branko Čibej wrote: > Given that we support a number of secure credentials stores, I propose > that, starting with 1.14.0 LTS, we disable the on-disk plain-text > password store by default. Why not start with 1.12.0?

Re: Merge dry-run and conflict resolution

On Tue, Oct 30, 2018 at 10:27:28AM +0100, Branko Čibej wrote: > [Moving to dev@ as this is more of a development question.] > > On 30.10.2018 09:35, Jonathan Guy wrote: > > Hi all > > Just looking over the code for the interactive conflict resolution. > > This is just an initial observation but in

Re: Subversion 1.11.0 up for testing/signing

On Mon, Oct 29, 2018 at 02:53:59PM +, Julian Foad wrote: > The 1.11.0 release artifacts are now available for testing/signing. > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. > > Differences from 1.11.0-rc2 should be limited

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

On Fri, Oct 26, 2018 at 12:11:57PM +0200, Branko Čibej wrote: > On 26.10.2018 12:07, s...@apache.org wrote: > > Author: stsp > > Date: Fri Oct 26 10:07:21 2018 > > New Revision: 1844884 > > > > URL: http://svn.apache.org/viewvc?rev=1844884&view=rev > > Log: > > * STATUS: Nominate r1844882. > > > >

Re: Subversion 1.10.3 up for testing/signing

On 05.10.2018 17:49, Julian Foad wrote: The 1.10.3 release artifacts are now available for testing/signing. Please get the tarballs from https://dist.apache.org/repos/dist/dev/subversion and add your signatures there. Thanks! Summary: +1 to release Platform Ubuntu 16.04.5 x64, Linux

Re: Subversion 1.10.3 up for testing/signing

On Fri, Oct 05, 2018 at 04:49:50PM +0100, Julian Foad wrote: > The 1.10.3 release artifacts are now available for testing/signing. > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. > > Thanks! Summary: +1 to release Tested: [bdb

Re: Hide experimental APIs to unblock 1.11 release

On Thu, Sep 20, 2018 at 10:13 PM Julian Foad wrote: > Julian Foad wrote: > > Stefan Kueng wrote: > > > but then that would mean I wouldn't get any compiler > > > error if I actually use a private and not just an experimental API. > > > > That'

Re: Subversion 1.11.0-rc2 up for testing/signing

On Fri, Sep 28, 2018 at 04:14:48PM +0100, Julian Foad wrote: > The 1.11.0-rc2 release artifacts are now available for testing/signing. > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. Summary: +1 to release Tested: [bdb | fsfs]

please review outstanding backports for 1.10.x

Julian and myself would like to start preparing another 1.10.x release over the coming week, to be relased close to 1.11.0. There are 9 pending nominations in 1.10.x/STATUS currently, and 4 bug fixes have already been merged to the 1.10.x branch since 1.10.2. All these fixes would provide good su

Re: Using APR pools "better"

On Wed, Sep 26, 2018 at 04:15:19PM -0500, Greg Stein wrote: > iterpool, scratch_pool, and result_pool are the KEY three concepts that we > learned while working on Subversion. Here's a recent example of where and why we added an iterpool (which should have been added when this loop was written in

Re: svn commit: r1841719 - /subversion/trunk/subversion/tests/libsvn_client/conflicts-test.c

On Mon, Sep 24, 2018 at 02:39:08AM +0200, Johan Corveleyn wrote: > ^^ copy-paste-o in comment 'A/mu' -> 'A/B' Thank you. Should all be fixed with r1841796.

Re: msguniq in po-update.sh

On Sun, Sep 23, 2018 at 11:06:40PM +0200, Mattias Engdegård wrote: > Sorry about messing up the build with my ill-considered merge of r1841318 > (sv.po). Instead of attempting to merge from 1.11.x, which is what caused the > duplicated msgids, I should just have copied the entire file from that bra

Re: Hide experimental APIs to unblock 1.11 release

as experimental, and IMHO that's good enough (at least for now). Stefan -- ___ oo // \\ "De Chelonian Mobile" (_,\/ \_/ \ TortoiseSVN \ \_/_\_/>The coolest interface to (Sub)version control /_/ \_\ http://tortoisesvn.net

Re: Subversion 1.11.0-rc1 up for testing/signing

On 13.09.2018 14:13, Julian Foad wrote: The 1.11.0-rc1 release artifacts are now available for testing/signing. Please get the tarballs from https://dist.apache.org/repos/dist/dev/subversion and add your signatures there. Thanks! Since I don't know if & when I will find time to address th

Re: API review for 1.11; do we need to mark new APIs as experimental?

On Sun, Sep 16, 2018 at 05:13:47PM +0100, Julian Foad wrote: > Stefan Sperling wrote: > > I'm starting to wonder what the point of public experimental APIs really is. > > [...] > > What about just making such APIs private and available under > > include/private?

Re: API review for 1.11; do we need to mark new APIs as experimental?

On Sun, Sep 16, 2018 at 12:30:24PM +, Daniel Shahaf wrote: > Thanks for elaborating on that, Greg. I agree that the scenario you > describe is something we should design to prevent. > > In a nutshell, I think the point is that we promise ABI forward > compatibility should deliver that even fo

Re: thoughts about shelving

very urgent, just something you might want to consider. in case you're interested, here are screenshots of the shelve and unshelve dialog I did in TSVN: https://svn.osdn.net/svnroot/tortoisesvn/trunk/doc/images/en/Shelve.png https://svn.osdn.net/svnroot/tortoisesvn/trunk/doc/images/en/Unshelve.png Stefan

thoughts about shelving

not finished yet implementing everything in TSVN I might have some more comments soon. Stefan

Re: Suggestion: linkify revnums and issues in the CHANGES file

On Thu, Sep 13, 2018 at 11:50:57AM +0100, Julian Foad wrote: > Stefan Sperling wrote: > > I don't think many people follow these references when reading CHANGES. > [...] > > I believe a short note at the top of the file which explains how to > > resolve these r

Re: Suggestion: linkify revnums and issues in the CHANGES file

On Thu, Sep 13, 2018 at 10:01:25AM +0100, Julian Foad wrote: > It seems to me rather poor that readers of our CHANGES file have to manually > follow references to revision numbers and issue numbers. Examples: > [[[ > - Server-side bugfixes: > * svnadmin dump shouldn't canonicalize svn:date (

Re: Suggestion: linkify revnums and issues in the CHANGES file

On Thu, Sep 13, 2018 at 12:00:39PM +0200, Branko Čibej wrote: > Given all the debate we've had about how to edit and merge the CHANGES > file on trunk and release branches ... how about only having the change > log in the wiki, with CHANGES containing only a pointer to the wiki page? My impression

Re: Feature freeze for 1.11

On Sat, Sep 08, 2018 at 05:38:44PM +0100, Julian Foad wrote: > I plan to make the 1.11.x branch in the next few days if I'm satisfied with > the items below. The conflict resolver does not support ambiguous moves yet for 'local missing' conflicts. I hope to get to that soon. Patches for this cou

Re: authz changes between 1.9 and 1.10

ts but given issue 4762 I not sure whether it describes the correct behaviour. User documentation on the new authz is inadequate. -- Stefan^2.

On my hiatus

contributions by the end of this year - but I cannot promise that. Until then, I will give some input on the things I've seen being discussed on the list. -- Stefan^2.

Re: svn commit: r1838746 - /subversion/site/staging/download.html

On 25/08/2018 18:06, sebb AT ASF wrote: > On 25 August 2018 at 13:44, Stefan wrote: >> On 25/08/2018 14:37, Stefan wrote: >>> On 23/08/2018 20:01, s...@apache.org wrote: >>>> Author: sebb >>>> Date: Thu Aug 23 18:01:30 2018 >>>> New Revisio

Re: svn commit: r1839039 - /subversion/site/staging/download.html

s. >> + On Windows you can use the certutil command line tool, for instance. > Perhaps add the specific --option flags here? Or at least use > tags to get the monospaced font. Added more specific usage sample for cerutils (incl. the missing -tags) in r1839052. Regards, Stefan

Re: svn commit: r1838746 - /subversion/site/staging/download.html

On 25/08/2018 14:37, Stefan wrote: > On 23/08/2018 20:01, s...@apache.org wrote: >> Author: sebb >> Date: Thu Aug 23 18:01:30 2018 >> New Revision: 1838746 >> >> URL: http://svn.apache.org/viewvc?rev=1838746&view=rev >> Log: >> SVN-4736 - fix g

Re: svn commit: r1838746 - /subversion/site/staging/download.html

On 23/08/2018 20:01, s...@apache.org wrote: > Author: sebb > Date: Thu Aug 23 18:01:30 2018 > New Revision: 1838746 > > URL: http://svn.apache.org/viewvc?rev=1838746&view=rev > Log: > SVN-4736 - fix gpg command > > Modified: > subversion/site/staging/download.html > > Modified: subversion/site/

Re: "Permission denied" committing to sourceforge

On Fri, Aug 10, 2018 at 08:44:08AM +0200, Thomas Singer wrote: > Hi, > > When trying to commit to a sourceforge repository using a self-compiled SVN > binary, I'm getting following error: > > D:\temp\irrlicht>svn.exe commit --username HinzKunz -m "a message" > Authentication realm:

Re: Bug report: Regression SVN Client, SSL, Serf 1.3.9-3, SSLVerifyClient require

ever, though then in a more general manner like: Troubleshooting Subversion SSL connection. -- Regards, Stefan Hett

New MaxSVN releases (incl. 1.9.9 and 1.10.2)

- provide early access to versions of SVN while they are in development - provide a distribution which can be used to debug/test issues yourself (by shipping symbol files) Regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature

Re: Subversion 1.9.9 up for testing/signing

qeyA4X4ik0WQLs1NCEcZ5PpMDgDIDPXBi/UjdRai96ND kJDuwYUYHaB3cn3ROwF5RIosdZv1gbWWGYN/2agMWXZpAOvQvOs= =mKpT -END PGP SIGNATURE- Regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature

Re: Subversion 1.10.2 up for testing/signing

3clWmFXRDwm34= =DKZZ -END PGP SIGNATURE- Regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature

Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches

On 17/07/2018 11:24, Branko Čibej wrote: > On 17.07.2018 11:17, Stefan wrote: >> That said, if the majority of the team is fine with a change, so will >> I be in the end and won't argue against it. > Correction: not "if the majority of the team etc." but "

Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches

On Mon, Jul 16, 2018 at 05:49:53PM +0100, Julian Foad wrote: > Julian Foad wrote: > > Stefan Sperling wrote: > > >I ran a sync merge from trunk/CHANGES to branch/CHANGES, and manually > > >deleted any entries above the one for the release being prepared. > > >

Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches

rsion's branch but were not yet backported to the previous version * just reading up old changelog entries out of interest As stated, none of these are major arguments against changing our process, but still I'd personally miss a complete changelog. That said, if the majority of the team is fine with a change, so will I be in the end and won't argue against it. Regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature

Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches

On Fri, Jul 13, 2018 at 05:12:04PM +0100, Julian Foad wrote: > I guess previous release managers merged the relevant changes manually to > achieve this. I ran a sync merge from trunk/CHANGES to branch/CHANGES, and manually deleted any entries above the one for the release being prepared. This wo

Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches

On 13/07/2018 18:12, Julian Foad wrote: > Stefan Hett wrote: >> On 7/13/2018 4:28 PM, Branko Čibej wrote: >>> On 13.07.2018 16:19, Julian Foad wrote: >>>>svn ps svn:externals '^/subversion/CHANGES CHANGES' trunk-wc/. >>> This would be mildly

Re: [RFC] Move CHANGES and COMMITTERS out of trunk/branches

. FWIW, changing COMMITTERS is usually the first task we give to new committers ... it's sort of easier for them to have that on trunk. It should not be too hard to make release.py do a sync-merge to the release branch. +1 [...] -- Regards, Stefan Hett

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

sting the release" and "to allow anybody planning > to test the release" is helpful. I suggest to pick one and drop the other :-) Done in r1835497 (incl. some more minor rephrasing). Regards, Stefan

Re: change release signature requirements?

On 05/07/2018 23:34, Julian Foad wrote: > Stefan wrote: >> Done in r1835191. > > Great -- except didn't we mean to change it to say "at least one on > each platform"? It still says "three"... > > - Julian > > Correct, my oversight -

Re: change release signature requirements?

On 03/07/2018 00:54, Stefan wrote: > On 29/06/2018 17:38, Julian Foad wrote: >> Stefan wrote: >> [...] >> >> Do you want to go ahead and update it (after waiting 5 days for >> anybody else to chime in)? > Will do Thursday 2018-07-05 to give everybody enough

Re: change release signature requirements?

On 29/06/2018 17:38, Julian Foad wrote: > Stefan wrote: >> new: >> [...] Before a release is officially made public, it must receive >> three +1 votes from members of the Subversion PMC. In addition, as a >> matter of project policy, we require testing and signatur

Re: change release signature requirements?

On 24/06/2018 08:20, 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 > signatures required for a release. > > While we never failed to meet the current requirements event

Re: Intentions for 1.11 release timing

On Mon, Jun 25, 2018 at 05:54:14PM +0100, Julian Foad wrote: > Julian Foad wrote: > > Forget about overlap periods, for a moment. Then there will be usually 3 > > supported lines (after a standard release) and sometimes 2 [...] > > I am wondering if we have been mis-thinking the support plans. Wh

Re: Roadmap.html

On Mon, Jun 25, 2018 at 04:09:40PM +0100, Julian Foad wrote: > I have been updating http://subversion.apache.org/roadmap.html > > For the "Next Release Status" section, AFAIK Shelving and Checkpointing are > the only features being worked on. > > Any further thoughts or info to add, anyone? > >

Re: #4754: Status Cache

On Mon, Jun 25, 2018 at 01:44:21PM +0200, Branko Čibej wrote: > On 25.06.2018 13:37, Stefan Sperling wrote: > > On Mon, Jun 25, 2018 at 01:29:04PM +0200, Branko Čibej wrote: > >> On 25.06.2018 13:21, Julian Foad wrote: > >>> Can someone confirm this makes sense as a

Re: #4754: Status Cache

On Mon, Jun 25, 2018 at 01:29:04PM +0200, Branko Čibej wrote: > On 25.06.2018 13:21, Julian Foad wrote: > > Can someone confirm this makes sense as a feature request? > > > > I know the usual caveats apply: details need to be filled in, and lack of > > resources; but basically? > > Basically, sur

Re: #4754: Status Cache

On Mon, Jun 25, 2018 at 12:21:03PM +0100, Julian Foad wrote: > I just filed https://issues.apache.org/jira/browse/SVN-4754 with this > description: > > [[[ > Core svn should provide a way to cache WC status results, so clients can get > a quick answer to questions like "is the WC modified?" > >

Re: change release signature requirements?

On Mon, Jun 25, 2018 at 10:56:21AM +, Daniel Shahaf wrote: > For clarity, I assume this applies to all future releases, including any > future patch releases of the 1.8/1.9/1.10 lines. Yes, it does. Having two different processes in place simultaneously for different release streams would be

change release signature requirements?

While we're on the subject of changing the supported release process, we could use this opportunity to lower the number of signatures required for a release. While we never failed to meet the current requirements eventually, our release process could be faster if less signatures were required. My

Re: handling of reparse points

is always a junction, but that's not the case. A junction is just a special form of a reparse point. Well, the more patches we get to fix these issues, the better. In the mean time, can we apply my patch to make things work with OneDrive folders? Stefan

Re: handling of reparse points

On 05.06.2018 23:35, Philip Martin wrote: Stefan Küng writes: Index: subversion/libsvn_subr/io.c === --- subversion/libsvn_subr/io.c (revision 1831874) +++ subversion/libsvn_subr/io.c (working copy) @@ -342,8 +342,11

Re: handling of reparse points

On Sat, May 26, 2018 at 7:35 AM Stefan Küng wrote: > Next try, patch attached. > Basically what this does is to never check for soft/hard links on Windows > ever. Since Subversion doesn't really handle those on Windows anyway, > checking for them doesn't make sense and cau

Re: handling of reparse points

ms to work fine. Stefan On Fri, May 25, 2018 at 8:30 PM Stefan Kueng wrote: > > > On 25.05.2018 18:07, Daniel Shahaf wrote: > > Stefan Küng wrote on Fri, 25 May 2018 17:37 +0200: > >> Can anyone comment on this please? > > > > I'm not familiar with the

Re: handling of reparse points

On 25.05.2018 18:07, Daniel Shahaf wrote: 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. And I'm not familiar with soft/hardlinks on Linux. :) If I do 'm

Re: handling of reparse points

Can anyone comment on this please? On Fri, May 18, 2018 at 10:29 PM Stefan Kueng wrote: > Hi, > > It seems that svn doesn't handle reparse points properly in all > situations. Which causes big problems for TSVN when a working copy is on > a Onedrive folder. > >

Re: Minimum version of JDK for Subversion 1.10 (was Re: JDK 10 removal of javah)

On Sun, May 20, 2018 at 12:47:39PM +0200, Michael Osipov wrote: > > On 18.05.2018 14:34, Stefan Sperling wrote: > > > I think you should aim to proceed with your plan as it was. > > > If anyone has strong objections to this, they should be constructive and > > &

handling of reparse points

ven if they point to directories. IMHO handling links/reparse-points specially is only required in very specific situations, like adding them. In most cases, resolving the links/reparse points is what should be done. Or am I missing something big here? Stefan Index: subversion/libs

Re: Intentions for 1.11 release timing

On 5/18/2018 4:27 PM, Julian Foad wrote: Stefan Sperling wrote on 2018-05-18: On Fri, May 18, 2018 at 02:54:03PM +0100, Julian Foad wrote: 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

Re: Intentions for 1.11 release timing

On Fri, May 18, 2018 at 02:54:03PM +0100, Julian Foad wrote: > Stefan Sperling wrote: > > On Fri, May 18, 2018 at 02:29:25PM +0100, Julian Foad wrote: > > > Branch for stabilization 4 months after the last release (which was in > > > 2018-04), so: > > > >

Re: Intentions for 1.11 release timing

On Fri, May 18, 2018 at 02:29:25PM +0100, Julian Foad wrote: > Branch for stabilization 4 months after the last release (which was in > 2018-04), so: > > * Branch in 2018-08 > * Aim to release in 2018-10 Wouldn't we also have to adjust our backporting guidelines if we did this? Would 1.10 on

Re: Minimum version of JDK for Subversion 1.10 (was Re: JDK 10 removal of javah)

On Fri, May 18, 2018 at 02:36:06PM +0200, Branko Čibej wrote: > On 18.05.2018 14:34, Stefan Sperling wrote: > > On Fri, May 18, 2018 at 08:22:46AM -0400, James McCoy wrote: > >> On Fri, May 18, 2018 at 09:46:41AM +0200, Stefan Sperling wrote: > >>> Elsewhere in

Re: Minimum version of JDK for Subversion 1.10 (was Re: JDK 10 removal of javah)

On Fri, May 18, 2018 at 08:22:46AM -0400, James McCoy wrote: > On Fri, May 18, 2018 at 09:46:41AM +0200, Stefan Sperling wrote: > > Elsewhere in this discussion thread it was suggested to raise the > > minimum JDK version requirement to Java 1.8. > > Your statement

Re: JDK 10 removal of javah

On Fri, May 18, 2018 at 08:40:35AM +0200, Thomas Singer wrote: > Whatever you do, please keep backward compatibility with older JDKs. Reason > is building on older OS X machines for most compatibility which do not allow > latest JDKs. > > Thanks for considering. Could you be more specific about w

Re: JDK 10 removal of javah

.11.x based on when we'll ship that version. [1] = http://www.oracle.com/technetwork/java/eol-135779.html [2] = https://en.wikipedia.org/wiki/Java_version_history#Java_6_updates [3] = https://en.wikipedia.org/wiki/Java_version_history#Java_7_updates -- Regards, Stefan Hett

Re: [PATCH] fix libsvn_auth_gnome_keyring.pc w/libsecret

On Thu, May 03, 2018 at 09:11:33AM +0100, Philip Martin wrote: > Philip Martin writes: > > > Philip Martin writes: > > > >>> Fixes libsvn_auth_gnome_keyring.pc when configured with libsecret, and > >>> make dependencies private. > >> > >> Looks OK to me. > > > > Perhaps we should delete the .pc

Re: Possible bug in the tree conflict resolver: "Accept incoming deletion" option doing nothing for a locally deleted file

On Tue, Apr 24, 2018 at 06:16:00PM +0300, Evgeny Kotkov wrote: > Hi everyone, > > I think that I might have stumbled across an issue with the new tree conflict > resolver in case of a delete-vs-delete conflict. Below is a simple > PowerShell- > based reproduction script that adds a file (r1), re

New MaxSVN releases (incl. 1.8.19, 1.9.7, and 1.10.0)

stribution which can be used to debug/test issues yourself (by shipping symbol files) Regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature

Re: move certain svn props to top level path?

not a non-controversial matter so I'm certainly fine with leaving this for tags as they are, of course. :-) Regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature

Re: Documentation to build SVN 1.10

oesn't build with SQLite <= 3.8.11.1? The configure script and INSTALL documentation suggests the minimum version should still be 3.8.2 (for 1.9 it was 3.7.12). -- Regards, Stefan Hett, Developer/Administrator

Re: Documentation to build SVN 1.10

On Wed, Apr 18, 2018 at 10:50:15AM +0200, Thomas Singer wrote: > Hi developers, > > I'm trying to build SVN 1.10 on CentOS 6.2 based on a black-box build script > that I have for SVN 1.9. So far it looks like SVN 1.10 requires a newer > sqlite-amalgamation-3081101.zip and requires something regard

Re: move certain svn props to top level path?

On 16/04/2018 09:15, Julian Foad wrote: > Branko Čibej wrote: >> On 15.04.2018 23:42, Stefan wrote: >>> On 15/04/2018 22:56, Julian Foad wrote: [...] > >>>> - If the properties are not set for a folder, the client should >>>> search upwards >>&

Re: move certain svn props to top level path?

On 15/04/2018 22:56, Julian Foad wrote: > Branko Čibej wrote on 2018-04-15: >> On 15.04.2018 21:01, Stefan wrote: >>> On 05/04/2018 00:09, Stefan wrote: >>>> I'm not sure if there are other tools around using these. I'm talking >>>> here TSVN

Re: move certain svn props to top level path?

On 05/04/2018 00:09, Stefan wrote: > On 04/04/2018 23:47, Branko Čibej wrote: >> On 04.04.2018 23:12, Stefan wrote: >>> Hi, >>> >>> atm we specify the following svn properties on trunk: >>> >>> * bugtraq:url >>> * bugtraq:log

Re: Subversion1.10.0 up for testing/signing

On 11/04/2018 09:31, Julian Foad wrote: > The 1.10.0 release artifacts are now available for testing/signing. > Please get the tarballs from >   https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. > > Thanks! > - Julian Summary ---     +1 to release Platform ---

Re: Subversion1.10.0 up for testing/signing

On Wed, Apr 11, 2018 at 08:31:25AM +0100, Julian Foad wrote: > The 1.10.0 release artifacts are now available for testing/signing. > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. > > Thanks! > - Julian Summary: +1 to release M

Re: [PATCH] Fix for SVN 1.8 with sqlite >= 3.12.0 and VS 2005+

On 18/11/2016 12:23, Stefan Hett wrote: > On 7/26/2016 12:13 AM, Stefan wrote: >> >> Hi, >> >> building SVN 1.8 using sqlite >= SQLite 3.12.0 (amalgamation) and VS >> 2005+ raises the following error: >> >> [...]\sqlite\sqlite3.c(42437): err

Re: Fix for SVN 1.7 with sqlite >= 3.12.0 and VS 2005+

On 18/07/2016 00:08, Stefan wrote: > On 7/17/2016 22:09, Branko Čibej wrote: >> On 17.07.2016 20:53, Stefan wrote: >>> Hi Daniel, >>>> Stefan wrote on Thu, Jul 14, 2016 at 00:14:31 +0200: >>>>> Note that SVN 1.7 is EOL and therefore isn't supporte

Re: Fwd: Returned post for annou...@apache.org

o I'd place it right below the first line (after "Apache Subversion [version].") but then there's already the link to the download page two lines below... Therefore, I'm quite a bit unsure about whether it wouldn't be unnecessary and just bloat the mail with yet another link... So I'll better leave that part for someone else to decide (not going to argue against it being added). Regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature

Re: move certain svn props to top level path?

On 04/04/2018 23:47, Branko Čibej wrote: > On 04.04.2018 23:12, Stefan wrote: >> Hi, >> >> atm we specify the following svn properties on trunk: >> >> * bugtraq:url >> * bugtraq:logregexp >> * tsvn:logwidthmarker >> * tsvn:projectlanguag

move certain svn props to top level path?

these properties just once at the top level (i.e. on https://svn.apache.org/repos/asf/subversion) and remove them on the sub-nodes (i.e. trunk, branches/xxx, tags/xxx, etc.). This will ensure we have a consistent setting for these project wise. Thoughts? Regards, Stefan smime.p7s Description: S

Re: Subversion1.10.0-rc2 up for testing/signing

On 29/03/2018 15:17, Julian Foad wrote: > The 1.10.0-rc2 release artifacts are now available for testing/signing. > Please get the tarballs from >   https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. > > Thanks! Summary ---     +1 to release Platform  

Re: Subversion1.10.0-rc2 up for testing/signing

On 29.03.2018 15:17, Julian Foad wrote: The 1.10.0-rc2 release artifacts are now available for testing/signing. Please get the tarballs from https://dist.apache.org/repos/dist/dev/subversion and add your signatures there. Thanks! Summary:   +1 to release Platform   Ubuntu 16.04.4 x64, Linux

Re: Warnings from the bindings

l fix and we are now seeing the remaining unpatched occurrences. -- Stefan^2.

<    1   2   3   4   5   6   7   8   9   10   >