Would "%s@%ld and %s@%ld must have a common ancestor" be easier to translate?
The term "ancestrally related" seems a bit complicated for translation :-P
On Mon, Jun 3, 2013 at 6:12 PM, wrote:
> Author: julianfoad
> Date: Mon Jun 3 22:12:41 2013
> New Revision: 1489203
>
> URL: http://svn.apach
On Mon, Jun 3, 2013 at 5:24 PM, Konstantin Kolinko
wrote:
> If you are considering 501 then there also exists 405 Method Not Allowed
> An implementation difference though is that 405 must be accompanied by
> an Allow header.
>
> Difference between 405 and 501 is also specified in ch.5.1.1 of RFC
>
2013/6/4 Greg Stein :
> On Mon, Jun 3, 2013 at 7:10 PM, Greg Stein wrote:
>> On Mon, Jun 3, 2013 at 6:48 PM, Ben Reser wrote:
>>...
>>> I'd argue that we should return a 500 range error since the problem
>>> here is that the server is not properly configured. There is really
>>
>> Nah. 500 means
On Mon, Jun 3, 2013 at 7:47 PM, Philip Martin
wrote:
>...
> However there is another HTTP_UNAUTHORIZED: mod_dav_svn returns it from
> lock.c:refresh_locks:
>
> /* Sanity check: does the incoming token actually represent the
> current lock on the incoming resource? */
> if ((! slock)
>
Greg Stein writes:
> On IRC, Ben and I tossed this around. The short answer is "the server
> is not configured to allow a LOCK operation." 501 (Not Implemented)
> states it is an appropriate status when the server is unable to
> support the request method.
>
> We can also adjust the error string
On Mon, Jun 3, 2013 at 7:10 PM, Greg Stein wrote:
> On Mon, Jun 3, 2013 at 6:48 PM, Ben Reser wrote:
>...
>> I'd argue that we should return a 500 range error since the problem
>> here is that the server is not properly configured. There is really
>
> Nah. 500 means there is nothing the client c
Ben Reser writes:
> That's my fault, I fixed the anonymous locking segfault and chose a
> 401 to return but I forgot about the WWW-Authenticate header
> requirement.
Not really your fault, even before your r1455352 mod_dav_svn returned
401. Without r1455352 append_locks calls svn_repos_fs_lock
On Mon, Jun 3, 2013 at 6:48 PM, Ben Reser wrote:
> On Mon, Jun 3, 2013 at 3:31 PM, Greg Stein wrote:
>...
>> Yeah. HTTP_CONFLICT should be correct, there.
>
> Well technically 401 is right but we have now way of filling in the
> proper WWW-Authenticate header. HTTP_CONFLICT doesn't sound
> parti
On Mon, Jun 3, 2013 at 3:31 PM, Greg Stein wrote:
> On Mon, Jun 3, 2013 at 6:09 PM, Philip Martin
> wrote:
>> Greg Stein writes:
>>
>>> On Mon, Jun 3, 2013 at 5:14 PM, Philip Martin
>>> wrote:
http://subversion.tigris.org/issues/show_bug.cgi?id=4368
Locking with anonymous http fa
I (Julian Foad) wrote:
> I (Julian Foad) wrote:
>> Stefan Küng wrote:
> This is the patch needed, modeled on the existing 'reintegrate' code
> (that's where the slightly strange error code comes from):
>
> [[[
> Index: subversion/libsvn_client/merge.c
>
On Mon, Jun 3, 2013 at 6:09 PM, Philip Martin
wrote:
> Greg Stein writes:
>
>> On Mon, Jun 3, 2013 at 5:14 PM, Philip Martin
>> wrote:
>>> http://subversion.tigris.org/issues/show_bug.cgi?id=4368
>>>
>>> Locking with anonymous http fails because there is no username. At
>>
>> That should be all
I (Julian Foad) wrote:
> Stefan Küng wrote:
>> SVN_ERR_W(svn_cl__check_related_source_and_target(
>> sourcepath1, &peg_revision1,
>> targetpath, &unspecified_revision, ctx, scratch_pool),
>> _("Source and target must be different but related branches"));
>>
>> To rep
Greg Stein writes:
> On Mon, Jun 3, 2013 at 5:14 PM, Philip Martin
> wrote:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=4368
>>
>> Locking with anonymous http fails because there is no username. At
>
> That should be allowed. A WebDAV lock does not require an owner.
svn_fs_lock requ
On Mon, Jun 3, 2013 at 5:14 PM, Philip Martin
wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4368
>
> Locking with anonymous http fails because there is no username. At
That should be allowed. A WebDAV lock does not require an owner.
> present mod_dav_svn returns "401 Unathorized"
http://subversion.tigris.org/issues/show_bug.cgi?id=4368
Locking with anonymous http fails because there is no username. At
present mod_dav_svn returns "401 Unathorized" however
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2
says that a 401 response MUST include a WWW-Authenti
On Mon, Jun 3, 2013 at 10:13 AM, Philip Martin
wrote:
> Johan Corveleyn writes:
>
>> ** Test 2 requires a lot of stack. PCRE can be configured to
>> ** use heap for recursion. Otherwise, to pass Test 2
>> ** you generally need to allocate 8 mb stack to PCRE.
>> ** See the 'pcrestack' page for a d
Stefan Küng wrote:
> I've got a small problem. As reported on the TSVN mailing list here:
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3057019
>
> an automatic merge can crash.
>
> The command line client does not, because it first checks the relationship of
> th
On Mon, Jun 3, 2013 at 10:22 AM, C. Michael Pilato wrote:
>...
> On the other hand, Serf 1.2.0 is the only available public Serf release with
> which Subversion 1.8.0 can operate[2], which really rather limits folks'
>...
> Unfortunately, there is as yet no public Serf release to date which contai
Hello everyone!
We have just made a release of serf 1.2.1. This fixes a number of
bugs, including a pretty bad bug in digest authentication on a single,
shared connection (issue 102). You can see all the changes at:
http://serf.googlecode.com/svn/tags/1.2.1/CHANGES
Download details are at:
ht
On 06/02/2013 10:53 PM, Markus Schaber wrote:
Hi, Blair,
Von: Blair Zajac [mailto:bl...@orcaware.com]
[Discussion whether to use (part of) C++ for SVN development]
I agree it's not worth going to C++. Where I'm coming from is a frustration
on the number of times I've seen pool lifetime bugs
Hi,
I've got a small problem. As reported on the TSVN mailing list here:
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3057019
an automatic merge can crash.
The command line client does not, because it first checks the
relationship of the urls:
merge-cmd.c, line 10
Belay that. I merged a couple extra things in the test suite, and
dropped one (just dealing with fixing a couple compiler warnings).
I'm going to wait for Lieven's +1 before cutting a release.
Cheers,
-g
On Mon, Jun 3, 2013 at 12:53 PM, Greg Stein wrote:
> Lieven produced a short list of chang
Lieven produced a short list of changes to release in 1.2.1, which I'm
merging now. The release should be done in about an hour.
Cheers,
-g
On Mon, Jun 3, 2013 at 11:36 AM, C. Michael Pilato wrote:
> On 06/03/2013 11:18 AM, Branko Čibej wrote:
>> I think it's clear that we have to wait for a Se
On 06/03/2013 11:18 AM, Branko Čibej wrote:
> I think it's clear that we have to wait for a Serf bugfix release before
> releasing RC3, and during that time our soak period is simply on hold.
> What happens after Serf 1.2.1 is released depends on the changes there.
> If it's just a trivial bugfix f
On Mon, Jun 3, 2013 at 8:18 AM, Branko Čibej wrote:
> I think it's clear that we have to wait for a Serf bugfix release before
> releasing RC3, and during that time our soak period is simply on hold.
> What happens after Serf 1.2.1 is released depends on the changes there.
> If it's just a trivial
On Mon, Jun 3, 2013 at 7:22 AM, C. Michael Pilato wrote:
> I'll suggest that the answer is found in how we'd track the issue locally.
> "Subversion requires Serf 1.2.1" would be a reasonable issue description.
> It would naturally be a 1.8.0 blocking issue. It's resolution (on our end,
> at least
I think it's clear that we have to wait for a Serf bugfix release before
releasing RC3, and during that time our soak period is simply on hold.
What happens after Serf 1.2.1 is released depends on the changes there.
If it's just a trivial bugfix for the digest authn issue, then we can
simply contin
Last week it was discovered that Serf 1.2.0 broke support for Digest
authentication, at least for applications such as Subversion where a
connection might be used for multiple requests against different URLs. You
can read about the problem in the issue where it was tracked (Serf issue
#102 [1]) an
On 06/03/2013 04:32 AM, Philip Martin wrote:
> This is a patch to svn_wc__get_tree_conflict which is only called from
> util.c:svn_wc__status2_from_3 which is itself only called in the main
> code from libsvn_wc/deprecated.c and libsvn_client/deprecated.c. That
> makes both svn_wc__get_tree_confli
On 03/06/13 13:31, Markus Schaber wrote:
Hi, Peter,
Von: Peter Weinert [mailto:peter.wein...@gns-mbh.com]
system: linux
subversion: v1.7.x
this problem starts when using version 1.7 of subversion.
until 1.6 every sub-dir had its own '.svn', so wherever i was, all
information to commit update
Branko Čibej :
> I believe the patch is not correct. It assumes unlimited buffering on
> the stdout and stderr pipes, which is never the case. The way Popen is
> used on the patch can cause the parent and child processes to
> deadlock.
>
> I suggest using Popen.communicate instead.
Agreed. commun
Hi, Peter,
Von: Peter Weinert [mailto:peter.wein...@gns-mbh.com]
>
> system: linux
> subversion: v1.7.x
>
> this problem starts when using version 1.7 of subversion.
> until 1.6 every sub-dir had its own '.svn', so wherever i was, all
> information to commit update was available.
> now there's o
On 03.06.2013 12:47, Neels Hofmeyr wrote:
> Hi dev,
>
> I tried to get svnperms.py going on a windows server (),
> but needed this patch to do so:
>
> http://svn.haxx.se/dev/archive-2009-04/0668.shtml
>
> It seems that no-one has answered Sergey on his patch submission back
> in 2009. (According to
Branko Čibej writes:
> On 03.06.2013 11:30, Bert Huijben wrote:
>> This function is also used from deprecated code in libsvn_cliënt and
>> some binding code, unlike most other deprecated code...
>>
>> In some ways this code is 'a bit less deprecated' ;-)
>
> And anyway, only public APIs can be de
system: linux
subversion: v1.7.x
this problem starts when using version 1.7 of subversion.
until 1.6 every sub-dir had its own '.svn', so wherever i was, all information
to commit update was available.
now there's only one, where one checked out the repo.
this is problematic when having somewher
Hi dev,
I tried to get svnperms.py going on a windows server (),
but needed this patch to do so:
http://svn.haxx.se/dev/archive-2009-04/0668.shtml
It seems that no-one has answered Sergey on his patch submission back
in 2009. (According to haxx.se, that thread ends right there.)
The patch remov
On 03.06.2013 11:30, Bert Huijben wrote:
> This function is also used from deprecated code in libsvn_cliënt and
> some binding code, unlike most other deprecated code...
>
> In some ways this code is 'a bit less deprecated' ;-)
And anyway, only public APIs can be deprecated. Private APIs are eithe
This function is also used from deprecated code in libsvn_cliënt and
some binding code, unlike most other deprecated code...
In some ways this code is 'a bit less deprecated' ;-)
Bert From: Philip Martin
Sent: 03/06/2013 10:33
To: Barry Scott
Cc: Subversion Development
Subject: Separating depreca
Philip Martin writes:
> Barry Scott writes:
>
>> Index: /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c
>> ===
>> --- /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c
>> (revision 1484244
Johan Corveleyn writes:
> ** Test 2 requires a lot of stack. PCRE can be configured to
> ** use heap for recursion. Otherwise, to pass Test 2
> ** you generally need to allocate 8 mb stack to PCRE.
> ** See the 'pcrestack' page for a discussion of PCRE's
> ** stack usage.
> ]]]
>
> So perhaps thi
Barry Scott writes:
> Index: /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c
> ===
> --- /Users/barry/wc/svn/svn-1.8.x/subversion/libsvn_wc/tree_conflicts.c
> (revision 1484244)
> +++ /Users/barry/wc/svn/sv
41 matches
Mail list logo
