Sure, sure. I wasn't attempting to be exhaustive. Just noting at least one.
Another big one would be Eclipse.
On Feb 9, 2012 10:54 PM, "Daniel Shahaf" wrote:
> I'd argue that it matters for any long-lived client. That includes all
> GUI clients, and even Python:
>
> % python
> >>> from math impo
I'd argue that it matters for any long-lived client. That includes all
GUI clients, and even Python:
% python
>>> from math import *
>>> x = (pi+e)/2.0
>>> from svn import *
>>> client.checkout3("https://github.com/foo/bar";)
Aborted (core dumped)
%
Greg Stein wrote on Thu, Feb 09, 2012 at 22:4
Hrm. Yeah... I guess for a Windows shell extension, that is a significant
distinction.
Thx
-g
On Feb 9, 2012 10:39 PM, "Daniel Shahaf" wrote:
> Old code allows malicious servers to abort() the process libsvn is
> linked to, new code doesn't.
>
> Greg Stein wrote on Thu, Feb 09, 2012 at 22:14:39
Old code allows malicious servers to abort() the process libsvn is
linked to, new code doesn't.
Greg Stein wrote on Thu, Feb 09, 2012 at 22:14:39 -0500:
> DoS? With the old code: the client died. With the new code: the client
> dies. No change that I'm aware of, other than a nicer error message.
>
DoS? With the old code: the client died. With the new code: the client
dies. No change that I'm aware of, other than a nicer error message.
It seems the justification would be, "nicer error message" rather than
anything about DoS.
Cheers,
-g
On Feb 9, 2012 6:46 PM, wrote:
> Author: danielsh
> D
On Thu, Feb 9, 2012 at 21:53, Daniel Shahaf wrote:
> Nick Hengeveld wrote on Thu, Feb 09, 2012 at 17:29:14 -0800:
>...
>> What's the best way to track down issues like this? I'm not currently
>> familiar
>> with svn client debugging but would be happy to learn.
>>
>
> For svn client debugging, th
Hey Nick!
Thanks for looking into this.
On Thu, Feb 9, 2012 at 20:29, Nick Hengeveld wrote:
> On Wed, Feb 8, 2012 at 12:59 PM, Greg Stein wrote:
>
>> So... this isn't really so much about "svn must allow for HTTP/1.0"
>> (yes, we'll work on it), but that github could also provide better
>> serv
Nick Hengeveld wrote on Thu, Feb 09, 2012 at 17:29:14 -0800:
> On Wed, Feb 8, 2012 at 12:59 PM, Greg Stein wrote:
>
> So... this isn't really so much about "svn must allow for HTTP/1.0"
> > (yes, we'll work on it), but that github could also provide better
> > service overall by updating its prox
On Wed, Feb 8, 2012 at 12:59 PM, Greg Stein wrote:
So... this isn't really so much about "svn must allow for HTTP/1.0"
> (yes, we'll work on it), but that github could also provide better
> service overall by updating its proxy.
>
I've been looking into what it would take to update our proxy. I
I know you're just shifting existing code, but that header should use
svn_stringbuf_createf(), or a series of appends. A stream is overkill.
On Feb 9, 2012 5:29 PM, wrote:
> Author: hwright
> Date: Thu Feb 9 22:29:06 2012
> New Revision: 1242567
>
> URL: http://svn.apache.org/viewvc?rev=1242567&
Ah, good one.
On Feb 9, 2012 6:45 PM, wrote:
> Author: danielsh
> Date: Thu Feb 9 23:45:03 2012
> New Revision: 1242607
>
> URL: http://svn.apache.org/viewvc?rev=1242607&view=rev
> Log:
> Convert asserts into errors.
>
> * subversion/libsvn_ra_serf/update.c
> (start_report): Gracefully error ou
On Thu, Feb 9, 2012 at 9:55 PM, Greg Stein wrote:
>
> On Feb 9, 2012 3:07 PM, "Paul Burba" wrote:
>>
>> On Thu, Feb 9, 2012 at 2:50 PM, Johan Corveleyn wrote:
>> > On Thu, Feb 9, 2012 at 7:59 PM, Greg Stein wrote:
>> >>
>> >> On Feb 9, 2012 1:23 PM, "Paul Burba" wrote:
>> >>>
>> >>> On Thu, Fe
Greg Stein wrote on Thu, Feb 09, 2012 at 17:43:25 -0500:
> On Feb 9, 2012 5:04 PM, "Hyrum K Wright" wrote:
> >
> > I find myself wanting to use the 'with' statement in the test suite,
> > which was introduced in Python 2.5 Python 2.5 was released 5.5 years
> > ago, and while I'm sure somebody on
Hyrum K Wright wrote on Thu, Feb 09, 2012 at 16:27:39 -0600:
> On Thu, Feb 9, 2012 at 4:10 PM, Daniel Shahaf wrote:
> > Hyrum K Wright wrote on Thu, Feb 09, 2012 at 16:04:06 -0600:
> >> I find myself wanting to use the 'with' statement in the test suite,
> >> which was introduced in Python 2.5 Py
On Feb 9, 2012 5:04 PM, "Hyrum K Wright" wrote:
>
> I find myself wanting to use the 'with' statement in the test suite,
> which was introduced in Python 2.5 Python 2.5 was released 5.5 years
> ago, and while I'm sure somebody on some archaic platform somewhere
> doesn't have it installed, I thin
On Thu, Feb 9, 2012 at 4:10 PM, Daniel Shahaf wrote:
> Hyrum K Wright wrote on Thu, Feb 09, 2012 at 16:04:06 -0600:
>> I find myself wanting to use the 'with' statement in the test suite,
>> which was introduced in Python 2.5 Python 2.5 was released 5.5 years
>> ago, and while I'm sure somebody o
[Hyrum K Wright]
> I think we can reasonably assume that Python 2.5 is generally
> available. For reference, we currently require and SQLite that is
> only 2.5-years-old.
Obligatory "what about Debian users, since that platform is always so
far behind": the oldest supported Debian release, lenny
Hyrum K Wright wrote on Thu, Feb 09, 2012 at 16:04:06 -0600:
> I find myself wanting to use the 'with' statement in the test suite,
> which was introduced in Python 2.5 Python 2.5 was released 5.5 years
> ago, and while I'm sure somebody on some archaic platform somewhere
> doesn't have it install
I find myself wanting to use the 'with' statement in the test suite,
which was introduced in Python 2.5 Python 2.5 was released 5.5 years
ago, and while I'm sure somebody on some archaic platform somewhere
doesn't have it installed, I think we can reasonably assume that
Python 2.5 is generally ava
[TheBlueSky .Net]
> Sorry if I have posted this in the not-right place :)
That's fine. It was an assertion failure which, by definition, is a
bug in the Subversion client. The bug was triggered by a bug on the
Github server side, but it's still a bug in the client.
Also, happily, someone at Gi
Hey all,
We have Ev2 somewhere on the future horizon. This means that many APIs
are going to be rev'd to take the new editor type. We likely aren't
going to get them into 1.8, but I'd like to go ahead and deprecate the
appropriate interfaces in svn_wc. The client lib can switch to some
internal/pr
On Feb 9, 2012 3:07 PM, "Paul Burba" wrote:
>
> On Thu, Feb 9, 2012 at 2:50 PM, Johan Corveleyn wrote:
> > On Thu, Feb 9, 2012 at 7:59 PM, Greg Stein wrote:
> >>
> >> On Feb 9, 2012 1:23 PM, "Paul Burba" wrote:
> >>>
> >>> On Thu, Feb 9, 2012 at 11:49 AM, Daniel Shahaf
wrote:
> >>> >...
> >>
>
Sorry if I have posted this in the not-right place :)
It's not like someone is going to die if I didn't checked out a git repo
from SVN client; I was only testing it as other people have done it
successfully.
Anyway, the only reason I posted in this mailing list is because the error
message told
On Thu, Feb 9, 2012 at 2:50 PM, Johan Corveleyn wrote:
> On Thu, Feb 9, 2012 at 7:59 PM, Greg Stein wrote:
>>
>> On Feb 9, 2012 1:23 PM, "Paul Burba" wrote:
>>>
>>> On Thu, Feb 9, 2012 at 11:49 AM, Daniel Shahaf wrote:
>>> >...
>>
>>> > It is suggested there that setting
>>> > libsvn_ra_serf/up
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: donderdag 9 februari 2012 20:34
> To: dev@subversion.apache.org
> Subject: disallow mixed-revision WC->{WC,URL} copies by default?
>
> Recently we had a user in #svn who somehow managed to create a
> copy that coul
On Thu, Feb 9, 2012 at 7:59 PM, Greg Stein wrote:
>
> On Feb 9, 2012 1:23 PM, "Paul Burba" wrote:
>>
>> On Thu, Feb 9, 2012 at 11:49 AM, Daniel Shahaf wrote:
>> >...
>
>> > It is suggested there that setting
>> > libsvn_ra_serf/update.c:MAX_NR_OF_CONNS
>> > to "2" will prevent ra_serf from drivi
Recently we had a user in #svn who somehow managed to create a
copy that could not be committed because of out-of-dateness errors.
I am not exactly sure what the real cause of the problem was.
It could be worked around by using a URL as copy source. So it
is likely that mixed-revisionnes somehow i
Hyrum K Wright wrote on Thu, Feb 09, 2012 at 13:16:13 -0600:
> On Thu, Feb 9, 2012 at 1:05 PM, Daniel Shahaf wrote:
> > Hyrum K Wright wrote on Thu, Feb 09, 2012 at 12:54:50 -0600:
> >> (I'll also note that we actually *do* have a checksum by this point,
> >> only it is the md5 provided by close_f
On Thu, Feb 9, 2012 at 11:32 AM, Mark Phippard wrote:
> On Thu, Feb 9, 2012 at 12:26 PM, C. Michael Pilato
> wrote:
>
>> Bah. I'd be surprised if most of our editors supported postfix text deltas.
>> To my knowledge, there is exactly one driver which uses that approach in
>> our own codebase (
On Thu, Feb 9, 2012 at 1:05 PM, Daniel Shahaf wrote:
> Hyrum K Wright wrote on Thu, Feb 09, 2012 at 12:54:50 -0600:
>> (I'll also note that we actually *do* have a checksum by this point,
>> only it is the md5 provided by close_file(), and Ev2 uses sha1s
>> exclusively, so we have to recalculate.
Greg Stein writes:
> What happens when you set MAX_NR_CONNS (that's not the right symbol, but
> close) in linsvn_ra_serf/update.c to 2 ? That should eliminate the
> parallelism. If that succeeds, then maybe we can patch 1.7.x in some way to
> allow svnrdump to set that max, yet keep multiple for
Hyrum K Wright wrote on Thu, Feb 09, 2012 at 12:54:50 -0600:
> (I'll also note that we actually *do* have a checksum by this point,
> only it is the md5 provided by close_file(), and Ev2 uses sha1s
> exclusively, so we have to recalculate. I suspect this will be a
Only sha1? It allows neither md
On Feb 9, 2012 1:23 PM, "Paul Burba" wrote:
>
> On Thu, Feb 9, 2012 at 11:49 AM, Daniel Shahaf wrote:
> >...
> > It is suggested there that setting
libsvn_ra_serf/update.c:MAX_NR_OF_CONNS
> > to "2" will prevent ra_serf from driving multiple window handlers
> > concurrently and thus avoid the bug
> From: Philip Martin
> To: Greg Stein
> Cc: dev@subversion.apache.org
> Sent: Thursday, 9 February 2012, 18:13
> Subject: Re: svn commit: r1242397 - in
> /subversion/trunk/subversion/libsvn_subr: skel.c stream.c
>
>G reg Stein writes:
>
>> I don't think this is the correct approach. svn_str
On Feb 9, 2012 1:29 PM, "Philip Martin" wrote:
>
> Johan Corveleyn writes:
>
> > The "dangerous behavior" may have been present in 1.7.0 already, but
> > 1.7.3 will be the first release where this appeared to cause a real
> > issue. I mean, for some reason the bug (or manifestation of the
> > "li
On Thu, Feb 9, 2012 at 12:24 PM, Daniel Shahaf wrote:
> hwri...@apache.org wrote on Wed, Feb 08, 2012 at 01:55:55 -:
>> Author: hwright
>> Date: Wed Feb 8 01:55:54 2012
>> New Revision: 1241733
>>
>> URL: http://svn.apache.org/viewvc?rev=1241733&view=rev
>> Log:
>> Ev2 shims: Make sure that i
On Thu, Feb 9, 2012 at 7:23 PM, Paul Burba wrote:
[ ... ]
> However, if I let the test suite start up httpd, then I *do*
> consistently see the same failure:
Wow, I wouldn't have thought of that as a discriminating factor. I'm
running the server in a separate command window, just running httpd.
On 02/09/2012 12:35 PM, Greg Stein wrote:
> If it is determined that ra_serf's parallelism is at fault here, then we can
> force it to use a single connection for svnrdump. That should make it follow
> the right order.
>
> (and yeah, it sucks when you try to advance the capabilities and get yanked
Johan Corveleyn writes:
> The "dangerous behavior" may have been present in 1.7.0 already, but
> 1.7.3 will be the first release where this appeared to cause a real
> issue. I mean, for some reason the bug (or manifestation of the
> "lingering bug") first appeared on 1.7.x after r1239697 (backpor
hwri...@apache.org wrote on Wed, Feb 08, 2012 at 01:55:55 -:
> Author: hwright
> Date: Wed Feb 8 01:55:54 2012
> New Revision: 1241733
>
> URL: http://svn.apache.org/viewvc?rev=1241733&view=rev
> Log:
> Ev2 shims: Make sure that if we are providing content to alter_file(), we
> are also provi
On Thu, Feb 9, 2012 at 11:49 AM, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Thu, Feb 09, 2012 at 02:33:25 +0100:
>> Having another look at this failure ...
>>
>> So far, we know (anyone, correct me if I'm wrong):
>>
>> - 'svnrdump load' in this test fails with: "svnrdump: E140001:
>> Unrecogn
Greg Stein writes:
> I don't think this is the correct approach. svn_stringbuf_t is
> *designed* to put a NUL at the end of the public length. Thus, it is
> supposed to properly manage the +1 inside its functions.
>
> The correct fix is to put a ++minimum_size into svn_stringbuf_ensure()
> rather
On Thu, Feb 9, 2012 at 6:32 PM, Mark Phippard wrote:
> On Thu, Feb 9, 2012 at 12:26 PM, C. Michael Pilato
> wrote:
>
>> Bah. I'd be surprised if most of our editors supported postfix text deltas.
>> To my knowledge, there is exactly one driver which uses that approach in
>> our own codebase (t
Peter Samuelson writes:
> [Philip Martin]
>> --- ../src/subversion/libsvn_subr/svn_base64.c (revision 1242045)
>> +++ ../src/subversion/libsvn_subr/svn_base64.c (working copy)
>> @@ -410,7 +410,7 @@
>>/* Resize the stringbuf to make room for the (approximate) size of
>> output, to avo
[Philip Martin]
> --- ../src/subversion/libsvn_subr/svn_base64.c (revision 1242045)
> +++ ../src/subversion/libsvn_subr/svn_base64.c (working copy)
> @@ -410,7 +410,7 @@
>/* Resize the stringbuf to make room for the (approximate) size of
> output, to avoid repeated resizes later.
>
On Feb 9, 2012 12:26 PM, "C. Michael Pilato" wrote:
>
> On 02/09/2012 11:41 AM, Philip Martin wrote:
> > "C. Michael Pilato" writes:
> >
> >> On 02/09/2012 05:22 AM, Philip Martin wrote:
> >>> Hyrum K Wright writes:
> >>>
> Is there any sense of closure on the serf+windows test failure on t
On Thu, Feb 9, 2012 at 12:26 PM, C. Michael Pilato wrote:
> Bah. I'd be surprised if most of our editors supported postfix text deltas.
> To my knowledge, there is exactly one driver which uses that approach in
> our own codebase (the commit driver). So, I can easily forgive svnrdump's
> dump
On 02/09/2012 11:41 AM, Philip Martin wrote:
> "C. Michael Pilato" writes:
>
>> On 02/09/2012 05:22 AM, Philip Martin wrote:
>>> Hyrum K Wright writes:
>>>
Is there any sense of closure on the serf+windows test failure on the
1.7.x branch? My sense is that the failure does *not* expos
I don't think this is the correct approach. svn_stringbuf_t is
*designed* to put a NUL at the end of the public length. Thus, it is
supposed to properly manage the +1 inside its functions.
The correct fix is to put a ++minimum_size into svn_stringbuf_ensure()
rather than make callers worry about s
"C. Michael Pilato" writes:
> On 02/09/2012 05:22 AM, Philip Martin wrote:
>> Hyrum K Wright writes:
>>
>>> Is there any sense of closure on the serf+windows test failure on the
>>> 1.7.x branch? My sense is that the failure does *not* expose a new
>>> bug on the branch, but rather smokes out
Johan Corveleyn wrote on Thu, Feb 09, 2012 at 02:33:25 +0100:
> Having another look at this failure ...
>
> So far, we know (anyone, correct me if I'm wrong):
>
> - 'svnrdump load' in this test fails with: "svnrdump: E140001:
> Unrecognized record type in stream". It seems the dumpfile contents o
On Thu, Feb 9, 2012 at 10:13 AM, C. Michael Pilato wrote:
> On 02/09/2012 05:22 AM, Philip Martin wrote:
>> Hyrum K Wright writes:
>>
>>> Is there any sense of closure on the serf+windows test failure on the
>>> 1.7.x branch? My sense is that the failure does *not* expose a new
>>> bug on the br
On 02/09/2012 05:22 AM, Philip Martin wrote:
> Hyrum K Wright writes:
>
>> Is there any sense of closure on the serf+windows test failure on the
>> 1.7.x branch? My sense is that the failure does *not* expose a new
>> bug on the branch, but rather smokes out an existing one.
>
> That's my view
stef...@apache.org wrote on Wed, Feb 08, 2012 at 00:44:26 -:
> Author: stefan2
> Date: Wed Feb 8 00:44:26 2012
> New Revision: 1241718
>
> URL: http://svn.apache.org/viewvc?rev=1241718&view=rev
> Log:
> Major improvement in delta window handling: Cache intermediate
> combined delta windows su
Johan Corveleyn writes:
> I'm not very experienced in debugging C code ... any hints on how to
> get a hold of the callstack easily? I'd think of setting a breakpoint
> there, but it would be best to do that with a conditional breakpoint
> somehow, to avoid having to resume a dozen times.
There
Johan Corveleyn wrote on Thu, Feb 09, 2012 at 11:44:52 +0100:
> On Thu, Feb 9, 2012 at 10:45 AM, Philip Martin
> wrote:
> > Johan Corveleyn writes:
> >
> >> DBG: dump_editor.c: 756: close_file 0112B188
> >> DBG: dump_editor.c: 552: add_file trunk/D/H/psi
> >> DBG: dump_editor.c: 725: apply_textde
Johan Corveleyn wrote on Thu, Feb 09, 2012 at 04:03:43 +0100:
> BTW: for some reason, the test now also fails with this last test-run
> (with mod_dav_svn@1.7.x@1239696), but with another failure:
>
> "svnrdump: E140001: Dump stream contains a malformed header (with no
> ':') at 'ile_prop 0112B188'
On Thu, Feb 9, 2012 at 10:45 AM, Philip Martin
wrote:
> Johan Corveleyn writes:
>
>> DBG: dump_editor.c: 756: close_file 0112B188
>> DBG: dump_editor.c: 552: add_file trunk/D/H/psi
>> DBG: dump_editor.c: 725: apply_textdelta 0112B188
>> DBG: dump_editor.c: 633: change_dir_prop 01150F00
>> DBG: du
Hyrum K Wright writes:
> Is there any sense of closure on the serf+windows test failure on the
> 1.7.x branch? My sense is that the failure does *not* expose a new
> bug on the branch, but rather smokes out an existing one.
That's my view as well. svnrdump has a bug that causes it to rely on
t
Johan Corveleyn writes:
> DBG: dump_editor.c: 756: close_file 0112B188
> DBG: dump_editor.c: 552: add_file trunk/D/H/psi
> DBG: dump_editor.c: 725: apply_textdelta 0112B188
> DBG: dump_editor.c: 633: change_dir_prop 01150F00
> DBG: dump_editor.c: 633: change_dir_prop 01150F00
> DBG: dump_editor.c
60 matches
Mail list logo
