Thanks for your help, and my apologies such newbitude. Some
> First, there's no such thing as an [auth] section in svnserve.conf.
> You're mixing it up with a config section from the *client* side
> ~/.subversion/servers file.
Hmmm... I'm sure you're right, but section 3.2.4 of the tortoise docs,
"Authentication with svnserve", talks about the "conf/svnserve.conf file in
your repository directory. This file controls the configuration of the
Am I confused?
> Second, that file is only ever used by the 'svnserve' server
> program. That's it. Not apache, and certainly not direct (file:///)
I knew it wasn't used by apache, but didn't realize that file:/// access
wasn't served by svnserve. That is clear from the architecture diagram in
the docs though; my bad.
Is it possible to shut down all access except through apache (leaving aside
direct edits of the files in the repo itself)? In that configuration, I
could use an http url locally, and also allow others access when I want to,
both through a single set of access controls in apache. Make sense?
> Third, there's no such thing as access control when your client
> touches the repository directly via file:///. It's meaningless; who
> would enforce it? Even if the client saw some variables that meant,
> "don't change things", the user could always open the repository
> files directly in a text editor and and start mucking with things.
> In other words, the only permissioning going on are operating-system
> perms on the database files. That's it. Set the ACLs appropriately,
> and let your OS do the work.
I'm aware that with the repository on the same machine, I could just edit
files in the repository directly. But that would defeat the purpose of
having scm at all. It's in my best interest to treat some of the files on my
own disk as if the repository was elsewhere.
Thanks again for your help, very much appreciated,
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat May 21 17:03:22 2005