Juergen Schoenwaelder wrote:
On Fri, Jul 23, 2004 at 02:53:54PM +0200, Frank Strau? wrote:
If you have any concerns (or if you would like to see libsmi being managed with Subversion), please let me know.
No problem from my side - as long as I can use the subversion native protocol and do not have to use web dav and all this machinery in the middle. ;-)
I'm a little ashamed to say that :-), but I tend to prefer *not* to support the svn://, svn+ssh:// and file:// schemes. But of course there is a reason. A reason that is also problematic with CVS...
When the repository is accessed through system calls on the filesystem and their access control mechanism (user, group, file mode), it is not possible to control who is allowed to access which projects within a repository. (In CVS it was due to the CVSROOT/ stuff, in SVN all data sits in a single Berkeley DB.) The only alternative would be to create separate repositories per project and one UNIX group per repository and hoping not to exceed the OS' limit of groups per user. Furthermore, I'd like to safely exclude the eventuality that the repository is accessed via NFS, which could cause strange problems due to incompatible locking mechanisms.
Hence, I prefer to support http://svn.ibr.cs.tu-bs.de/svn for anonymous r/o access, and https://svn.ibr.cs.tu-bs.de/ for authenticated r/w access. On the server side, I have installed an Apache authentication module that is based on PAM/NIS, i.e., using the local users passwords, and an SVN specific access control module that allows a fine grained configuration of who is allowed to read and/or write which parts of the repository. On the client side, svn allows to either save security information in ~/.subversion/ and reuse it for subsequent access to the repository, or not to do so if you don't want to have your password residing in your filesystem (more or less in cleartext, I'm not sure yet sure).
So, could you live with that? :-)