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

Re: [VOTE]: Default http-client for 1.7 Serf or Neon

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Fri, 5 Aug 2011 08:39:55 +0200

On Fri, Aug 5, 2011 at 06:26, Greg Stein <gstein_at_gmail.com> wrote:
> On Aug 4, 2011 11:43 PM, "Branko Čibej" <brane_at_e-reka.si> wrote:
>>...
>
>> Speaking of politicking, I don't see any technical explanation for
>> Greg's veto in the 1.7.x STATUS, which causes me to wonder why anyone is
>> treating it as valid in the first place.
>
> The change goes against our previously-stated direction. Using Neon holds us
> back from future improvements (discussed across many threads), so I consider
> such a change a regression in our codebase.
>
> There are no registered and actionable bugs. We made serf the default
> shortly after 1.6.x was branched. It has been the default for two+ years.
> Changing the default does not help in our project's intended direction, nor
> indication that we would avoid this same discussion next time around. This
> is the time to move forward, as we have done with so many other moving parts
> of this project.

The default for two+ years, yes. But the default in a dev version,
with mostly no companies using it. So the test audience was very very
small. I had TSVN nightly builds available the whole time, and it's
only now with the beta that a few people are trying it out in their
company environment. And now I'm getting reports of big problems.

Example problem (one that I could actually pinpoint):
User tried a big merge
Merge failed every time, but every time at a different point in the
merge process
Switching to neon solved the problem

Asked the user to retry with serf, failed again.
Several emails later I found that their firewall software would start
blocking TSVN from accessing the repository. Disabling the firewall
made serf work too.
I have no idea why the firewall would block only serf requests and not
neon, but that's what we found.

Other problems reported with serf were related to SSPI authentication
- usually we got that working somehow with a lot of tweaking (trial &
error) of the server setup. --> Neon works, serf does not without
changing the server setup.

Both these problems are with serf, even though it isn't a bug in serf
(at least in case of the firewall, not sure about SSPI).
Does this indicate that serf is unstable and not ready? No, definitely not.

But for users and sysadmins, that doesn't matter at all. They want SVN
and TSVN to work, without having to disable firewalls (will never,
ever happen - they rather stick with 1.6 or drop SVN completely) or
tweak their server setup.

Since I don't want to be killed by sysadmins after the TSVN release,
I'm sticking with neon.

Stefan

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
Received on 2011-08-05 08:41:10 CEST

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.