On Wed, Jun 19, 2013 at 9:23 PM, Mark Phippard markp...@gmail.com wrote:
On Jun 19, 2013, at 9:09 PM, jcor...@apache.org wrote:
...
+div class=notice
+pFor 1.8 servers, set strongSVNAllowBulkUpdates/strong to
+strongPrefer/strong if your server configuration does not allow an
+intermediate
[[[
% cat ./repro
#!/bin/sh
set -eu
svn16=/usr/bin/svn
svnadmin16=/usr/bin/svnadmin
svn17=/usr/local/svn-1.7.10/bin/svn
svn18=/usr/local/svn-1.8.0/bin/svn
rm -rf r
U=file://`pwd`/r
$svnadmin16 create r
$svn17 log $U /dev/null
printf '1.7: %s\n' `ls r/db/ | grep node`
$svn18 log $U /dev/null
On Thu, Jun 20, 2013 at 5:41 AM, Johan Corveleyn jcor...@gmail.com wrote:
On Thu, Jun 20, 2013 at 3:27 AM, Johan Corveleyn jcor...@gmail.com wrote:
On Thu, Jun 20, 2013 at 3:23 AM, Mark Phippard markp...@gmail.com wrote:
On Jun 19, 2013, at 9:09 PM, jcor...@apache.org wrote:
Author: jcorvel
On Thu, Jun 20, 2013 at 9:57 AM, Daniel Shahaf danie...@elego.de wrote:
[[[
% cat ./repro
#!/bin/sh
set -eu
svn16=/usr/bin/svn
svnadmin16=/usr/bin/svnadmin
svn17=/usr/local/svn-1.7.10/bin/svn
svn18=/usr/local/svn-1.8.0/bin/svn
rm -rf r
U=file://`pwd`/r
$svnadmin16 create r
$svn17
Hi all,
I'd like to work on adding support for auto-resolving tree conflicts
with incoming moves during updates and merges, and also local moves
during merges. This builds on the efforts we made to resolve tree
conflicts involving local moves during updates in Subversion 1.8.
I've discussed some
On Thu, Jun 20, 2013 at 11:50 AM, Ivan Zhakov i...@visualsvn.com wrote:
On Thu, Jun 20, 2013 at 5:41 AM, Johan Corveleyn jcor...@gmail.com wrote:
On Thu, Jun 20, 2013 at 3:27 AM, Johan Corveleyn jcor...@gmail.com wrote:
On Thu, Jun 20, 2013 at 3:23 AM, Mark Phippard markp...@gmail.com wrote:
On 06/20/2013 06:31 AM, stef...@apache.org wrote:
Author: stefan2
Date: Thu Jun 20 10:31:53 2013
New Revision: 1494913
URL: http://svn.apache.org/r1494913
Log:
Fix a severe performance regression in 'svn log': The new log code
will run svn_client__repos_location_segments even if we log
On 06/20/2013 06:55 AM, Johan Corveleyn wrote:
Fine for me. I actually don't care about this personally (at our
workplace we're still lightyears away from upgrading, both client and
server side). I just found it to be an important omission from our
release notes (that actually should have been
Perhaps the better change is to make svn_repos__validate_prop() early-out
(with success, of course) on a NULL value and adjust the rest of the code
therein accordingly. I can see the benefit in flagging the *addition* (or
modification) of a non-regular property (which is the first test that
On Thu, Jun 20, 2013 at 06:15:52PM +0530, Arwin Arni wrote:
Hi,
Properties are validated regardless of the action on the property.
This poses a problem when it comes to very old repositories that
contain invalid properties committed by very old clients that
didn't perform these validations.
On Thu, Jun 20, 2013 at 2:44 PM, Ivan Zhakov i...@visualsvn.com wrote:
On Thu, Jun 20, 2013 at 4:40 PM, C. Michael Pilato cmpil...@collab.net
wrote:
On 06/20/2013 06:55 AM, Johan Corveleyn wrote:
Fine for me. I actually don't care about this personally (at our
workplace we're still
On Thu, Jun 20, 2013 at 9:18 AM, Johan Corveleyn jcor...@gmail.com wrote:
Big +1. HTTP protocol options added mostly for debugging purpose, not
for regular users.
Of course. I agree.
Note that I didn't ask for adding http-max-connections to the release
notes. But the skelta-mode and bulk
When Subversion used neon until 1.8 was released it supported the Windows
Integrated Security Scheme called 'NTLM'. This same scheme was also
supported in the ra_serf authentication framework we used before requiring
Serf 0.7. (Read: Before Subversion 1.7). But now after releasing Subversion
1.8
Arwin Arni wrote:
Properties are validated regardless of the action on the property. This poses
a
problem when it comes to very old repositories that contain invalid
properties committed by very old clients that didn't perform these
validations.
What cases are you talking about,
I (Julian Foad) wrote:
What cases are you talking about, specifically?
[...]
Agreed. We discussed this before, at least in terms of the command-line
client,
and that was the conclusion we agreed on. The principle should apply
consistently, so +1 to fix any APIs or wherever you're seeing
On Thu, Jun 20, 2013 at 5:30 PM, Bert Huijben b...@qqmail.nl wrote:
[...]
The patch to serf 1.2.1 attached to this mail is a (tiny bit cleaned up)
hack based on the old code in ra_serf, some code from an old serf branch and
the new in serf auth_kerb code, which re-enables the NTLM
On Thu, Jun 20, 2013 at 02:59:26PM +0200, Bart van Oerle wrote:
Hello,
I got the following error when doing a Check out with a freshly installed
TortoiseSVN:
In file
'D:\Development\SVN\Releases\TortoiseSVN-1.8.0\ext\subversion\subversion\libsvn_client\ra.c'
line 647: assertion
On Thu, Jun 20, 2013 at 9:40 AM, Ivan Zhakov i...@visualsvn.com wrote:
On Thu, Jun 20, 2013 at 5:30 PM, Bert Huijben b...@qqmail.nl wrote:
[...]
The patch to serf 1.2.1 attached to this mail is a (tiny bit cleaned up)
hack based on the old code in ra_serf, some code from an old serf branch
-Original Message-
From: Ivan Zhakov [mailto:i...@visualsvn.com]
Sent: donderdag 20 juni 2013 15:41
To: serf-...@googlegroups.com; Bert Huijben
Cc: dev@subversion.apache.org; Gert Kello
Subject: Re: [serf-dev] [Patch] Adding NTLM Support to Serf - Work in
progress / Subversion
On Thu, Jun 20, 2013 at 5:44 PM, Mark Phippard markp...@gmail.com wrote:
On Thu, Jun 20, 2013 at 9:40 AM, Ivan Zhakov i...@visualsvn.com wrote:
On Thu, Jun 20, 2013 at 5:30 PM, Bert Huijben b...@qqmail.nl wrote:
[...]
The patch to serf 1.2.1 attached to this mail is a (tiny bit cleaned up)
On Thu, Jun 20, 2013 at 02:59:26PM +0200, Bart van Oerle wrote:
In file
'D:\Development\SVN\Releases\TortoiseSVN-1.8.0\ext\subversion\subversion\libsvn_client\ra.c'
line 647: assertion failed (peg_revnum != SVN_INVALID_REVNUM)
Is there any way we can get the tortoise assertion reports to
On 20.06.2013 15:54, Daniel Shahaf wrote:
On Thu, Jun 20, 2013 at 02:59:26PM +0200, Bart van Oerle wrote:
In file
'D:\Development\SVN\Releases\TortoiseSVN-1.8.0\ext\subversion\subversion\libsvn_client\ra.c'
line 647: assertion failed (peg_revnum != SVN_INVALID_REVNUM)
Is there any way we
On Thu, Jun 20, 2013 at 10:01 AM, Tobias Bading tbad...@web.de wrote:
On 20.06.2013 15:54, Daniel Shahaf wrote:
On Thu, Jun 20, 2013 at 02:59:26PM +0200, Bart van Oerle wrote:
In file
'D:\Development\SVN\Releases\TortoiseSVN-1.8.0\ext\subversion\subversion\libsvn_client\ra.c'
line 647:
Tobias Bading wrote on Thu, Jun 20, 2013 at 16:01:45 +0200:
On 20.06.2013 15:54, Daniel Shahaf wrote:
On Thu, Jun 20, 2013 at 02:59:26PM +0200, Bart van Oerle wrote:
In file
'D:\Development\SVN\Releases\TortoiseSVN-1.8.0\ext\subversion\subversion\libsvn_client\ra.c'
line 647: assertion
Hi,
Just raising interest before users are reporting this issue.
On two separate occasions this morning (from different networks) clean
checkouts from svn.apache.org (the EU mirror) got the simple but fatal
error:
svn: E175009: XML parsing failed: (200 OK)
After the checkout just
I created and uploaded a dump file (damn it's big), I hope this will help
you guys solving the problem.
http://www.sendspace.com/file/8m1osy
2013/6/20 Tobias Bading tbad...@web.de
On 20.06.2013 16:05, Daniel Shahaf wrote:
Tobias Bading wrote on Thu, Jun 20, 2013 at 16:01:45 +0200:
On
Rainer, can you check if the patch below works for you?
If so, we can merge both patches and put the new code into an #else block.
...
+ for (j = 0; j 4; j++)
+val |= (path[i + j] j);
...
It seems that this sode should be:
+ for (j = 0; j 4; j++)
+val |= (path[i
On Thu, Jun 20, 2013 at 04:30:33PM +0100, Julian Foad wrote:
I just noticed the Working copy records moves as first-class operation
section in the release notes may not be clear enough, as it doesn't
explicitly point out that the local move is NOT preserved as a move when
committed. I feel
The below is fixed with r1495054 for Subversion's site.
Hyrum's nightly Javadoc stored here probably needs fixed and it uses
whatever the system installed javadoc is on minotaur (which appears to be
an OpenJDK6 version, which I'm pretty sure is vulnerable since I used
something similar to
Did you read my email above? Let me explain again. Server advertises
supported authentication schemes, for example Microsoft IIS:
[[[
C: GET / HTTP/1.1
S: HTTP/1.1 401 Authorization Required
S: WWW-Authenticate: NTLM
S: WWW-Authenticate: Negotiate
S: WWW-Authenticate: Basic
]]]
Then
1.8.0 calls gcc with -std=c90. For my Solaris 10 Sparc using gcc 4.7.2
this leads to _STRICT_STDC getting defined and then limits.h no longer
defines PATH_MAX. So apr.h bombs out during compile with:
#error no decision has been made on APR_PATH_MAX for your platform
Adding e.g. EXTRA_CPPFLAGS =
On Thu, Jun 20, 2013 at 11:27 AM, Ivan Zhakov i...@visualsvn.com wrote:
Mark,
Wearing my VisualSVN CTO hat:
VisualSVN is a commercial company. And CollabNET is a commercial
company. That's not a surprise.
And it's not a surprise that VisualSVN Server authentication works
fine after upgrade
From: kmra...@rockwellcollins.com [mailto:kmra...@rockwellcollins.com]
Did you read my email above? Let me explain again. Server advertises
supported authentication schemes, for example Microsoft IIS:
[[[
C: GET / HTTP/1.1
S: HTTP/1.1 401 Authorization Required
S: WWW-Authenticate:
20 jun 2013 kl. 16.54 skrev Ivan Zhakov:
It seems the code is missing #ifdef SVN_UNALIGNED_ACCESS_IS_OK . The
attached patch should fix problem, but I'm not sure that this is right
solution for the problem.
Assuming the hash function does not need to be portable (which appears
likely from a
On Thu, Jun 20, 2013 at 8:02 PM, Mattias Engdegård
matti...@bredband.net wrote:
20 jun 2013 kl. 16.54 skrev Ivan Zhakov:
It seems the code is missing #ifdef SVN_UNALIGNED_ACCESS_IS_OK . The
attached patch should fix problem, but I'm not sure that this is right
solution for the problem.
On Thu, Jun 20, 2013 at 08:13:14PM +0400, Ivan Zhakov wrote:
On Thu, Jun 20, 2013 at 8:02 PM, Mattias Engdegård
matti...@bredband.net wrote:
20 jun 2013 kl. 16.54 skrev Ivan Zhakov:
It seems the code is missing #ifdef SVN_UNALIGNED_ACCESS_IS_OK . The
attached patch should fix problem,
C. Michael Pilato wrote:
On 06/20/2013 09:24 AM, Johan Corveleyn wrote:
I think this is an important change (improvement) that deserves
mention in the release notes, rather than being burried in the huge
CHANGES list. [...]
[...]
I agree that the feature is a good one to highlight.
Ben Reser wrote:
Julian Foad wrote:
+pWhat this emdoes not/em mean:/p
+ul
+ lipMoves are recorded as such only within the working copy. The link
+ between the copy and the delete is established only when a local move
+ operation is performed, and is lost upon commit./p/li
+/ul
This
One correction see below.
On 20.06.2013 18:02, Mattias Engdegård wrote:
20 jun 2013 kl. 16.54 skrev Ivan Zhakov:
It seems the code is missing #ifdef SVN_UNALIGNED_ACCESS_IS_OK . The
attached patch should fix problem, but I'm not sure that this is right
solution for the problem.
Assuming
Hi All!
I got exactly the same error with 1.8.0 on Windows 7 x64.
I have already reverted back to 1.7.9, but here's what I've noticed:
1. I work with 2 different svn repositaries, one is private, I don't know
what version of SVN is installed, but it works fine. The other one is https://
On 20.06.2013 16:20, Daniel Shahaf wrote:
Does Tortoise apply any patches to its binaries? That is, the svn.exe Bart
used contain any code not in our tag?
No, it's a plain svn.exe without any patches.
The only difference is how it's built: instead of a dll for each lib
there's only one dll
On 06/20/2013 12:21 PM, Julian Foad wrote:
I'll add it to the Command-line client improvements (client) section.
How about this patch?
+1
--
C. Michael Pilato cmpil...@collab.net
CollabNet www.collab.net Enterprise Cloud Development
On 20.06.2013 17:02, Bart van Oerle wrote:
I created and uploaded a dump file (damn it's big), I hope this will
help you guys solving the problem.
http://www.sendspace.com/file/8m1osy
Here's the stack trace:
BowPad
TortoiseProc.exe!svn_error_handle_malfunction(int can_return=0, const char *
-Original Message-
From: Stefan Küng [mailto:tortoise...@gmail.com]
Sent: donderdag 20 juni 2013 19:28
To: dev@subversion.apache.org Subversion Development
Subject: Re: error checking out in TortoiseSVN
On 20.06.2013 17:02, Bart van Oerle wrote:
I created and uploaded a dump
Hi,
Another crash that's climbing up in the crash report statistics for TSVN.
Seems to be related to the previously discussed problem with checkouts
in TSVN.
The stack trace:
BowPad
libsvn_tsvn.dll!svn_ra_serf__credentials_callback(char * *
username=0x, char * *
On Thu, Jun 20, 2013 at 6:20 PM, Stefan Sperling s...@elego.de wrote:
On Thu, Jun 20, 2013 at 08:13:14PM +0400, Ivan Zhakov wrote:
On Thu, Jun 20, 2013 at 8:02 PM, Mattias Engdegård
matti...@bredband.net wrote:
20 jun 2013 kl. 16.54 skrev Ivan Zhakov:
It seems the code is missing
20 jun 2013 kl. 21.44 skrev Stefan Fuhrmann:
A capable compiler should unroll the inner loop
such that we end up with ~10 cycles / 4 bytes.
That would be slightly faster than the * 33 loop.
That depends on a lot of things (such as the latency/throughput of the
multiplier).
By the way, the
On 20.06.2013 17:52, Rainer Jung wrote:
1.8.0 calls gcc with -std=c90. For my Solaris 10 Sparc using gcc 4.7.2
this leads to _STRICT_STDC getting defined and then limits.h no longer
defines PATH_MAX. So apr.h bombs out during compile with:
#error no decision has been made on APR_PATH_MAX for
On Thu, Jun 20, 2013 at 2:19 PM, Stefan Küng tortoise...@gmail.com wrote:
Hi,
Another crash that's climbing up in the crash report statistics for TSVN.
Seems to be related to the previously discussed problem with checkouts in
TSVN.
The stack trace:
BowPad
On 20.06.2013 22:30, Branko Čibej wrote:
On 20.06.2013 17:52, Rainer Jung wrote:
1.8.0 calls gcc with -std=c90. For my Solaris 10 Sparc using gcc 4.7.2
this leads to _STRICT_STDC getting defined and then limits.h no longer
defines PATH_MAX. So apr.h bombs out during compile with:
#error no
At the Hackathon I talked to a bunch of us about how I believe we need to start
implementing move tracking, and my overview of a plan, and there was wide
agreement from those present.
I am proposing that was tackle move tracking now.
Briefly
===
It comes from my wanting to make merging
On Thu, Jun 20, 2013 at 09:55:20PM +0100, Julian Foad wrote:
Johan Corveleyn wrote:
On Thu, Jun 20, 2013 at 7:27 PM, C. Michael Pilato cmpil...@collab.net
wrote:
On 06/20/2013 12:21 PM, Julian Foad wrote:
I'll add it to the Command-line client improvements (client) section.
How
On Thu, Jun 20, 2013 at 10:30 PM, Greg Stein gst...@gmail.com wrote:
On Thu, Jun 20, 2013 at 2:19 PM, Stefan Küng tortoise...@gmail.com wrote:
Hi,
Another crash that's climbing up in the crash report statistics for TSVN.
Seems to be related to the previously discussed problem with checkouts
On Fri, Jun 21, 2013 at 12:30 AM, Greg Stein gst...@gmail.com wrote:
On Thu, Jun 20, 2013 at 2:19 PM, Stefan Küng tortoise...@gmail.com wrote:
Hi,
Another crash that's climbing up in the crash report statistics for TSVN.
Seems to be related to the previously discussed problem with checkouts
On 20.06.2013 22:38, Branko Čibej wrote:
On 20.06.2013 22:30, Branko Čibej wrote:
On 20.06.2013 17:52, Rainer Jung wrote:
1.8.0 calls gcc with -std=c90. For my Solaris 10 Sparc using gcc 4.7.2
this leads to _STRICT_STDC getting defined and then limits.h no longer
defines PATH_MAX. So apr.h
Daniel Shahaf wrote:
On Thu, Jun 20, 2013 at 09:55:20PM +0100, Julian Foad wrote:
It's checked in 'svn' first, and if you call the client layer
directly then the requirement is still there but you'll get a
lower level error for it, [...]
(The check in 'svn' appears to have been removed
On 06/20/2013 02:40 PM, stef...@apache.org wrote:
Author: stefan2
Date: Thu Jun 20 21:40:50 2013
New Revision: 1495204
URL: http://svn.apache.org/r1495204
Log:
Follow-up to r1495063: integer overflows result in an inefficient hash
function and reduce cache effectiveness.
*
On Thu, Jun 20, 2013 at 12:33 PM, Stefan Sperling s...@elego.de wrote:
...
The customer would like early access to the features developed as
part of this effort. I think this is a great opportunity to get
real-world testing of new features before we decide whether to ship
them in an official
On Thu, Jun 20, 2013 at 10:03 PM, Mattias Engdegård
matti...@bredband.netwrote:
20 jun 2013 kl. 21.44 skrev Stefan Fuhrmann:
A capable compiler should unroll the inner loop
such that we end up with ~10 cycles / 4 bytes.
That would be slightly faster than the * 33 loop.
That depends on a
On Fri, Jun 21, 2013 at 2:11 AM, stef...@apache.org wrote:
Author: stefan2
Date: Thu Jun 20 22:11:31 2013
New Revision: 1495209
URL: http://svn.apache.org/r1495209
Log:
Make the hash function used by the FSFS DAG node cache
platform-independent. That should help us reproducing issues
On Thu, Jun 20, 2013 at 11:43 PM, Blair Zajac bl...@orcaware.com wrote:
On 06/20/2013 02:40 PM, stef...@apache.org wrote:
Author: stefan2
Date: Thu Jun 20 21:40:50 2013
New Revision: 1495204
URL: http://svn.apache.org/r1495204
Log:
Follow-up to r1495063: integer overflows result in an
21 jun 2013 kl. 00.32 skrev Stefan Fuhrmann:
After some IRC discussion, we added r1495209 which
provides actual platform-independence.
With the messy code and extra htonl() call cost where not inlined, I
doubt it's worth it. I'd just #if out the 4-byte acceleration as
originally proposed
Vitaly v.ketsenko at gmail.com writes:
Hi All!
I got exactly the same error with 1.8.0 on Windows 7 x64.
I have already reverted back to 1.7.9, but here's what I've noticed:
1. I work with 2 different svn repositaries, one is private, I don't know
what version of SVN is installed, but it
63 matches
Mail list logo
