Re: bug in can_modify()

2012-05-16 Thread Greg Stein
On May 15, 2012 6:04 PM, "Hyrum K Wright" wrote: >... > This research comes as a result of the final test failures on the > ev2-export branch for commit: tree conflicts tests 4 and 8. Both of > these set up the tree conflict scenario, and in doing so occasionally > expect an out-of-date error, wh

Re: svn commit: r1339233 - in /subversion/trunk/subversion: libsvn_ra_neon/util.c libsvn_ra_serf/util.c tests/cmdline/prop_tests.py tests/cmdline/svnmucc_tests.py

2012-05-16 Thread Greg Stein
On Wed, May 16, 2012 at 11:37 AM, wrote: > Author: philip > Date: Wed May 16 15:37:10 2012 > New Revision: 1339233 > > URL: http://svn.apache.org/viewvc?rev=1339233&view=rev > Log: > Apache puts extra newlines in responses when built with AP_DEBUG > so remove these from some error messages.  Fix

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 7:29 PM, Greg Stein wrote: > Excellent. And that told me what I needed to know. I believe it is now > fixed in r1339425. Give it a whirl, please. Fix confirmed. -- Thanks Mark Phippard http://markphip.blogspot.com/

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Greg Stein
On Wed, May 16, 2012 at 6:34 PM, Mark Phippard wrote: > On Wed, May 16, 2012 at 5:55 PM, Greg Stein wrote: >> On Wed, May 16, 2012 at 11:45 AM, Mark Phippard wrote: >>> I cannot recreate this with the Apache repository, but with a local >>> 1.7.5 server and current trunk client I get this: >>> >

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 5:55 PM, Greg Stein wrote: > On Wed, May 16, 2012 at 11:45 AM, Mark Phippard wrote: >> I cannot recreate this with the Apache repository, but with a local >> 1.7.5 server and current trunk client I get this: >> >> $ svn co http://cu121.cloud.sp.collab.net/svn/desktop deskt

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Greg Stein
On May 16, 2012 6:04 PM, "Ivan Zhakov" wrote: > > On Thu, May 17, 2012 at 1:55 AM, Greg Stein wrote: > > On Wed, May 16, 2012 at 11:45 AM, Mark Phippard wrote: > >> I cannot recreate this with the Apache repository, but with a local > >> 1.7.5 server and current trunk client I get this: > >> > >

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Ivan Zhakov
On Thu, May 17, 2012 at 1:55 AM, Greg Stein wrote: > On Wed, May 16, 2012 at 11:45 AM, Mark Phippard wrote: >> I cannot recreate this with the Apache repository, but with a local >> 1.7.5 server and current trunk client I get this: >> >> $ svn co http://cu121.cloud.sp.collab.net/svn/desktop deskt

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Greg Stein
On Wed, May 16, 2012 at 11:45 AM, Mark Phippard wrote: > I cannot recreate this with the Apache repository, but with a local > 1.7.5 server and current trunk client I get this: > > $ svn co http://cu121.cloud.sp.collab.net/svn/desktop desktop > --username=markphip --depth=immediates > subversion/s

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Greg Stein
On May 16, 2012 4:06 PM, "Mark Phippard" wrote: > > On Wed, May 16, 2012 at 4:04 PM, Greg Stein wrote: > > > > On May 16, 2012 3:00 PM, "Justin Erenkrantz" wrote: > >> > >> On Wed, May 16, 2012 at 11:54 AM, Mark Phippard > >> wrote: > >> > NOTE the length stuff that happened in the middle of th

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Blair Zajac
On 05/16/2012 11:15 AM, Justin Erenkrantz wrote: On Wed, May 16, 2012 at 11:10 AM, Mark Phippard wrote: I found another tool that worked ( I think I just needed to run wireshark as root), however this tool and tcpdump both do not give what I want. I am going through a VPN and it looks like all

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 4:12 PM, Mark Phippard wrote: > On Wed, May 16, 2012 at 4:06 PM, Mark Phippard wrote: > >> I do not think the server sent garbage.  It sent a chunked response >> where the entire OPTIONS response did not come in one packet.  When >> this happens with the new code it seems

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 4:06 PM, Mark Phippard wrote: > I do not think the server sent garbage.  It sent a chunked response > where the entire OPTIONS response did not come in one packet.  When > this happens with the new code it seems to break. > > As Justin said, the date/time was simply insert

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 4:04 PM, Greg Stein wrote: > > On May 16, 2012 3:00 PM, "Justin Erenkrantz" wrote: >> >> On Wed, May 16, 2012 at 11:54 AM, Mark Phippard >> wrote: >> > NOTE the length stuff that happened in the middle of the response? >> >> Yah, that'd be a CDATA spanning TCP packets as

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Greg Stein
On May 16, 2012 3:00 PM, "Justin Erenkrantz" wrote: > > On Wed, May 16, 2012 at 11:54 AM, Mark Phippard wrote: > > NOTE the length stuff that happened in the middle of the response? > > Yah, that'd be a CDATA spanning TCP packets as socat puts in > timestamps when a new packet arrives. > > So, ya

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Philip Martin
Justin Erenkrantz writes: > On Wed, May 16, 2012 at 11:59 AM, Philip Martin > wrote: >> Those look like the numbers with mod-deflate in the path.  Although >> mod-deflate reduces the traffic it pushes up the server CPU because serf >> is pushing so much more data through the compressor.  It's no

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Daniel Shahaf
Philip Martin wrote on Wed, May 16, 2012 at 19:59:15 +0100: > Justin Erenkrantz writes: > > > On Wed, May 16, 2012 at 11:17 AM, Daniel Shahaf wrote: > >> Perhaps I wasn't clear.  The traffic using ra_serf is 2.2 times as much > >> as using ra_neon; see the (currently) last comment on the issue P

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Philip Martin
Philip Martin writes: > Mark Phippard writes: > >> Greg is working on. I will try Philip's suggestion but assume I need >> to read up on what he suggested so that I understand what I need to >> do. > > Something like this: > > $ socat -v TCP4-LISTEN:8080,reuseaddr,fork TCP4:svn.apache.org:http

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Justin Erenkrantz
On Wed, May 16, 2012 at 11:59 AM, Philip Martin wrote: > Those look like the numbers with mod-deflate in the path.  Although > mod-deflate reduces the traffic it pushes up the server CPU because serf > is pushing so much more data through the compressor.  It's not much of a > selling point that se

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Justin Erenkrantz
On Wed, May 16, 2012 at 11:54 AM, Mark Phippard wrote: > NOTE the length stuff that happened in the middle of the response? Yah, that'd be a CDATA spanning TCP packets as socat puts in timestamps when a new packet arrives. So, yah, Greg's the most recent culprit in that space. =P -- justin

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Philip Martin
Justin Erenkrantz writes: > On Wed, May 16, 2012 at 11:17 AM, Daniel Shahaf wrote: >> Perhaps I wasn't clear.  The traffic using ra_serf is 2.2 times as much >> as using ra_neon; see the (currently) last comment on the issue Philip >> links to. > > I definitely don't see that locally - I only se

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Daniel Shahaf
Philip Martin wrote on Wed, May 16, 2012 at 19:55:41 +0100: > Mark Phippard writes: > > > Greg is working on. I will try Philip's suggestion but assume I need > > to read up on what he suggested so that I understand what I need to > > do. > > Something like this: > > $ socat -v TCP4-LISTEN:808

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Philip Martin
Mark Phippard writes: > Greg is working on. I will try Philip's suggestion but assume I need > to read up on what he suggested so that I understand what I need to > do. Something like this: $ socat -v TCP4-LISTEN:8080,reuseaddr,fork TCP4:svn.apache.org:http then in another window something li

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Mark Phippard
Justin helped my get socat working on IRC. For archives sake, I basically am using it as a proxy. I added localhost:8080 as my proxy in servers and then it worked great. Here is the response it logs in the failed request: /svn/de< 2012/05/16 14:45:54.190315 length=74 from=1852 to=1925 sktop/

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Peter Samuelson
[Greg Stein] > A following question asks about API compatibility. I believe we can > simply sub ra_serf into any loader/query for ra_neon. Hard linkage to > the ra_neon library may also need a solution (it becomes a shim?). I was concerned with this exact issue when libsvn_ra_dav was renamed to l

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 2:30 PM, Justin Erenkrantz wrote: > On Wed, May 16, 2012 at 11:29 AM, Mark Phippard wrote: >> Obviously I am not understanding how to use this tool. > > Ahh...you then run tcpdump against localhost port 8080 (probably > requiring interface lo0).  socat just gets you around

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Justin Erenkrantz
On Wed, May 16, 2012 at 11:29 AM, Mark Phippard wrote: > Obviously I am not understanding how to use this tool. Ahh...you then run tcpdump against localhost port 8080 (probably requiring interface lo0). socat just gets you around the VPN issue. -- justin

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 2:10 PM, Philip Martin wrote: > Justin Erenkrantz writes: > >> On Wed, May 16, 2012 at 10:55 AM, Mark Phippard wrote: >>> I am trying Wireshark but it says I do not have any interfaces it can >>> use.  I am on a Macbook Air so maybe it needs an Ethernet adapter. >>> Looki

