Motivated by a note from Jürgen some weeks ago and by an article in a german computer magazine I have looked at Subversion and the quite comprehensive free documentation. I would like to switch the libsmi project from CVS to Subversion some time soon. Subversion has quite some real advantages compared to CVS (that I don't want to enumerate here). One thing is that it allows to access the repository via HTTP/DAV and HTTPS/DAV (besides others). The problem that occured most often when people wanted to have access to the libsmi source code were very strict firewalls (on the client side) that disallowed to access our CVS server.
If you have any concerns (or if you would like to see libsmi being managed with Subversion), please let me know.
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. ;-)
/js
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. ;-)
Of course, the svn+ssh:// scheme will also be supported for those with a local account.
Frank Strauß wrote:
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. ;-)
Of course, the svn+ssh:// scheme will also be supported for those with a local account.
Does that mean I will or will not be able to do
"svn co <some-url-or-other>"
?
Andrew Hood wrote:
Frank Strauß wrote:
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. ;-)
Of course, the svn+ssh:// scheme will also be supported for those with a local account.
Does that mean I will or will not be able to do
"svn co <some-url-or-other>"
Yes, this will be the way to checkout the "HEAD" of the package.
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? :-)
On Thu, Jul 29, 2004 at 06:29:08PM +0200, Frank Strau? wrote:
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.
I do not care about direct access to the files. But I do not understand the difference between talking SVN native to the svnserv daemon and talking webdav when it comes to access control. In both cases, I think access control is implement in one of the server processes.
Anyway, if you prefer to go with webdav, feel free to do. I will be able to adapt to it.
/js
On 29. Jul 2004, at 21:05, Juergen Schoenwaelder wrote:
On Thu, Jul 29, 2004 at 06:29:08PM +0200, Frank Strau? wrote:
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.
I do not care about direct access to the files. But I do not understand the difference between talking SVN native to the svnserv daemon and talking webdav when it comes to access control. In both cases, I think access control is implement in one of the server processes.
That is (theoretically) true for the administratively started svnserve daemon. But in case of the svn+ssh:// scheme, you start svnserve yourself in "tunnel mode" (-t) and svnserve assumes you have been "externally authenticated", so in that case you (your uid, and not an administratively chosen pseudo uid) need access to the repository.
Besides that, also the svnserve daemon (not in tunnel mode) has very limited access control. The documentation says:
Notice that svnserve only understands “blanket” access control. A user either has universal read/write access, universal read access, or no access. There is no detailed control over access to specific paths within the repository. For many projects and sites, this level of access control is more than adequate. However, if you need per-directory access control, you'll need to use Apache instead of svnserve as your server process.
So, what I think is missing is (a) a more fine grained access control mechanism for svnserve (preferably aligned with the apache modules access control), and (b) a way to install svnserve with the suid flag set, so that an svn user cannot access the whole repository database directly.
Anyway, if you prefer to go with webdav, feel free to do. I will be able to adapt to it.
Thanks.
participants (3)
-
Andrew Hood -
Frank Strauß -
Juergen Schoenwaelder