On Tue, Nov 14, 2017 at 03:57:45PM +, Sam White wrote:
> Hi Developers,
>
> I propose the addition of an equivalent to the --parents option to "svn
> commit", to check in the directory structure as well as any files
> specified.
>
> I understand that with svn add, the --parents option is avai
Thanks Sally,
everything which will increase the visibility of the event is much
appreciated.
Regards,
Stefan
On 12/11/2017 19:09, Sally Khudairi wrote:
> Thanks, Stefan. I'll add it to the Apache Weekly News Round-Up and will
> also promote on our social channels.
>
> Here&#x
On 26/10/2017 22:34, Stefan wrote:
> Hi,
>
> the Apache Subversion project organizes a yearly hackathon for its
> project members. This year we are planning something special during that
> event for the community as well: A meet-and-greet event.
>
> If you always wanted to
On Fri, Nov 03, 2017 at 01:33:03PM +0100, Vincent Lefevre wrote:
> As I thought, I couldn't reproduce the bug with such a sample
> repository.
>
> But I've found that the bug is fixed in the trunk. I could bisect
> to search for the fix, and this is the following:
>
>
On Fri, Nov 03, 2017 at 10:53:07AM +0100, Vincent Lefevre wrote:
> On 2017-11-03 10:01:26 +0100, Stefan Sperling wrote:
> > I agree this looks like a bug. However, it is unclear how to reproduce it.
> >
> > Can you provide a sample repository (or shell script) which
On Fri, Nov 03, 2017 at 12:44:03AM +0100, Vincent Lefevre wrote:
> On 2017-11-03 00:18:59 +0100, Vincent Lefevre wrote:
> > cventin:~> svn ls -r99809
> > file:///home/vlefevre/private/svn-tmp/perso/tcl/fidelite@99808
> > svn: E160016: Failure opening '/perso/tcl/fidelite'
> > svn: E160016: '/perso
On 26/10/2017 23:28, Branko Čibej wrote:
> [Restoring all Cc:]
> On 26.10.2017 22:34, Stefan wrote:
>> The meet-and-greet event will happen on November 23rd in Aachen at 8pm
>> local time (UTC: +02:00).
>
> On 23rd November it will be UTC+01:00, daylight savings time in t
e interested in joining us, please send me a PM and whether you
are planning to have dinner there as well (or just come over for a
drink), so I can make sure we get a proper location which is large
enough for all of us.
Regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
On Tue, Oct 10, 2017 at 05:32:21PM -0400, Paul Hammant wrote:
> >
> >
> > Anybody knows why asfgit closed the PR?
> >
> > I've clicked on the above hyperlink, and saw some comments made by
> > Julian (11 hours ago) and by the submitter (8 hours ago), but these
> > comments are not visible on dev@.
;
> The event is planned to be held in Aachen, Germany in the late November.
> The approximate dates for the main part of this event are either November
> 13-17th or 20-24th. One of the Subversion PMC members, Stefan Hett, who
> currently resides in Aachen, is going to take on most of th
On Sat, Oct 07, 2017 at 03:18:11PM -0700, William Orr wrote:
> Thanks for the feedback. I've finally gotten the chance to update the
> patch with the suggestions. Lemme know if this addresses your concerns,
> and I can write up the changelog for it.
>
> Thanks,
> William Orr
>
Thanks. Some remar
ore we try
presenting this prototype to a wider range of users outside the
dev-lists. For a start, 'Unshelve' should show a list of previously
shelved patches and allow selecting one from the list, with the most
recent one chosen by default.
- Julian
--
Regards,
Stefan Hett
eate all sorts of compatibility issues
with rules to address them and all for a limited increase in coding
convenience.
-- Stefan^2.
as just for the
sake of the //-comment-usage.
But I see that there's some reluctance to make this step, and while I'd
certainly would appreciate us moving ahead, I personally also don't see
that much an urge to use C99-features atm. Hence, I'll leave the idea
rested now.
Regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
On 24/09/2017 19:55, Branko Čibej wrote:
> On 24.09.2017 11:36, Stefan wrote:
>> On 22/09/2017 13:29, Branko Čibej wrote:
>>> On 22.09.2017 13:18, Julian Foad wrote:
>>>> Julian Foad wrote:
>>>>> When we released Subversion 1.0 in 2004, we were st
.
As far as I see it, one of the main restrictions we regularly face is
the use of //-comment styles (especially when talking here integrated
external libraries/code). This is something which has long been
supported even in VS.
The wikipedia page also provides quite a summary of C99-support in
different compilers [1].
Regards,
Stefan
[1] https://en.wikipedia.org/wiki/C99#Implementations
On Tue, Sep 19, 2017 at 05:59:52PM +0200, Branko Čibej wrote:
> Fixed in r1808258.
Thanks!
> But ... what is a "nearest youngest common ancestor?"
Oh dear... well, it's the YCA of a path component x of path A and
a path component y of path B.
I found no better way to determine a revision to use
s or
> explicit_bzero). If I missed a technique for doing this that exists in
> svn already, please let me know so I can update the diff.
I don't think we have an API for that either, unfortunately. However,
the same portability concerns apply. In any case, it would be great to
have s
On Thu, Sep 14, 2017 at 08:29:25AM -0400, Paul Hammant wrote:
> The needs of the book are different to the needs of the Svn project. And
> the needs of the project are far more important than one of a few Svn books.
I don't understand this reasoning.
The book doesn't receive the attention it deser
On Thu, Sep 14, 2017 at 08:24:35AM -0400, Nathan Hartman wrote:
> It's on my
> long to-do list to send in some patches and I'm hoping others will
> jump in too, particularly to write a chapter on some advanced real
> world usage scenarios, like workflow strategies to scale up a
> development team s
On Wed, Sep 13, 2017 at 06:53:14AM -0400, Paul Hammant wrote:
> Oh tools/client-side/svn-viewspec.py doesn't have any tests :-(
>
> The good news is that it can be refactored to have test quite easily. I
> think I'll be able to donate some code.
I would also be happy to see further improvements t
On 11.09.2017 13:52, Bert Huijben wrote:
Hi Stefan,
I'm still seeing failures when loading repositories on 1.9.x since the SHA1
collision handling changes and currently no nominations in STATUS that will
change the behavior back to something that will work.
One of the repositor
On 9/5/2017 12:20 PM, Stefan Hett wrote:
Hi,
building the 32-bit version on trunk works fine with latest trunk now.
However running nant x64 setup ends up with the following error:
[exec]
D:\TSVN_Build\TortoiseSVN_1_10\src\TortoiseSVNSetup\StructureFragment.wxs(170)
: error LGHT0103 : The
or 64-bit here (note
that there's a TortoiseStub.dll in
D:\TSVN_Build\TortoiseSVN_1_10\bin\release64\bin but no 32-suffixed one.
--
Regards,
Stefan Hett
On 04.09.2017 12:14, Stefan Hett wrote:
On 9/3/2017 5:03 PM, Stefan Fuhrmann wrote:
On 02.09.2017 13:54, Branko Čibej wrote:
The OSX build slave is failing on a couple of the conflict resolver
tests over ra_svn. Can someone please take the time to figure it out?
Otherwise my maintaining the
On 9/3/2017 5:03 PM, Stefan Fuhrmann wrote:
On 02.09.2017 13:54, Branko Čibej wrote:
The OSX build slave is failing on a couple of the conflict resolver
tests over ra_svn. Can someone please take the time to figure it out?
Otherwise my maintaining the build slave makes no sense ...
r1807154
On 02.09.2017 18:26, Branko Čibej wrote:
On 02.09.2017 18:06, Stefan Fuhrmann wrote:
On 02.09.2017 17:17, Branko Čibej wrote:
On 02.09.2017 17:12, stef...@apache.org wrote:
+svn_boolean_t
+svn_utf__fuzzy_glob_match(const char *str,
+ const apr_array_header_t
On 02.09.2017 13:54, Branko Čibej wrote:
The OSX build slave is failing on a couple of the conflict resolver
tests over ra_svn. Can someone please take the time to figure it out?
Otherwise my maintaining the build slave makes no sense ...
r1807154 should fix these.
-- Stefan^2.
On 03/09/2017 11:20, Johan Corveleyn wrote:
> On Fri, Sep 1, 2017 at 2:23 AM, Daniel Shahaf wrote:
>> Stefan Sperling wrote on Thu, 31 Aug 2017 12:05 +0200:
>>> On Wed, Aug 30, 2017 at 11:36:17PM +, Daniel Shahaf wrote:
>>>> Johan Corveleyn wrote on Wed, 30 Aug
On 01.09.2017 17:24, Julian Foad wrote:
Stefan Sperling wrote:
On Fri, Sep 01, 2017 at 03:01:33PM +0100, Julian Foad wrote:
The above behaviour looks good to me.
However, as you already pointed out, matching child path components
seems to be impossible at present:
$ svn ls -r3 --pattern
On 01.09.2017 15:31, Branko Čibej wrote:
On 01.09.2017 06:36, Stefan Fuhrmann wrote:
On 29.08.2017 14:04, Branko Čibej wrote:
On 29.08.2017 13:28, Stefan Sperling wrote:
On Tue, Aug 29, 2017 at 01:12:07PM +0200, Stefan Fuhrmann wrote:
How would you implement the case-insensitive
ing them in the output.
2. Handle these cases in the callers, duplicating that part.
3. Keep it as it is.
-- Stefan^2.
toring whole files instead of
patches. Rebasing and reordering would become much simpler (although not
exactly "simple" if we take tree restructuring into account).
Another reason to store whole files: patches don't work with non-text
files. Which is a major problem especially on Windows where files often
are encoded in utf16.
Stefan
On Fri, Sep 01, 2017 at 04:24:28PM +0100, Julian Foad wrote:
> And, for consistency, when matching paths with "svn log -vq --search..."
> I would expect the same (I would not expect 'dog*' to match
> lazy_dog.txt). At present the implementation does match it, because it
> treats the pattern as a su
On Fri, Sep 01, 2017 at 03:01:33PM +0100, Julian Foad wrote:
> (I'm unsure exactly what you meant there, stsp -- that seems to
> contradict the previous paragraph, if 'svn log --search remains
> case-insensitive.)
The most important point for me is that I don't think appending and
prepending * glo
;t follow the advice. But I certainly also see
that it might be interpreted in another way. So no harm in being precise
here and adding an erratum, I guess...
--
Regards,
Stefan Hett
On 01.09.2017 13:30, Stefan Sperling wrote:
On Fri, Sep 01, 2017 at 06:36:46AM +0200, Stefan Fuhrmann wrote:
Because I think that strict glob-like patterns need to be supported
as well, I suggest to have two options:
--search does a fuzzy search just like we use it in other commands
On Fri, Sep 01, 2017 at 06:36:46AM +0200, Stefan Fuhrmann wrote:
> Because I think that strict glob-like patterns need to be supported
> as well, I suggest to have two options:
>
>--search does a fuzzy search just like we use it in other commands.
> We implicitly
On 29.08.2017 14:04, Branko Čibej wrote:
On 29.08.2017 13:28, Stefan Sperling wrote:
On Tue, Aug 29, 2017 at 01:12:07PM +0200, Stefan Fuhrmann wrote:
How would you implement the case-insensitive comparison
on the server side consistent with the client-side locals?
As far as I can tell the
On Thu, Aug 24, 2017 at 01:44:48PM +0200, Stefan Sperling wrote:
> I see the following options going forward:
> 2) Try to make the resolver handle the case where copyfrom does not point
> back into the same branch. (How?)
I have implemented option 2) in r1806831.
It seems to
On Wed, Aug 30, 2017 at 11:36:17PM +, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Wed, 30 Aug 2017 23:44 +0200:
> > After chatting on #asfinfra, they first have to investigate the
> > possibilities in JIRA. If it's at all possible, we'll have to come up
> > with a good text (perhaps dependi
On Tue, Aug 29, 2017 at 01:12:07PM +0200, Stefan Fuhrmann wrote:
> How would you implement the case-insensitive comparison
> on the server side consistent with the client-side locals?
As far as I can tell the utf8proc code which the client uses
for this is local-independent.
'find -name -maxdepth -prune ...'. I expect almost zero use cases
would require case-sensitive matching at this UI level, and that is why
we made 'svn log --search' just be case-insensitive always.
How would you implement the case-insensitive comparison
on the server side consistent with the client-side locals?
-- Stefan^2.
On 29.08.2017 12:22, Johan Corveleyn wrote:
On Tue, Aug 29, 2017 at 12:08 PM, Stefan Fuhrmann wrote:
On 18.08.2017 13:36, Johan Corveleyn wrote:
On Sun, Jan 29, 2017 at 10:35 AM, Stefan Fuhrmann
wrote:
On 24.01.2017 12:20, Stefan Sperling wrote:
...
I would like to get an 1.10.0
On 18.08.2017 13:36, Johan Corveleyn wrote:
On Sun, Jan 29, 2017 at 10:35 AM, Stefan Fuhrmann wrote:
On 24.01.2017 12:20, Stefan Sperling wrote:
...
I would like to get an 1.10.0 alpha1 released in February. Unless I hear
objections I will start rolling this alpha release from trunk and call
On Fri, Aug 25, 2017 at 10:08:04AM +0100, Julian Foad wrote:
> Example workflow:
>
> 1. There exists a shelved patch 'foo' with a verbose log message
> 2. 'svn unshelve foo'
There can only be one changelist per file.
What if at this point there is another changelist 'bar' which includes a
file mo
can be used to debug/test issues yourself
(by shipping symbol files)
Regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
During a recent discussion in #svn-dev IRC, Johan and I identified a
problem connected to merges of non-conflicting moves.
(http://colabti.org/irclogger/irclogger_log/svn-dev?date=2017-08-22#l81)
The new resolver in 1.10 makes sure that copyfrom info of a moved file
or directory points back into t
On Wed, Aug 23, 2017 at 04:09:55PM +, Daniel Shahaf wrote:
> s...@apache.org wrote on Mon, 21 Aug 2017 12:49 +:
> > Author: stsp
> > Date: Mon Aug 21 12:49:42 2017
> > New Revision: 1805627
> >
> > URL: http://svn.apache.org/viewvc?rev=1805627&view=rev
> > Log:
> > Follow-up to r1805620: F
On Wed, Aug 23, 2017 at 02:16:15PM -, kot...@apache.org wrote:
> Author: kotkov
> Date: Wed Aug 23 14:16:15 2017
> New Revision: 1805897
>
> URL: http://svn.apache.org/viewvc?rev=1805897&view=rev
> Log:
> fsfs: Make LZ4 the new default compression algorithm for all (new and
> upgraded) format
strate the problem) to me it sounds like basically the same
underlying problem. Do you agree?
--
Regards,
Stefan Hett
On Fri, Aug 18, 2017 at 10:58:13PM +0300, Evgeny Kotkov wrote:
> With all that in mind, I propose that we do (2). Any objections?
I want (2) as well. Thanks for doing this work, and for very clearly
and transparently describing the tradeoffs and our options.
On Fri, Aug 18, 2017 at 05:33:14PM +, Daniel Shahaf wrote:
> s...@apache.org wrote on Fri, 18 Aug 2017 10:33 +:
> > +++ subversion/site/publish/security/CVE-2017-9800-advisory.txt Fri Aug 18
> > 10:33:10 2017
> > @@ -80,24 +96,36 @@ Recommendations:
> >the included patch.
> >
> >
that
kind of issue by running release.py check-sigs in the future, so we
should not run into such problem again.
Shortly discussed on IRC with brane whether we'd be ok with making the
correcting commit on dist.apache.org (with the conclusion to just fix it).
Regards,
Stefan
[1] http://mirro
/release.py?rev=1805277&r1=1805276&r2=1805277&view=diff
> ==
> [...]
>
>
Thanks for improving the checks.
I've tested the current release.py on trunk (@1805277). It works like a
charm. :-)
Regards,
Stefan
> +
> # finally, run the subcommand, and give it the parsed arguments
> args.func(args)
>
>
Thanks for changing this. I had put that one on my todo-list while
signing the 1.9.7/1.8.18 releases to simplify the verification process.
Regards,
Stefan
On Tue, Aug 15, 2017 at 04:33:31PM +, Daniel Shahaf wrote:
> Ping? We seem to have consensus on lowering the bar, but not yet consensus
> on what to. It'd be nice to have finished this by the next release.
>
> (editor hat on)
I agree with Mark.
Let's require a lower count of +1 votes (3 in
dition to "Resolution" or instead of it). If a change needs to be
> made, please tell me. (Or commit it directly :-))
>
> Thanks,
>
> Daniel
FWIW: Reviewed the JIRA link and looks correct to me.
Regards,
Stefan
On Wed, Aug 02, 2017 at 06:49:55PM -, kot...@apache.org wrote:
> +svn_boolean_t
> +svn_ra_serf__is_local_network(svn_ra_serf__session_t *session)
> +{
> + return session->conn_latency >= 0 &&
> + session->conn_latency < apr_time_from_msec(5);
> +}
"local network" is a rather blurry co
On 6/28/2017 10:06, Stefan Hett wrote:
> Hi,
>
> I'd just like to drop a quick note letting all know that despite my
> absence over the past weeks/months I'm all fine and still alive.
>
> I've had several very busy weeks the past months (and this is likely
>
On Wed, Jul 26, 2017 at 02:14:36PM -, danie...@apache.org wrote:
> Author: danielsh
> Date: Wed Jul 26 14:14:36 2017
> New Revision: 1803053
>
> URL: http://svn.apache.org/viewvc?rev=1803053&view=rev
> Log:
> * subversion/svn/svn.c
> (svn_cl__cmd_table."cleanup"): Edit the help text so it is
On Wed, Jul 26, 2017 at 03:48:33PM +0300, Evgeny Kotkov wrote:
> Stefan Sperling writes:
>
> >> The way the lz4 code is currently embedded in libsvn_subr makes it
> >> awkward to add support for an external liblz4.
> >
> > I agree that an external library sho
On Wed, Jul 26, 2017 at 12:36:05PM +0100, Philip Martin wrote:
> Philip Martin writes:
>
> > $ pkg-config lz4 --libs
> > -llz4
>
> Typo, that should be
>
> pkg-config liblz4 --libs
>
> The way the lz4 code is currently embedded in libsvn_subr makes it
> awkward to add support for an
On Wed, Jul 26, 2017 at 02:41:31PM +0300, Evgeny Kotkov wrote:
> Stefan Sperling writes:
>
> > Sounds like we're headed in a good direction :-)
>
> One particular thing that bothers me about using LZ4 as the new default
> is that I think that a decision like that go
On Wed, Jul 26, 2017 at 01:18:00PM +0300, Evgeny Kotkov wrote:
> Stefan Sperling writes:
>
> > Does mod_dav_svn really need an option for this?
> >
> > Can't lz4 (svndiff2) be negotiated as a mutual protocol capability of
> > client and server? Why won't a
On Mon, Jul 17, 2017 at 02:54:59PM +0200, Evgeny Kotkov wrote:
> https://svn.apache.org/r1801974 adds negotiation and support for LZ4 in
> mod_dav_svn and in ra_serf. Except for the PUT requests, which require a
> couple of tweaks to the negotiation scheme, with this change svndiff2 with
> LZ4 wil
On Mon, Jul 24, 2017 at 07:19:09PM +0300, Evgeny Kotkov wrote:
> However, there are a couple of difficulties with porting this approach to
> mod_dav_svn, i.e., if we introduce the SVNCompression directive. There
> are clients that don't use LZ4, so, presumably, this options would require
> specify
On Tue, Jul 25, 2017 at 11:09:21AM +, Daniel Shahaf wrote:
> Stefan Sperling wrote on Mon, 24 Jul 2017 18:34 +0200:
> > Daniel, I'm thinking that reverting r1802797, which changed the default
> > behaviour of 'svn cleanup', may be good enough to address your
On Mon, Jul 24, 2017 at 06:22:10PM +0200, Stefan Sperling wrote:
> On Mon, Jul 24, 2017 at 03:40:32PM +, Daniel Shahaf wrote:
> > It seems the real fix would be figuring out a way for 'cleanup' not to
> > break all locks it sees.
>
> Actually, I missed that cle
On Mon, Jul 24, 2017 at 03:40:32PM +, Daniel Shahaf wrote:
> It seems the real fix would be figuring out a way for 'cleanup' not to
> break all locks it sees.
Actually, I missed that cleanup_internal() grabs a WC lock, so the
entire point of my argument is moot. The other client manipulating
W
I have slightly changed the default mode of 'svn cleanup' in r1802797.
It will no longer remove unreferenced pristines from the pristine store.
Instead, the new --vacuum-pristines option must be used, added in r1802787.
This runs the same operation under a working copy write lock.
Note that the d
On Wed, Jul 19, 2017 at 03:00:47PM +, Daniel Shahaf wrote:
> The 1.10.0-alpha3 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
On 19.07.2017 17:00, Daniel Shahaf wrote:
The 1.10.0-alpha3 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.2
On Tue, Jul 18, 2017 at 09:47:36PM +, Daniel Shahaf wrote:
> Hi,
>
> I'm working on CHANGES for alpha3. Could I please get a hand on the
> following six changes. For each of them: does it need to be listed in
> CHANGES? How'd you summarize the user-visible (or API-consumer-visible)
> change
On Tue, Jul 18, 2017 at 12:27:42PM +0100, Julian Foad wrote:
> I just ran into the following bug. It appears that the conflict resolver
> doesn't properly follow branch (copy) history when searching for details.
>
> [[[
> $ svn sw ^/subversion/branches/shelve-checkpoint3
> [...]
>
> $ svn merge ^
On Mon, Jul 17, 2017 at 02:54:59PM +0200, Evgeny Kotkov wrote:
> LZ4 offers much faster decompression than zlib, and read operations should
> benefit from this change as well. (Don't have the exact numbers available
> here on my phone, sorry for that.)
>
> https://svn.apache.org/r1801974 adds neg
On Tue, Jul 11, 2017 at 09:11:58PM +0200, Branko Čibej wrote:
> Another issue I have with the proposal is the idea to use file suffixes.
> That's usually the wrong way to go about things (case in point: Windows
> does it, with didastrous results). It's much better to determine file
> format by insp
On Tue, Jul 11, 2017 at 10:35:12PM +0200, Stefan Sperling wrote:
> On Tue, Jul 11, 2017 at 07:54:58PM +, Daniel Shahaf wrote:
> > As others have said, configure already supports both 2.x and 3.x. The
> > remaining question is just whether release.py should use 2.x or 3.x
On Tue, Jul 11, 2017 at 07:54:58PM +, Daniel Shahaf wrote:
> As others have said, configure already supports both 2.x and 3.x. The
> remaining question is just whether release.py should use 2.x or 3.x for
> rolling tarballs. release.py uses own swig version compiled directly
> from swig upstr
On Tue, Jul 11, 2017 at 04:33:37PM +0100, Julian Foad wrote:
> An improvement would be to show the pending status, perhaps like this:
>
> ...
> > A file scheduled to be added to the repository in the next commit was found
> > in the working copy.
> > Pending status of the file is:
> > RM sub
On Mon, Jul 10, 2017 at 11:38:10PM +, Daniel Shahaf wrote:
> Shall we bump the release.py swig version to 3.x for 1.10.x? Currently it
> points to 2.0.12 which is over 3 years old and AFAICT deprecated upstream
> (there were no further releases of the 2.x line of swig).
>
> Cheers,
>
> Danie
e the svn: protocol, tune the repo as previously discussed,
pick a fast server CPU and you should be able to reach up
to 200MB/s over a single network connection in 1.9 with
'svn import'. 'svn commit' takes about twice as long but
that could be fixed eventually as well.
-- Stefan^2.
in
JNIUtil::wrappedCreateClientException to remove most of them:
// Create a local frame for our references
- env->PushLocalFrame(LOCAL_FRAME_SIZE);
+ env->PushLocalFrame(LOCAL_FRAME_SIZE + 100);
Maybe, it is the SVN_ERR__TRACING section in that method
that causes the overflow?
-- Stefan^2.
4096R/B59CE6D6010C8AAD] with fingerprint:
8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD
Bert Huijben [4096R/C4A6C625CCC8E1DF] with fingerprint:
3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF
Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint:
8BC4 DAE0 C5A4 D65F
On 7/6/2017 08:04, Stefan wrote:
> On 7/6/2017 04:13, Daniel Shahaf wrote:
>> Stefan wrote on Thu, 06 Jul 2017 00:14 +0200:
>>> Summary
>>> ---
>>> +0.5 to release (+1 once subversion-1.8.18.tar.gz.sha512 has been
>>> corrected - see below)
On 7/6/2017 04:13, Daniel Shahaf wrote:
> Stefan wrote on Thu, 06 Jul 2017 00:14 +0200:
>> Summary
>> ---
>> +0.5 to release (+1 once subversion-1.8.18.tar.gz.sha512 has been
>> corrected - see below)
>>
>> Verified
>>
>>
On 7/3/2017 12:55, Stefan Sperling wrote:
> The 1.8.18 release can now be tested and signed.
> Get it from https://dist.apache.org/repos/dist/dev/subversion
> as usual, and add your signatures there. Thanks!
Summary
---
+0.5 to release (+1 once subversion-1.8.18.tar.gz.sha512
On Wed, Jul 05, 2017 at 10:39:39AM +, Daniel Shahaf wrote:
> We have the required signatures, I've submitted the artifacts
> to the mirrors. Thanks all for testing.
\o/
On 03.07.2017 12:55, Stefan Sperling wrote:
The 1.8.18 release can now be tested and signed.
Get it from https://dist.apache.org/repos/dist/dev/subversion
as usual, and add your signatures there. Thanks!
Summary:
+1 to release
(despite binding issues similar to 1.9.6 - see below
On 6/30/2017 15:05, Daniel Shahaf wrote:
> The 1.9.6 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.
>
> I'm aiming to release this within a week. (CHANGES points to thi
The 1.8.18 release can now be tested and signed.
Get it from https://dist.apache.org/repos/dist/dev/subversion
as usual, and add your signatures there. Thanks!
On 30.06.2017 15:05, Daniel Shahaf wrote:
The 1.9.6 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.
I'm aiming to release this within a week. (CHANGES points to this
Wedn
On Fri, Jun 30, 2017 at 01:05:48PM +, Daniel Shahaf wrote:
> The 1.9.6 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.
>
> I'm aiming to release this within a week.
On 30.06.2017 16:38, Daniel Shahaf wrote:
Stefan Sperling wrote on Fri, 30 Jun 2017 16:10 +0200:
We need an additional vote now in order to roll a 1.8 tarball today.
Can anyone help?
* r1785737, r1785738, r1785734, r1786447, r1785754, r1786445, r1786446,
r1786515, r1794611, r1800387
We need an additional vote now in order to roll a 1.8 tarball today.
Can anyone help?
* r1785737, r1785738, r1785734, r1786447, r1785754, r1786445, r1786446,
r1786515, r1794611, r1800387
Make FSFS consistency no longer depend on hash algorithms.
Justification:
This eliminates any exi
On Fri, Jun 30, 2017 at 02:54:51PM +0100, Julian Foad wrote:
> Looks like the "remove" part was accidentally lost in r1685793 (June 2015,
> after 1.9 was branched).
>
> Anyone want to investigate further and fix?
>
> - Julian
Thanks for spotting this!
Could we just revert r1685793 for now? I th
est/sign the release for
Windows once stsp rolled that out, despite the lack of time atm.
--
Regards,
Stefan Hett
It seems we have some pending releases to roll, and I will have
some time to do that, so I'll just do it :-)
Probably by the end of this week.
Please review STATUS again ASAP and bump any pending nominations
that have either no votes or incomplete votes from you.
The sooner, the better.
On Friday
On 29.05.2017 05:45, Orivej Desh wrote:
* Stefan Fuhrmann [2017-05-28]
The callstacks suggests that this is a pool cleanup race.
Please try the attached patch and report the results.
Thanks! With this patch subversion from trunk no longer crashes, and
subversion 1.9.5 does not crash with an
attached patch and report the results.
Thanks you!
-- Stefan^2.
==329484==ERROR: AddressSanitizer: heap-use-after-free on address
0x625234d0 at pc 0x0077f3f9 bp 0x7ffc53dac920 sp 0x7ffc53dac918
READ of size 8 at 0x625234d0 thread T0
#0 0x77f3f8 in object_ref_cleanup
/home
501 - 600 of 5045 matches
Mail list logo
