Summary:
+1 to release (Unix)
Platform
Mac OS X 10.11.4 El Capitan
Standard dependencies:
Apple LLVM version 7.3.0 (clang-703.0.29)
APR 1.4.8
APR-Util 1.5.2
zlib 1.2.5
httpd 2.4.18
Python 2.7.10
Perl 5.18.2
Ruby 2.0.0p648 (2015-12-16 r
Summary:
+1 to release (Unix)
Platform
Mac OS X 10.11.4 El Capitan
Standard dependencies:
Apple LLVM version 7.3.0 (clang-703.0.29)
APR 1.4.8
APR-Util 1.5.2
zlib 1.2.5
httpd 2.4.18
Python 2.7.10
Perl 5.18.2
Ruby 2.0.0p648 (2015-12-16 r
On Thu, Apr 21, 2016 at 10:57:34AM +0100, Philip Martin wrote:
> Stefan Sperling writes:
>
> > Funny. It works with 1.9.x indeed.
> >
> > Now try the same with a trunk client.
> > Is this a regression? Or a new feature?
>
> This is caused by the deliberate change, r1739263, to the way our merge
On 21.04.2016 16:34, Stefan Sperling wrote:
> On Thu, Apr 21, 2016 at 02:04:08PM -, s...@apache.org wrote:
>> Author: stsp
>> Date: Thu Apr 21 14:04:08 2016
>> New Revision: 1740320
>>
>> URL: http://svn.apache.org/viewvc?rev=1740320&view=rev
>> Log:
>> Add a conflict resolution option for dir/
On 21 April 2016 at 19:44, Stefan Sperling wrote:
> On Thu, Apr 21, 2016 at 07:37:50PM +0300, Ivan Zhakov wrote:
>> On 21 April 2016 at 17:34, Stefan Sperling wrote:
>> > Implementation aside, I do think the option to merge the two directories
>> > makes sense, even if they are ancestrally unrela
The 1.9.4 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 plan to try and release on April 28th
so please try and get your votes/signatures in place by April 27th.
Thanks!
On Thu, Apr 21, 2016 at 07:37:50PM +0300, Ivan Zhakov wrote:
> On 21 April 2016 at 17:34, Stefan Sperling wrote:
> > Implementation aside, I do think the option to merge the two directories
> > makes sense, even if they are ancestrally unrelated.
> May there are some implementation problems, but I
The 1.8.16 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 plan to try and release on April 28th
so please try and get your votes/signatures in place by April 27th.
Thanks!
On 21 April 2016 at 17:34, Stefan Sperling wrote:
> On Thu, Apr 21, 2016 at 02:04:08PM -, s...@apache.org wrote:
>> Author: stsp
>> Date: Thu Apr 21 14:04:08 2016
>> New Revision: 1740320
>>
>> URL: http://svn.apache.org/viewvc?rev=1740320&view=rev
>> Log:
>> Add a conflict resolution option f
On Thu, Apr 21, 2016 at 02:04:08PM -, s...@apache.org wrote:
> Author: stsp
> Date: Thu Apr 21 14:04:08 2016
> New Revision: 1740320
>
> URL: http://svn.apache.org/viewvc?rev=1740320&view=rev
> Log:
> Add a conflict resolution option for dir/dir "incoming add vs local
> obstruction upon merge"
+1 on backport. Feel free to call it a documentation/trivial change that
doesn't need full votes.
Bert
> -Original Message-
> From: kot...@apache.org [mailto:kot...@apache.org]
> Sent: donderdag 21 april 2016 15:51
> To: comm...@subversion.apache.org
> Subject: svn commit: r17403
Branko Čibej wrote on Sun, Apr 17, 2016 at 18:47:35 +0200:
> P.S.: It would also be nice if developers compiled stuff in maintainer
> mode and fixed new warnings before committing ... just sayin'.
That's exactly why we have the svn-warnings bot. Its build did trigger
the 'switch' warning you had
Stefan Sperling writes:
> Funny. It works with 1.9.x indeed.
>
> Now try the same with a trunk client.
> Is this a regression? Or a new feature?
This is caused by the deliberate change, r1739263, to the way our merge
algorithm handles adjacent changes.
2003 discussion about merging without a co
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: donderdag 21 april 2016 09:43
> To: dev@subversion.apache.org
> Cc: comm...@subversion.apache.org
> Subject: Re: svn commit: r1740170 -
> /subversion/trunk/subversion/libsvn_client/conflicts.c
>
> On Thu, Apr 21,
On Thu, Apr 21, 2016 at 09:40:07AM +0200, Branko Čibej wrote:
> It is wrong to use conflict->local_abspath to construct the relative
> URL.
Yes, it is.
But where is the alleged code that does this? I don't see it.
And I don't think I've written it.
On Wed, Apr 20, 2016 at 10:19:56PM +0200, Bert Huijben wrote:
> The path calculation here 100% assumes that the working copy is always a
> clean check out from ^/. This might be the case in our test suite, but in
> almost every normal user scenario this isn’t the case.
>
> You can’t just calcula
16 matches
Mail list logo
