| |||||||||||
Subversion: The new-generation CVS (DevChannel)Subversion: The new-generation CVS (DevChannel)Posted May 29, 2004 0:30 UTC (Sat) by piman (subscriber, #8957)In reply to: Subversion: The new-generation CVS (DevChannel) by FarcePest Parent article: Subversion: The new-generation CVS (DevChannel) I think it's perfectly fair to call Apache a "back end" from the perspective of a software developer. It does manage authentication, path-based authorization, encryption, and browsing, all of which are traditionally back-end activities. svnserve is another back end. svn(1) is a front end. Maybe if you're developing a Subversion client, Apache is a front-end. But only a handful of people are doing that, and I suspect thousands or tens of thousands are using Subversion for something else.
(Log in to post comments)
Subversion: The new-generation CVS (DevChannel) Posted May 31, 2004 2:25 UTC (Mon) by lakeland (subscriber, #1157) [Link] Hm, no.I think the point is that apache _can_ manage all you say for svn, but apache is not the default any more. When I set up svn a couple months ago, I found it easiest to use ssh instead of apache. In fact, the docs I followed assume you want ssh, and just gave apache as an alternative. From my perspective, the dependency on apache is just as a library needed to compile the server.
Subversion: The new-generation CVS (DevChannel) Posted May 31, 2004 6:02 UTC (Mon) by piman (subscriber, #8957) [Link] Apache or svnserve is basically necessary if you want public repository access (which most projects do). They're also necessary if you want to restrict repository access on a per-directory basis, or don't want to hand out SSH accounts to anyone with commit access (which is generally a good idea).To get nontrivial collaboration out of SVN, you need svnserve or Apache.
Subversion: The new-generation CVS (DevChannel) Posted May 31, 2004 6:27 UTC (Mon) by lakeland (subscriber, #1157) [Link] Most open source projects want private access. But what about a group ofdevelopers working in a company? ssh is perfectly acceptable for that. Perhaps a huge company would need per-directory access control to a level not easily provided by chown/chmod. My point is that I think saying _most_ projects don't need svnserve. Most projects are written by one person or small companies.
Subversion: The new-generation CVS (DevChannel) Posted May 31, 2004 6:39 UTC (Mon) by piman (subscriber, #8957) [Link] Per-directory access control in Subversion is not available at all via chown/chmod.
Subversion: The new-generation CVS (DevChannel) Posted Jun 3, 2004 22:12 UTC (Thu) by brouhaha (subscriber, #1698) [Link] Per-directory access control in Subversion is not available at all via chown/chmod.Actually that can be done, if you use svnserve tunnelled through SSH. I had my repositories set up that way for about six months. It works because the svnserve process invoked on the user's behalf runs under his or her user ID. The preferred approach to access control with Subversion seems to be the use of hook scripts. Some examples hook scripts are provided; they don't implement per-directory access control, but it would not be difficult to set up using the example scripts as a base. In fact, you could easily implement per-file access control, or even more complex policies such aIP address or date restrictions, or checking ACLs in a parallel directory structure.
Subversion: The new-generation CVS (DevChannel) Posted Jun 3, 2004 22:14 UTC (Thu) by brouhaha (subscriber, #1698) [Link] I should clarify that my mention of SSH wasn't really per-directory access control within a repository, which does require hook scripts. I meant that I used directory ownership to control access to multiple repositories on the same Subversion server, which is probably not what was wanted.But it is possible to do this using hook scripts, as I described.
Subversion: The new-generation CVS (DevChannel) Posted Jun 1, 2004 9:38 UTC (Tue) by mkching (guest, #21009) [Link] I run a Subversion hosting service (wush.net) and there is no way I could offer anything beyond the most trivial of setups without using Apache as the backend. SSH may be the easiest for one developer, but the gap quickly closes as you do more. Even small companies benefit from the Apache setup. A lot of the small organizations like to use WebDAV for checkouts (and checkins using autoversioning) from anywhere, something you cannot do without Apache. In addition, many people like to use viewsvn, which does not cooperate easily with user-owned repositories since it will be running as www. There are lots of other setups that you just can't do without using Apache and not just esoteric ones.
|
|||||||||||