You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2001/08/31 21:08:51 UTC

more handy post-M3 tips

* We still can't checkout arbitrary revisions over dav (iz #411).
  However, you can somewhat work around this problem by doing 'svn up
  -r N' on your working copy.  This *does* seem to work over dav.

* Issue 472 may get in your way:  Karl and I have been experimenting,
  and we're noticing that updates which include a large number of
  files somehow cause Neon to freak out.  

  For example, if my working copy is at rev. 16, I can easily downdate
  to revision 14.  But if I try to go from 16->10, it's too much, and
  I see the error again.  So we can update in small steps.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: more handy post-M3 tips

Posted by Ben Collins-Sussman <su...@collab.net>.

Joe Orton <jo...@manyfish.co.uk> writes:

> Anyway, I might try and implement this, because I can't update my
> working copy until this bug is fixed! :) See how it goes...

What, you don't like re-checking out your working copy every time
there's a commit?  :-)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: more handy post-M3 tips

Posted by Joe Orton <jo...@manyfish.co.uk>.

On Tue, Sep 04, 2001 at 06:42:32PM +0200, Branko ï¿½ibej wrote:
> Greg Stein wrote:
> 
> >Hoo boy... this is going to be an ugly one to fix. The cheap way is to open
> >a second session, but I don't like that one at all.
> >
> Um. What's wrong with opening a second session? Use one for reading the 
> REPORT, and another for all the GETs, PROPFINDs and whatnot. That means 
> you always use two, not 1+N sessions, right?

Yes, fixed at two sessions. I think the worst thing is that the first
session will be blocked while the second session does its thing. Imagine
session 1 does the REPORT, then half way through reading the response,
we have to GET a 200Mb document. By the time the client has finished
that, the server may have timed out the REPORT request and aborted that
connection.

Maybe that would be okay, if the REPORT is then restarted correctly, and
doesn't have to do the 200Mb GET again. I guess that would work.

Each session would have to renegotiate authentication, which might be an
issue.

Anyway, I might try and implement this, because I can't update my
working copy until this bug is fixed! :) See how it goes...

joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: DAV update problem (was: more handy post-M3 tips)

Posted by Greg Stein <gs...@lyra.org>.

On Tue, Sep 04, 2001 at 06:42:32PM +0200, Branko ï¿½ibej wrote:
> Greg Stein wrote:
> >Hoo boy... this is going to be an ugly one to fix. The cheap way is to open
> >a second session, but I don't like that one at all.
>
> Um. What's wrong with opening a second session? Use one for reading the 
> REPORT, and another for all the GETs, PROPFINDs and whatnot. That means 
> you always use two, not 1+N sessions, right?

For small updates, that second connection is relatively expensive.

Joe also had excellent points about the timeouts and the authentication,
both good reasons for why I didn't feel two sessions was a good idea.

