C. Michael Pilato wrote on Tue, May 14, 2013 at 23:19:36 -0400:
>Exceptions:
>
> ctypes-python: test_as_human_string (svntypes.SvnDateTestCase)
> test failed due to poorly written test (since fixed on trunk).
... and merged to 1.8.x for inclusion in rc3 (or 1.8.1).
On 05/14/2013 03:18 PM, Ben Reser wrote:
> Here it is: the second Release Candidate for Subversion 1.8.0. You can
> fetch the proposed tarballs from here:
> https://dist.apache.org/repos/dist/dev/subversion
Summary:
+1 to release.
Platform:
Linux 3.2.0-39-generic-pae
Ubuntu 12.04.2
Mark Phippard wrote on Tue, May 14, 2013 at 17:03:48 -0400:
> I am still getting those test failures in the svnrdump and svnsync
> tests. Given that the tests work for others, I would guess this is
> something odd about my machine setup. I manually did an svnsync to
> confirm the binary worked.
>
On Tue, May 14, 2013 at 3:18 PM, Ben Reser wrote:
> Here it is: the second Release Candidate for Subversion 1.8.0. You can
> fetch the proposed tarballs from here:
> https://dist.apache.org/repos/dist/dev/subversion
>
> The magic rev is r1482456
>
> This is a release candidate, meaning if all g
I am still getting those test failures in the svnrdump and svnsync
tests. Given that the tests work for others, I would guess this is
something odd about my machine setup. I manually did an svnsync to
confirm the binary worked.
In the svn:// and http:// tests I have a couple of additional failur
On 05/14/2013 04:13 PM, bre...@apache.org wrote:
> Author: breser
> Date: Tue May 14 20:13:13 2013
> New Revision: 1482554
>
> URL: http://svn.apache.org/r1482554
> Log:
> Make ctypes-python tests pass regardless of timezone.
Awesome! I had pushed this buglet onto my TODO list at the end of last
Here it is: the second Release Candidate for Subversion 1.8.0. You can
fetch the proposed tarballs from here:
https://dist.apache.org/repos/dist/dev/subversion
The magic rev is r1482456
This is a release candidate, meaning if all goes well it (or something
very much like it) will become the fi
Bert Huijben wrote:
> Julian Foad wrote:
>> (1) Inserting a UCS-2 string into a UTF-8 error message will surely fail
>> in one way or another.
>>
>> (2) Just below this error handling, the code to write the null terminator
>> is bogus.
>>
>> I suggest:
[...]
>> - err = svn_error_cr
On Thu, Mar 17, 2011 at 4:21 PM, wrote:
> Author: rhuijben
> Date: Thu Mar 17 12:21:29 2011
> New Revision: 1082451
>
> URL: http://svn.apache.org/viewvc?rev=1082451&view=rev
> Log:
> On Windows avoid a file flush that is taking over 15% of the checkout time.
>
> * subversion/libsvn_subr/io.c
>
Note that this is not really an abuse of the delta editor. This is the
documented behavior of both this replay editor and the ra call behind 'svn
status -u': sending limited changes instead of full changes
Sending full results to both of them would be a major performance issue.
(I haven't veri
> -Original Message-
> From: Julian Foad [mailto:julianf...@btopenworld.com]
> Sent: dinsdag 14 mei 2013 18:05
> To: BertHuijben
> Cc: dev@subversion.apache.org
> Subject: Re: svn commit: r1482282 - svn_nls_init on Windows
>
> Bert Huijben wrote:
> > URL: http://svn.apache.org/r1482282
>
This change breaks the api contract of svn_ra_replay_range()
* If @a send_deltas is @c TRUE, the actual text and property changes in
* the revision will be sent, otherwise dummy text deltas and NULL property
* changes will be sent instead.
Bert
On Fri, Feb 24, 2012 at 7:29 PM, wrote:
> Aut
Bert Huijben wrote:
> URL: http://svn.apache.org/r1482282
> Log:
> * subversion/libsvn_subr/nls.c
> (svn_nls_init): Don't use an uninitialized variable to produce a very
> unlikely if not impossible to reach error.
>
> Modified: subversion/trunk/subversion/libsvn_subr/nls.c
> ===
Stefan Sperling wrote:
> On Mon, May 13, 2013 at 10:10:58PM +0100, Julian Foad wrote:
>>> Author: stsp
>>
>>> URL: http://svn.apache.org/r1480669
>>> Log:
>>> If a merged property value exists, make the 'dc' conflict prompt
>>> option use the merged value as 'mine' for display. Else, users might
On Tue, May 14, 2013 at 7:23 AM, C. Michael Pilato wrote:
> With 1.8.0-rc1 DOA, should we roll more of the 1.8.x/STATUS items into what
> will be rc2? There look to be quite a few that have "(1.8.1)" decorators on
> them, I assume because they aren't considered valuable enough to restart the
> so
With 1.8.0-rc1 DOA, should we roll more of the 1.8.x/STATUS items into what
will be rc2? There look to be quite a few that have "(1.8.1)" decorators on
them, I assume because they aren't considered valuable enough to restart the
soak process. But the soak is already restarted, so...
Ben, can you
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: dinsdag 14 mei 2013 15:20
> To: 'Mark Phippard'; 'Ben Reser'
> Cc: 'Subversion Development'
> Subject: RE: 1.8.0-rc1 up for testing/signing
>
>
>
> > -Original Message-
> > From: Mark Phippard [mailto:mar
On 14.05.2013 15:19, Bert Huijben wrote:
>
>> -Original Message-
>> From: Mark Phippard [mailto:markp...@gmail.com]
>> Sent: vrijdag 10 mei 2013 17:43
>> To: Ben Reser
>> Cc: Subversion Development
>> Subject: Re: 1.8.0-rc1 up for testing/signing
>>
>> On Wed, May 8, 2013 at 12:40 PM, Mark
On 05/13/2013 09:58 PM, Bob Cardillo wrote:
> I'm running Subversion 1.8.0-dev on Windows 7 Pro SP1.
>
> The following steps went through without error on 1.7.x, but they fail with
> an error on the last step when run on 1.8.0 (see below for full reproducible
> recipe):
> 1. make a copy (branch)
> -Original Message-
> From: Mark Phippard [mailto:markp...@gmail.com]
> Sent: vrijdag 10 mei 2013 17:43
> To: Ben Reser
> Cc: Subversion Development
> Subject: Re: 1.8.0-rc1 up for testing/signing
>
> On Wed, May 8, 2013 at 12:40 PM, Mark Phippard
> wrote:
> > I am using a new build pr
Branko Čibej writes:
>> These warnings are "maybe" which means there will be false positives and
>> different compilers will have different results. I see a number of
>> false positives with gcc 4.7.2 and I don't think we should be adding
>> spurious initialisation to make them go away.
>>
>> Wh
On 14.05.2013 13:02, Philip Martin wrote:
> Branko Čibej writes:
>
>> This discussion is out of date, I committed a different fix yesterday
>> that doesn't require premature initialization, yet avoids the
>> uninitialized-read problem.
> There was no uninitialized read to avoid. My compiler now p
Branko Čibej writes:
> This discussion is out of date, I committed a different fix yesterday
> that doesn't require premature initialization, yet avoids the
> uninitialized-read problem.
There was no uninitialized read to avoid. My compiler now produces:
../src/subversion/libsvn_fs_fs/tree.c:
On 14.05.2013 06:30, Branko Čibej wrote:
> On 14.05.2013 05:04, Daniel Shahaf wrote:
>> Joe Swatosh wrote on Mon, May 13, 2013 at 18:53:35 -0700:
>>> Is SIZE_MAX c89? Should it be APR_SIZE_MAX in utf8proc.h (along with
>>> including svn_dep_compat.h)?
>> subversion/libsvn_subr/utf8proc/utf8proc.h i
On Mon, May 13, 2013 at 10:10:58PM +0100, Julian Foad wrote:
> > Author: stsp
>
> > URL: http://svn.apache.org/r1480669
> > Log:
> > If a merged property value exists, make the 'dc' conflict prompt option
> > use the merged value as 'mine' for display. Else, users might get confused
> > if they ed
On 14.05.2013 08:31, Blair Zajac wrote:
> Hi Brane,
>
> Just saw the veto on my compiler warning commits for 1.8.x.
>
> I nominated your two commits on top of my commits (to avoid merge
> conflicts), which should resolve the veto, but I left it in the vetoed
> section to be safe. Pinging you here s
On 14.05.2013 08:05, Blair Zajac wrote:
> On 4/18/13 11:53 AM, Philip Martin wrote:
>> bl...@apache.org writes:
>>
>>> Author: blair
>>> Date: Thu Apr 18 18:41:55 2013
>>> New Revision: 1469520
>>>
>>> URL: http://svn.apache.org/r1469520
>>> Log:
>>> open_path(): silence compiler warning.
>>>
>>> s
27 matches
Mail list logo
