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

Re: First impressions...

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-01-25 20:54:45 CET

On Fri, Jan 25, 2002 at 10:33:03AM -0600, Eric M. Hopper wrote:
>...
> WebDAV? Why? Seems like adding a useless layer to me. Lets replace
> the very simple xinetd with a much more complex Apache, and add an extra
> superfluous protocol layer as well! OSes that make writing to a socket
> somehow different from doing any other kind of IO deserve to have it be
> complicated to port stuff to them. Luckily, you were farsighted enough
> to make this easy to change if someone gets irritated enough by it.

Here are some of the benefits of our choice of using WebDAV:

* builtin web browsing of the repository. for example, take a look at:
    http://svn.collab.net/repos/svn/trunk/HACKING
  (that's the HEAD right there; we also have URLs for every previous
   revision of every file)

* DAV-based browsing. use Web Folders or WebDrive or somesuch on your
  Windows box (or Windows XP's native DAV mounts) to browse the SVN
  repository with Windows Explorer. Mac OS X has builtin DAV server
  mounting. Nautilus has DAV capabilities. Then you have your Open Source
  tools such as cadaver, Goliath, etc.

* existing libraries. I couldn't even begin to count the number of HTTP
  tools and libraries available. If we had designed our own protocol, then
  we would have /none/ of those benefits. Heck, two HTTP library
  implementors (Joe Orton of Neon, and Daniel Stenberg of CURL) are regulars
  here. we wouldn't get that benefit. I've used Python's httplib (and a
  davlib of my own) to do a lot of testing of our server. No need to go and
  roll new protocol libraries.

* existing tools. one word: Ethereal :-) When we capture network traces,
  Ethereal already knows about HTTP. It's quite nice, but I know there are
  even better ones out there. but we also have other tools like squid and
  other (caching) proxies.

* and that point: caching proxy. Subversion will work great with caching
  proxies. there is no longer a need for specialized tools like "cvsup".
  just drop in a caching proxy, and you've already got your distributed
  read-only repository. that european dev team can just drop in the cache
  between them and the US server and their checkouts/updates will get cached
  for the benefit of the other team members. commits will flow through, back
  to the US-based server.

* sophisticated, broad authentication. we don't have to reimplement an
  authentication scheme for a new protocol. we can use all of the various
  schemes that have been defined for HTTP. ever look at CVS? ever see the "I
  Love You" or "I Hate You" lines? :-) that is all part of creating a new
  authentication scheme. but we get to use SSL and certificate-based auth if
  we want. Kerberos. NTLM. or even just simple Basic or Digest. and our
  users can come from text files, database, LDAP, or PAM. we don't have to
  reinvent the wheel cuz it is all available for Apache already.

* awesome network server. we don't have to worry about how to portably set
  TCP_CORK for optimal network packets. we don't have to worry about when
  sendfile() makes sense, or if it is available. we don't have to worry
  about dropped client connections, how to best use threads and processes to
  scale, request management, monitoring, logging, etc. Apache gives us all
  of that and a ton more. I *really* would not want to do that through
  xinetd. I mean... setting TCP_CORK on stdout? freaky :-)

* well-defined on-wire compression. we already have on-wire compression,
  similar to CVS's "-z#" switch. and we didn't do anything. the client
  library and server that we use just support it automatically for us.

* future interoperability with IDEs and other WebDAV/DeltaV clients. as
  DeltaV becomes more prevalent, IDEs could very well use it for source code
  management, and we'll be right there without needing to write some MS/SCC
  library to interface to the tool.

And that is just what I could think of off the top of my head. Give me some
time, and I could probably double the list :-)

Designing new wire protocols for sophisticated applications is a losing
proposition. I might not use HTTP/DAV/DeltaV between my computer and a
remote temperature sensing device, but for a source code management system?
Hell ya. :-)

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:37:00 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.