| |||||||||||
|
| |||||||||||
Subversion: The new-generation CVS (DevChannel)Subversion: The new-generation CVS (DevChannel)Posted May 28, 2004 21:25 UTC (Fri) by FarcePest (guest, #3065)Parent article: Subversion: The new-generation CVS (DevChannel)
Subversion is tightly integrated with the Apache Web server, This is misleading. Subversion uses the Apache Portable Runtime (APR) library, which is analogous to GTK+'s glib, or Mozilla NSPR. which allows it to provide a robust back end for repositories in areas such as authentication, path-based authorization, and browsing, although support is provided by an external module. Berkeley/Sleepycat DB-4 is the storage back end, though this is intended to be pluggable in the long run. Apache, along with mod_dav and mod_dav_svn, is one the front ends, with the aforementioned svnserve being another front end. Better links: If you already know CVS, then you will have very little trouble adjusting to Subversion. Command line usage is very similar. The main difference is there are no explicit tags and branches. Instead of CVS's per-file revisions, each snapshot of the tree has it's own revision number. When you commit, you get a new snapshot with an incremented revision number (just an increasing integer). You can implement branches or tags just by copying the trunk (or another branch or tag) to another directory with svn copy. This only makes "cheap copies" of files; think of hard links. Usually you create branch, tags, and trunk directories in the root of your project, and then make copies into branch and tags.
(Log in to post comments)
Subversion: The new-generation CVS (DevChannel) Posted May 29, 2004 0:30 UTC (Sat) by piman (subscriber, #8957) [Link] 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.
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.
|
|||||||||||