Re: svn commit: r1335639 - /subversion/trunk/subversion/libsvn_wc/adm_ops.c

2012-05-16 Thread Justin Erenkrantz
On Wed, May 16, 2012 at 11:17 AM, Ivan Zhakov wrote: > It seems to be a good thing to try to implement on Hackathon in Berlin. > > I'm often switching between different branches and I'll benefit a lot > if this operation will just take one REPORT request, instead of many > PROPFINDs for each added

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Justin Erenkrantz
On Wed, May 16, 2012 at 11:17 AM, Daniel Shahaf wrote: > Perhaps I wasn't clear.  The traffic using ra_serf is 2.2 times as much > as using ra_neon; see the (currently) last comment on the issue Philip > links to. I definitely don't see that locally - I only see about a 20-25% gap - which from lo

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 2:15 PM, Justin Erenkrantz wrote: > On Wed, May 16, 2012 at 11:10 AM, Mark Phippard wrote: >> I found another tool that worked ( I think I just needed to run >> wireshark as root), however this tool and tcpdump both do not give >> what I want.  I am going through a VPN and

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Philip Martin
Justin Erenkrantz writes: > Philip's trick to redirect the traffic to local port 8080 via socat > should let you see what your client is sending. And receiving. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com

Re: svn commit: r1335639 - /subversion/trunk/subversion/libsvn_wc/adm_ops.c

