[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: revision 50 - trunk/subversion/libsvn_ra_dav

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-09-06 00:47:19 CEST

On Wed, Sep 05, 2001 at 03:27:46PM -0500, Ben Collins-Sussman wrote:
> joe@tigris.org writes:
> > Use a second ne_session for GET requests so updates work.
> >
>
> Thank you!!
>
> Thank you!!
>
> Thank you!!
>
> Greg may not approve of this solution, but heck. I just updated my
> working copy to revision 1, and then back to 50! Mike did something
> similar, and didn't lose any of his four locally-modified files
> either.
>
> This is so great. I wonder if we can close issue 481. Better let
> Greg decide that.

Nope. As I mentioned over AIM, and described yesterday. I believe the proper
solution is to avoid opening two TCP sessions. For small updates, that will
be more efficient from a network standpoint (TCP-open over a modem
connection can be a bit doggy).

Efficient resource use from a system standpoint (client, network, and
server) is to use the local disk.

There is also the problem of session timeouts, as Joe mentioned.

In the future, we will also want to defer asking for username/password until
the server actually requests it. (anonymous checkouts should not require a
user/pass at the cmdline; thus, we should wait) To wait until the server
asks for it implies that we install a callback on the session. If you have a
restricted read server, then you're going to get queried for *each* session.
If you're using SSL, then you must do a session negotiation *twice*.

Joe's scheme is great for now, especially because I won't be able to fix
this until at least next week (leaving for Seattle tomorrow). But the long
run is to buffer in memory, and use the disk when memory gets too large.

So yes: the bug should stay open.

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
Received on Sat Oct 21 14:36:40 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.