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

Re: Light weight client question.

From: <cmpilato_at_collab.net>
Date: 2003-06-28 10:38:05 CEST

Ben Collins-Sussman <sussman@collab.net> writes:

> Ross Mark <rossm@controllingedge.com.au> writes:
> > I'm after a light weight version of the svn+http client. This client
> > would only allow checkout's and updates (switch too as it is just a
> > type of update). There is absolutely no need to do a checkin. Given
> > this case the problems that normally arise from having a working copy
> > and the original file should not be an issue since the original is
> > only needed for determining the delta on a checkin.
> The trick here is to somehow issue http requests to gather
> information, but not use libsvn_wc at all; no .svn/ directories to
> manage working copy metadata.
> If you just want a checkout of HEAD, you can practically do a
> recursive 'wget' on the repository URL. All you need to do is issue a
> bunch of GET requests with any old http client.

Unfortunately, bugs in mod_dav_svn might make this fail if you have
paths which contain HTML-unsafe characters (like ampersands and other
things typically represented by HTML character entities). But aside
from this problem, yeah, recursive GETs would work fine.

> If you want to be able to *update*, then something needs to record the
> exact revision you checked out. Your lightweight client would then
> send an http REPORT request with a short svn-specific xml body, and
> have to learn to parse the xml response which describes exactly which
> files need to be "fetched" (via GET) to update to HEAD.

...of course, since your lightweight client did a checkout without a
working copy, there's no information lying about with which to
generate this REPORT request. :-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 28 10:38:20 2003

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.