2012-05-16 Thread Ivan Zhakov
On Thu, May 10, 2012 at 5:41 PM, C. Michael Pilato wrote: > On 05/10/2012 06:21 AM, Ivan Zhakov wrote: >> It seems that ra_serf unconditionally retrieves properties using >> PROPFIND for *all* added files: > > Yup, that's what I said.  :-) > >> subversion\libsvn_ra_serf\update.c:1633 (start_report

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Daniel Shahaf
Justin Erenkrantz wrote on Wed, May 16, 2012 at 11:13:16 -0700: > On Wed, May 16, 2012 at 10:48 AM, Daniel Shahaf wrote: > > Philip Martin wrote on Wed, May 16, 2012 at 18:39:37 +0100: > >> The issue that worries me the most is the traffic issue: > >> > >> http://subversion.tigris.org/issues/show_

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Justin Erenkrantz
On Wed, May 16, 2012 at 11:10 AM, Mark Phippard wrote: > I found another tool that worked ( I think I just needed to run > wireshark as root), however this tool and tcpdump both do not give > what I want.  I am going through a VPN and it looks like all the > packets are encrypted.  The protocol fo

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Justin Erenkrantz
On Wed, May 16, 2012 at 10:48 AM, Daniel Shahaf wrote: > Philip Martin wrote on Wed, May 16, 2012 at 18:39:37 +0100: >> The issue that worries me the most is the traffic issue: >> >> http://subversion.tigris.org/issues/show_bug.cgi?id=3980 > > Your recent figures on that issue show a +122% increas

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 1:57 PM, Justin Erenkrantz wrote: > On Wed, May 16, 2012 at 10:55 AM, Mark Phippard wrote: >> I am trying Wireshark but it says I do not have any interfaces it can >> use.  I am on a Macbook Air so maybe it needs an Ethernet adapter. >> Looking for other mac capture tools

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Philip Martin
Justin Erenkrantz writes: > On Wed, May 16, 2012 at 10:55 AM, Mark Phippard wrote: >> I am trying Wireshark but it says I do not have any interfaces it can >> use.  I am on a Macbook Air so maybe it needs an Ethernet adapter. >> Looking for other mac capture tools right now. > > As root, use: >

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Justin Erenkrantz
On Wed, May 16, 2012 at 10:55 AM, Mark Phippard wrote: > I am trying Wireshark but it says I do not have any interfaces it can > use.  I am on a Macbook Air so maybe it needs an Ethernet adapter. > Looking for other mac capture tools right now. As root, use: # tcpdump -w /tmp/mycapture.dump -i e

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 1:50 PM, Justin Erenkrantz wrote: > On Wed, May 16, 2012 at 8:45 AM, Mark Phippard wrote: >> I cannot recreate this with the Apache repository, but with a local >> 1.7.5 server and current trunk client I get this: > > I tried with a local 1.7.5 server and can't reproduce t