> > Buffering in memory could be impossible for a large update.
>
> Absolutely. It would also violate our "streaminess" promise. (A promise 
> we aren't keeping right now, though.)
> 
> >Setting and abandonment threshold isn't all that attractive either...
>
> "Update abourted because there are too many changes in the repository." 
> Brrr.

Right and right.

I believe the proper approach is to buffer X amount of data, then fall off
to temporary file. Replay those instructions to fetch the information.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: more handy post-M3 tips

Posted by Branko Čibej <br...@xbc.nu>.

Greg Stein wrote:

>Hoo boy... this is going to be an ugly one to fix. The cheap way is to open
>a second session, but I don't like that one at all.
>
Um. What's wrong with opening a second session? Use one for reading the 
REPORT, and another for all the GETs, PROPFINDs and whatnot. That means 
you always use two, not 1+N sessions, right?

> Buffering in memory could be impossible for a large update.
>
Absolutely. It would also violate our "streaminess" promise. (A promise 
we aren't keeping right now, though.)

>Setting and abandonment threshold isn't all that attractive either...
>
"Update abourted because there are too many changes in the repository." 
Brrr.


-- 
Brane ďż˝ibej   <br...@xbc.nu>            http://www.xbc.nu/brane/




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: more handy post-M3 tips

Posted by Greg Stein <gs...@lyra.org>.

On Mon, Sep 03, 2001 at 10:02:20PM +0100, Joe Orton wrote:
>...
> the client does a REPORT with body
> 
> <S:update-report xmlns:S="svn:">
> <S:entry rev="29"></S:entry>
> <S:missing>notes</S:missing>
> </S:update-report>
> 
> but then half way through reading the response body, starts a GET using
> the same session! (an assert() in neon somewhere would have made that
> easier to diagnose, hmmmm)

Eek! That isn't good at all. Thanks for the pointer on that one...

Hmm. Basic design flaw in the update processing. We process the XML and
attempt to do the operations during the scan (rather than buffer all
instructions in memory, then execute). But (of course) we cannot do a GET or
PROPFIND or anything like that because we're still processing the REPORT
body.

I bet the only way it happens to work is if the REPORT body fits into the 8k
buffer that you use to read inside Neon. (it isn't going to be a single
network packet, cuz I'm assuming the inbound TCP buffers are already holding
the fully response, but that could certainly vary... so say 1500 to 8000
bytes of response)

Note that just having Neon pun a GET request while processing the REPORT
won't be the answer. That would eliminate the future chance of HTTP
pipelining (that is: sending one request while working on it). You just
can't *process* them out of order :-)

Hoo boy... this is going to be an ugly one to fix. The cheap way is to open
a second session, but I don't like that one at all. Buffering in memory
could be impossible for a large update. Setting and abandonment threshold
isn't all that attractive either...

Sigh.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: more handy post-M3 tips

Posted by Joe Orton <jo...@manyfish.co.uk>.

On Sat, Sep 01, 2001 at 06:27:37PM -0700, Greg Stein wrote:
> I'm guessing it is on the Apache side, rather than Neon. We *are* using the
> bleeding edge alpha Apache, after all :-)

Well I wasn't going to debug this after you said that but I think this 
may be an ra_dav issue if it is the same problem as:

$ svn co http://svn.collab.net/repos/svn
$ cd svn
$ rm -rf notes
$ svn up

the client does a REPORT with body

<S:update-report xmlns:S="svn:">
<S:entry rev="29"></S:entry>
<S:missing>notes</S:missing>
</S:update-report>

but then half way through reading the response body, starts a GET using
the same session! (an assert() in neon somewhere would have made that
easier to diagnose, hmmmm)

joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: more handy post-M3 tips

Posted by Greg Stein <gs...@lyra.org>.

On Sat, Sep 01, 2001 at 12:14:43AM +0100, Joe Orton wrote:
> On Fri, Aug 31, 2001 at 04:08:51PM -0500, Ben Collins-Sussman wrote:
> ...
> > * Issue 472 may get in your way:  Karl and I have been experimenting,
> >   and we're noticing that updates which include a large number of
> >   files somehow cause Neon to freak out.  
> 
> I saw the bug posted... "error reading chunked response body" was the
> error? That's a weird error to be getting, it means neon got confused
> parsing the response at HTTP level.  If you can reproduce this easily
> and can turn on neon debugging in your client by putting a call to
> 
>   ne_debug_init(stderr, NE_DBG_HTTP|NE_DBG_HTTPBODY);
> 
> somewhere which runs early in ra_dav/session.c it might give some useful
> clues.

I'm guessing it is on the Apache side, rather than Neon. We *are* using the
bleeding edge alpha Apache, after all :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: more handy post-M3 tips

Posted by Joe Orton <jo...@manyfish.co.uk>.

On Fri, Aug 31, 2001 at 04:08:51PM -0500, Ben Collins-Sussman wrote:
...
> * Issue 472 may get in your way:  Karl and I have been experimenting,
>   and we're noticing that updates which include a large number of
>   files somehow cause Neon to freak out.  

I saw the bug posted... "error reading chunked response body" was the
error? That's a weird error to be getting, it means neon got confused
parsing the response at HTTP level.  If you can reproduce this easily
and can turn on neon debugging in your client by putting a call to

  ne_debug_init(stderr, NE_DBG_HTTP|NE_DBG_HTTPBODY);

somewhere which runs early in ra_dav/session.c it might give some useful
clues.

joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org