Infamous "Item is not readable" for svn log

[Nerius Landys]

I've found quite a few hits on Google regarding this subject, but I
have not found any elegant solutions to this problem.

I'm running SVN 1.6.9 (r901367) on FreeBSD (built from ports). I have
the svnserve daemon running. I'm trying to have some areas of my
repository be public (requiring no auth) and others be private
(requiring auth even for read access). So, lines in my svnserve.conf:

[general]
anon-access = read
auth-access = write
password-db = passwd
authz-db = authz
realm = Rambetter's Code Repository
[sasl]
use-sasl = false

Lines from passwd:

[users]
maj = fakepass
rambetter = fakepass

Lines from authz:

[aliases]
[groups]
[/]
rambetter = rw
* = r
[/repos/urt-playerdb]
rambetter = rw
* =
[/repos/ioUrT-server-4.1-supersecret]
maj = rw
* =
[/repos/jblockout]
rambetter = rw
* =
[/repos/ioquake3-server-1.36-rambetter]
rambetter = rw
* =
[/repos/ioUrT-server-4.1-rambetter]
rambetter = rw
* =

I cannot perform an "svn log" from the paths above that have the "* ="
(to restrict read access to the public). The error message is "svn:
Item is not readable" when I perform and "svn log" on these restricted
directories.

I know this is a common problem, but is there an elegant way to to
have both publicly readable and protected sections in the same
repository? I have done one thing in the past, which is to create a
user called "anonymous" with the empty password, and I tell the public
that to check out they type this:

svn checkout svn://daffy.nerius.com/repos/ioUrT-server-4.1
--username="anonymous" --password=""

... but this approach seems to be very clumsy.

Another solution that comes to mind is to start a whole new repository
with a separate svnserve daemon. How would I move over an entire
directory, all history included, if I were to do this?

Any other solutions?

[Bob Archer]

Did you attempt to pass your user credentials with the svn log command?

BOb

[Nerius Landys]

> Did you attempt to pass your user credentials with the svn log command?

Yes. There is a discussion regarding that here:
http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&viewType=browseAll&dsMessageId=173879

[Bob Archer]

I think setting up a guest username with no password is the easiest way to go. Baring that setting up apache for anon requests and svn for authenticated.

Seems like this shouldn't be so hard. Luckily we haven't needed path authorization yet.

BOb

[David Brodbeck]

On Feb 26, 2010, at 2:03 PM, Bob Archer wrote:
> I think setting up a guest username with no password is the easiest way to go.

That's how we're doing it on our repository. It's a little clumsy, but workable for our user population.

> Baring that setting up apache for anon requests and svn for authenticated.

That would also work. In our case we didn't really want the added complexity of Apache -- plus I was worried about user confusion. I already have a fair number of people who get http: and svn: mixed up from time to time. Having http: work in some situations but not others would just add to their perplexity.

--

David Brodbeck
System Administrator, Linguistics
University of Washington

[Nerius Landys]

>> I think setting up a guest username with no password is the easiest way to go.
>
> That's how we're doing it on our repository. It's a little clumsy, but workable for our user population.

You mean like I've done it? e.g.:

svn checkout svn://clanwtf.net/repos/ioUrT-server-4.1
--username=anonymous --password=""

Yes it is a little bit clumsy. I suggest that the SVN development
team address this issue.

[Johan Corveleyn]

On Fri, Feb 26, 2010 at 11:44 PM, David Brodbeck
<bro...@u.washington.edu> wrote:
> On Feb 26, 2010, at 2:03 PM, Bob Archer wrote:
>> Baring that setting up apache for anon requests and svn for authenticated.
>
> That would also work.  In our case we didn't really want the added complexity of Apache -- plus I was worried about user confusion.  I already have a fair number of people who get http: and svn: mixed up from time to time.  Having http: work in some situations but not others would just add to their perplexity.

You can also put them both on Apache, then there's not that much
confusion. That's how we do it: two Location blocks in Apache, both
backed by the same repository:
- http://svn.example.com/public_svn: the anonymously accessible one.
Goes over plain http, doesn't require authentication, but uses an
authz file to limit the paths that can be read.
- https://svn.example.com/svn: the "real" one for the developers. Goes
over https, requires authentication, and doesn't use an authz file
(allowing us to set "SVNPathAuthz off", which avoids the performance
loss normally associated with this setup).

Of course you can also have them both over https (it doesn't really
hurt the anonymous one).

Johan

[Nerius Landys]

> You can also put them both on Apache, then there's not that much
> confusion. That's how we do it: two Location blocks in Apache, both
> backed by the same repository:

Hrm, I was kind of hoping to avoid using httpd.