Re: Trunk checkout fails with serf but not neon

2012-05-16 Thread Justin Erenkrantz
On Wed, May 16, 2012 at 8:45 AM, Mark Phippard wrote: > I cannot recreate this with the Apache repository, but with a local > 1.7.5 server and current trunk client I get this: I tried with a local 1.7.5 server and can't reproduce this. It looks like the OPTIONS request is failing (note the 401 e

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Daniel Shahaf
Philip Martin wrote on Wed, May 16, 2012 at 18:39:37 +0100: > The issue that worries me the most is the traffic issue: > > http://subversion.tigris.org/issues/show_bug.cgi?id=3980 Your recent figures on that issue show a +122% increase in traffic. Do we know what the worst case increase is? For

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Philip Martin
Greg Stein writes: > We have some issues filed against ra_serf. Which of them should be > considered as blockers? I still use neon because it's inconvenient that serf hangs every now and then over https: http://subversion.tigris.org/issues/show_bug.cgi?id=3981 The issue that worries me the mos

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Justin Erenkrantz
On Wed, May 16, 2012 at 3:46 AM, Greg Stein wrote: > Short query: is this possible? Given that the last major blocker/complaint that I was aware of had to do with the C-L/chunking on the request side and that's been resolved now in trunk (serf + svn), I think it's possible without any user-visibl

Re: svn commit: r1339262 - in /subversion/trunk: ./ build/generator/ build/win32/ notes/ subversion/svnmucc/ subversion/tests/cmdline/svntest/ tools/client-side/svnmucc/ tools/dev/windows-build/

2012-05-16 Thread C. Michael Pilato
On 05/16/2012 12:57 PM, Daniel Shahaf wrote: > cmpil...@apache.org wrote on Wed, May 16, 2012 at 16:44:47 -: >> Author: cmpilato >> Date: Wed May 16 16:44:47 2012 >> New Revision: 1339262 >> >> URL: http://svn.apache.org/viewvc?rev=1339262&view=rev >> Log: >> Finish issue #3308 ("Promote 'svnmu

Re: svn commit: r1339262 - in /subversion/trunk: ./ build/generator/ build/win32/ notes/ subversion/svnmucc/ subversion/tests/cmdline/svntest/ tools/client-side/svnmucc/ tools/dev/windows-build/

2012-05-16 Thread Daniel Shahaf
cmpil...@apache.org wrote on Wed, May 16, 2012 at 16:44:47 -: > Author: cmpilato > Date: Wed May 16 16:44:47 2012 > New Revision: 1339262 > > URL: http://svn.apache.org/viewvc?rev=1339262&view=rev > Log: > Finish issue #3308 ("Promote 'svnmucc' tool (or functionality) into a > fully supported

Re: ISSUE: "To many open files" not being logged by master server when sync fails.

2012-05-16 Thread Philip Martin
Kenneth Miles writes: > On 04/05/12 20:09, Philip Martin wrote: >> Kenneth Miles writes: >> >> I'm not sure if a specific revision is causing the issue. But it always fails replaying on a certain revision number as seen in the stack trace. It is definitely opening mu

Trunk checkout fails with serf but not neon

