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

RE: Outdated ./subversion/libsvn_ra_serf/README

From: Bert Huijben <bert_at_qqmail.nl>
Date: Mon, 29 Feb 2016 11:25:34 +0100

> -----Original Message-----
> From: Stefan Fuhrmann [mailto:stefan2_at_apache.org]
> Sent: zondag 28 februari 2016 19:23
> To: dev <dev_at_subversion.apache.org>
> Subject: Outdated ./subversion/libsvn_ra_serf/README
>
> Hi all,
>
> The first section of that file looks like a keeper
> but most of the status info is horribly outdated
> and can probably be removed.
>
> Could someone with in-depth ra_serf knowledge please
> update the file?

This file was last updated in 2008, when our serf support was still very
experimental. The valuable pieces were already moved to the standard
locations.

I just removed the file in r1732848.
(Copied last version to the bottom of this mail for easy reference)

        Bert

[[
ra_serf status
==============

This library is an RA-layer implementation of a WebDAV client that uses
Serf.

Serf's homepage is at:
  http://code.google.com/p/serf/

The latest serf releases can be fetched at:
  http://code.google.com/p/serf/downloads/list

The latest serf sources can be fetched via SVN at:
  http://serf.googlecode.com/svn/trunk/

ra_serf can be enabled with the following configure flags:
 "--with-serf=/path/to/serf/install"
As Neon is currently Subversion's default RA DAV layer, you also need
to add "http-library = serf" to your ~/.subversion/servers file to
choose ra_serf at runtime. Alternately, you can build with only
support for ra_serf:
 "--without-neon --with-serf=/path/to/serf/install"

For more about how ra_serf/ra_neon talk WebDAV, consult
notes/webdav-protocol.

Working copies are interchangeable between ra_serf and ra_neon. (They both
use
the svn:wc:ra_dav:version-url property to store the latest revision of a
file.)

Completed tasks
---------------
- Core functionality complete (see regression test status below)
- https support (SSL)
- Basic authentication
- Update parallelization/pipelining (also for status/diff/switch/etc)
  - Does not require inline base64-encoding of content
  - 4 connections are open on an update (matches browser's default behavior)
  - 1 connection is used for the REPORT; 3 are used to fetch files & props
- Supports http-compression config flag
- SSL client and server certificates
- Proxy support
- NTLM/SSPI integration for Windows folks
- REPORT body buckets can now be read twice (#3212)

Regression test status
----------------------
All current regression tests are known to pass on:
  - Debian/AMD64 with APR 1.3.x
  - Mac OS X
  - Solaris
  - Windows

Things to do before the next release (1.6.x timeframe)
------------------------------------------------------

- Digest authentication

- Fix the editor API violation (TBC, #2932)

Nice to haves
-------------

- Move some of the code from ra_serf into serf. Serf doesn't have a very
  high-level API; but the code in util.c can go a long way towards that.

- Commit parallellization/pipelining
  - Determine how to use HTTP pipelining and multiple connections for commit
  - May need response from CHECKOUT to issue PUT/PROPPATCH
  - ra_svn has a custom commit pipelining that may be worth investigating
too

- Use PROPFIND Depth: 1 when we are adding a directory locally to skip
  fetching properties on files

- Discover server's keep-alive setting via OPTIONS requests and notify serf

- Fix bug in mod_dav_svn that omits remove-prop in the update-report when a
  lock is broken and send-all is false.
  (See upd_change_xxx_prop in mod_dav_svn/update.c)

- Fix bug in mod_dav_svn/mod_deflate that causes it to hold onto the entire
  REPORT response until it is completed. (This is why ra_serf doesn't
request
  gzip compression on the REPORT requests.)

- Remove remaining abort()s - ;-) aka add better debug logging

- Support for HTTP/1.0 pnly proxies.
]]
Received on 2016-02-29 11:25:56 CET

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.