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

Re: Four failing tests on trunk with ra_serf.

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 13 Nov 2008 20:13:06 -0500

On Thu, Nov 13, 2008 at 7:52 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Julian Foad wrote:
>> Would you say, then, that we've reached the point where we should all be
>> treating Serf as part of the product and paying it as much attention as
>> Neon/svn/local? One thing we should do to cement this is ask Lieven to
>> get the Serf build-bot running on par with the others, not just the
>> present once a day.
> Frankly, serf won't be on par with Neon until it's the default dav ra method,
> and it gets more everyday usage.

There has got to be a better way than that. With a product as mature
as Subversion we cannot just switch users to Serf if we are not highly
confident it is going to behave as well as Neon.

> Oh, and maintaining two dav ra layers is the sure way to madness. If/once
> ra_serf is the default, let's just nuke ra_neon and be done with it.

This makes sense, but I'd like to see someone do a feature comparison
of what each can do before we just nuke neon. I know that ra_serf has
added support for a lot of the same authentication mechanisms that
Neon supports, but I think Neon still supports some that Serf does
not. For example, I know there are people that have deployed Neon in
a Smart Card environment with PKCS#11 certificates. Can we just take
that away from those users? Has Serf added this?

Another issue that has been raised in the past is that ra_serf does
not honor the depth-first editor API contract. That would need to be
fixed as part of becoming "official".

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-14 02:13:20 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.