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

Re: clients not supporting http?

From: David Weintraub <qazwart_at_gmail.com>
Date: Fri, 9 Jul 2010 00:07:06 -0500

On Thu, Jul 8, 2010 at 6:05 AM, Jason Aubrey <aubreyja_at_gmail.com> wrote:
> Hi All,
>
> I recently set up svn over http for a project I'm involved with. One
> user made the following complaints:
>
> (1) Some svn clients do not support the http protocol.  This
> is a common occurrence when a user builds svn from source.

Yes and no. Almost every binary available supports the HTTP protocol.
I would even go so far as to say they all do, but somewhere is an
obscure client (maybe for some Thuderbird Basic OS system) that
doesn't.

A much more likely occurrence is that someone builds their own binary
and doesn't have the neon and APR libraries needed for building with
the HTTP protocol. That binary would not support HTTP. However, you
can get pre-build binaries for almost every single OS you can name.
There should be no reason why a developer needs to build their own.

Your developer can go to http://www.sunfreeware.com to get a
Subversion client that uses the HTTP protocol for his Solaris machine.

> (2) When i attempted to download a single-file,
> svn complained that the file name was not a directory
> name and rejected the request.

Subversion only allows you to check out directories. You can use the
"svn cat" command to get single files, but if you're doing a checkout,
you need to checkout a directory.

NOTE: You can use the --depth=empty switch to checkout a directory
with no files in it, then do an "svn update <fileName>" to get the
single file you want. I discourage developers from doing this because
what they're doing is making a change without any testing. That is a
no-no.

-- 
David Weintraub
qazwart_at_gmail.com
Received on 2010-07-09 07:08:47 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.