2012-05-16 Thread Mark Phippard
I cannot recreate this with the Apache repository, but with a local 1.7.5 server and current trunk client I get this: $ svn co http://cu121.cloud.sp.collab.net/svn/desktop desktop --username=markphip --depth=immediates subversion/svn/checkout-cmd.c:168: (apr_err=130003) subversion/libsvn_client/ch

Re: new conflict callback API

2012-05-16 Thread Stefan Sperling
On Wed, May 16, 2012 at 02:52:46PM +, Markus Schaber wrote: > Hmm, this may lead to _very_ special strategies implemented in the core. > > Like when a CoDeSys Device plugged into a Slot conflicts, and a neighbor slot > is empty. > > On the SVN Working copy, this looks like (irrelevant files

AW: new conflict callback API

2012-05-16 Thread Markus Schaber
Hi, Stefan, Von: Stefan Sperling [mailto:s...@elego.de] > > On Wed, May 16, 2012 at 02:52:06PM +0100, Julian Foad wrote: > > OK, I appreciate that issue. I see two ways the client lib can help: > > > > 1. providing a set of client-lib APIs to perform the most commonly > > wanted resolutions; > >

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread C. Michael Pilato
On 05/16/2012 10:13 AM, Greg Stein wrote: > On Wed, May 16, 2012 at 9:43 AM, C. Michael Pilato > wrote: >> but: How hard would it be to temporarily maintain two commit paths -- one >> that drives an Ev2 editor, and one that drives Ev1? The call to >> svn_ra_get_commit_editorN() would return NOT

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 9:46 AM, Ivan Zhakov wrote: > On Wed, May 16, 2012 at 5:15 PM, C. Michael Pilato > wrote: >> On 05/16/2012 06:46 AM, Greg Stein wrote: >>> Short query: is this possible? >> >> I know of no convincing reason why we cannot someday delete libsvn_ra_neon. >>  I am very much i

Re: new conflict callback API

2012-05-16 Thread Stefan Sperling
On Wed, May 16, 2012 at 02:52:06PM +0100, Julian Foad wrote: > OK, I appreciate that issue.  I see two ways the client lib can help: > > 1. providing a set of client-lib APIs to perform the most commonly wanted > resolutions; > > 2. providing a set of (APIs? comments?) that suggest what set of p

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Greg Stein
On Wed, May 16, 2012 at 9:43 AM, C. Michael Pilato wrote: > On 05/16/2012 09:33 AM, Hyrum K Wright wrote: >> On Wed, May 16, 2012 at 8:15 AM, C. Michael Pilato >> wrote: >>> ... >>> What to do about the commit Ev2 stuff?  Perhaps you or Hyrum can help us >>> understand the scope of the performan

Re: new conflict callback API

2012-05-16 Thread Julian Foad
- Original Message - > From: Stefan Sperling > To: Julian Foad > Cc: "dev@subversion.apache.org" ; Bert Huijben > > Sent: Wednesday, 16 May 2012, 14:07 > Subject: Re: new conflict callback API > > On Wed, May 16, 2012 at 01:55:01PM +0100, Julian Foad wrote: >> I think the way to a

Re: new conflict callback API

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 8:55 AM, Julian Foad wrote: > Stefan Sperling wrote: > >> Bert Huijben wrote: >>>  Note that the simple view of this model doesn't match GUI clients >>>  expectations. >>> >>>  GUI's can stay inside a callback and keep the gui functional for other >>>  operations, so callba

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Ivan Zhakov
On Wed, May 16, 2012 at 5:15 PM, C. Michael Pilato wrote: > On 05/16/2012 06:46 AM, Greg Stein wrote: >> Short query: is this possible? > > I know of no convincing reason why we cannot someday delete libsvn_ra_neon. >  I am very much in favor of getting back to a single DAV provider.  I > believe

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread C. Michael Pilato
On 05/16/2012 09:33 AM, Hyrum K Wright wrote: > On Wed, May 16, 2012 at 8:15 AM, C. Michael Pilato > wrote: >> ... >> What to do about the commit Ev2 stuff? Perhaps you or Hyrum can help us >> understand the scope of the performance cost paid by employing editor shims? > > The primary performan

AW: new conflict callback API

2012-05-16 Thread Markus Schaber
Hi, Von: Julian Foad [mailto:julianf...@btopenworld.com] > Stefan Sperling wrote: > > Bert Huijben wrote: > > So you mean that instead of calling into a GUI client via a set of > > callbacks, the client library should provide several API functions > > that GUI clients can use to gather conflict in

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Hyrum K Wright
On Wed, May 16, 2012 at 8:15 AM, C. Michael Pilato wrote: >... > What to do about the commit Ev2 stuff?  Perhaps you or Hyrum can help us > understand the scope of the performance cost paid by employing editor shims? The primary performance cost paid by Ev2 is that the entire edit is queued up du

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Mark Phippard
On Wed, May 16, 2012 at 9:25 AM, Greg Stein wrote: > [avoiding responding, in favor of collecting feedback, but one item...] > > On Wed, May 16, 2012 at 9:15 AM, C. Michael Pilato > wrote: >>... >> Having not reviewed the issues myself, I can only submit the following >> litmus test of ra_serf r

Re: svn commit: r1338810 - /subversion/trunk/subversion/libsvn_repos/replay.c

2012-05-16 Thread C. Michael Pilato
On 05/15/2012 03:50 PM, Daniel Shahaf wrote: >> } >> } >> >> - /* Handle property modifications. */ >>if (! do_delete || do_add) >> { >> - if (change->prop_mod) >> + /* Handle property modifications. >> + >> + Note that this needs to happen in the "copy f

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread Greg Stein
[avoiding responding, in favor of collecting feedback, but one item...] On Wed, May 16, 2012 at 9:15 AM, C. Michael Pilato wrote: >... > Having not reviewed the issues myself, I can only submit the following > litmus test of ra_serf readiness:  can it do everything that our current > user base ex

Re: [DISCUSS] delete ra_neon

2012-05-16 Thread C. Michael Pilato
On 05/16/2012 06:46 AM, Greg Stein wrote: > Short query: is this possible? I know of no convincing reason why we cannot someday delete libsvn_ra_neon. I am very much in favor of getting back to a single DAV provider. I believe that ra_serf offers us the best path forward along those lines, not b

Re: new conflict callback API

2012-05-16 Thread Stefan Sperling
On Wed, May 16, 2012 at 01:55:01PM +0100, Julian Foad wrote: > I think the way to avoid "offering options the client library is not prepared > to handle" is that the application should resolve a conflict by calling a > series of (mostly) normal client operations, rather than by telling the > cli

Re: new conflict callback API

2012-05-16 Thread Julian Foad
Stefan Sperling wrote: > Bert Huijben wrote: >> Note that the simple view of this model doesn't match GUI clients >> expectations. >> >> GUI's can stay inside a callback and keep the gui functional for other >> operations, so callbacks can only be handled by application-modal dialogs >> (You

Re: new conflict callback API

2012-05-16 Thread Stefan Sperling
On Wed, May 16, 2012 at 01:59:43PM +0200, Bert Huijben wrote: > Note that the simple view of this model doesn't match GUI clients > expectations. > > GUI's can stay inside a callback and keep the gui functional for other > operations, so callbacks can only be handled by application-modal dialogs >

RE: new conflict callback API

2012-05-16 Thread Bert Huijben
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: woensdag 16 mei 2012 13:25 > To: dev@subversion.apache.org > Subject: RFC: new conflict callback API > > The current conflict callback API passes a svn_wc_conflict_description2_t > struct to the callback, and all

RFC: new conflict callback API

2012-05-16 Thread Stefan Sperling
The current conflict callback API passes a svn_wc_conflict_description2_t struct to the callback, and allows the callback to freely return any possible value of svn_wc_conflict_choice_t as a result. This works fine for text and prop conflicts, which is what this API was designed for. However, if w

[DISCUSS] delete ra_neon

2012-05-16 Thread Greg Stein
Short query: is this possible? Long query: Hyrum has been doing some heavy lifting on moving our code to Ev2 for commits. That work can be merged soonish, but a strong argument can be made for "only when all RA providers have an Ev2 commit editor" (because otherwise poor-perf shims are used). ra_