Weekly Edition
Return to the Press page
| |||||||||||
Subversion: The new-generation CVS (DevChannel)
OSDN DevChannel looks
at Subversion. "Subversion is tightly integrated with the Apache
Web server, 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. This configuration is
very Apache-specific, so we will not address any details here. As an
alternative, Subversion offers a lightweight solution named svnserve which
uses a proprietary protocol running over TCP. For our simple needs svnserve
will do."
(Log in to post comments)
Subversion: The new-generation CVS (DevChannel) Posted May 28, 2004 21:25 UTC (Fri) by FarcePest (guest, #3065) [Link] 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.
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.
Subversion: The new-generation CVS (DevChannel) Posted May 28, 2004 22:14 UTC (Fri) by andre (guest, #11559) [Link] > Berkeley/Sleepycat DB-4 is the storage back end, though this is intended> to be pluggable in the long run. Do you have more details on that (like how long would the long run be :)? I would love to switch to subversion, but I've already had enough problems with BerkeleyDB on other software...
Subversion: The new-generation CVS (DevChannel) Posted May 30, 2004 6:25 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] Hi good news for you the cvs version already implements this. check it out
Subversion: The new-generation CVS (DevChannel) Posted May 31, 2004 5:59 UTC (Mon) by piman (subscriber, #8957) [Link] I assume you mean, the SVN version. :)
Subversion: The new-generation CVS (DevChannel) Posted May 29, 2004 0:40 UTC (Sat) by maney (subscriber, #12630) [Link] If you already know CVS, then you will have very little trouble adjusting to Subversion.Oh yeah. My biggest problem so far has been extinguishing the reflexes connected to the ugly hacks I had to use with CVS to do simple things. The change from per-file version numbers to per-changeset numbering is a breath of fresh air, of course. I was stunned when I discovered how easy it was to setup an svn+sshp: method to access repositories on the box that hides its SSH access behind a non-standard port (which, come to think of it, probably isn't necessary any longer... except for all the separate places that setup is wired into). But there is a downside. Now that it's easy to move files and directories around, and doing so leaves history intact, I have little excuse to put off some large-scale refactoring that's been too obviously painful to do under CVS. :-)
Kudos to Watson for the original Woody backport of the package and to Conrad for ongoing maintenance, without which it would have been much too easy to put off diving into subversion on the flimsy grounds of the pain of installing it on many of the machines I work on regularly.
Subversion: The new-generation CVS (DevChannel) Posted May 29, 2004 17:55 UTC (Sat) by lonely_bear (subscriber, #2726) [Link] I would like to suggest GNU ARCH as an alternative. Give it a try.http://www.gnu.org/software/gnu-arch/
Subversion: The new-generation CVS (DevChannel) Posted May 30, 2004 21:13 UTC (Sun) by riel (guest, #3142) [Link] Agreed. BK, Arch and Monotone all seem to be revision control systems designed to work the way open source development is done - distributed.In contrast, CVS seems to be modeled around a proprietary way of doing software development, with few developers having access to the revision control system and even fewer allowed to participate in it. Subversion appears to be a better implementation of the (IMHO flawed) CVS model.
Subversion: The new-generation CVS (DevChannel) Posted May 31, 2004 1:23 UTC (Mon) by gdt (subscriber, #6284) [Link] Subversion never claimed to be more than a better CVS. That was the project goal. They've succeeded in meeting that, although taking much longer than anyone expected. I've attempted to configure a secure CVS server for updates with anonymous access for reads and been stunned that CVS can't do this without a huge amount of effort (or simply giving up and having two rsynced repositories). So I'm glad to see an alternative to CVS. You also write of open source development as if it were a monolithic design methodology. This is hardly so; projects vary widely in their methodologies. For example, Samba's "core team" approach might well only see the costs of distributed version control without seeing the benefits. I've tried arch. A nice idea, but too many limitations for deployment at this time. I do get frustrated with the "editor wars" aspects of configuration control. Especially since the most useful parts of configuration control are the analysis add-ins, something no open source system seems to have much of. To pick a simple task, rebuild the project each night, e-mailing owners and those that modified failing code with compile and regression test errors. Or, tell me which modules don't have a regression test. Or, who checks in the greatest proportion of failing code. Or, which module has had the most field issues raised against it.
Subversion: The new-generation CVS (DevChannel) Posted May 31, 2004 6:21 UTC (Mon) by piman (subscriber, #8957) [Link] You have inspired me to see if I can hack together a Python (or shell) script to automate regression testing in Subversion. :)
Subversion: The new-generation CVS (DevChannel) Posted May 31, 2004 6:14 UTC (Mon) by piman (subscriber, #8957) [Link] Though open source development involves many contributors, it is rarely done distributedly. Almost always there is an official tree, and no others. In rare cases with lots of features in testing, which might conflict with each other, development has actually been done in a distributed manner; this is how the kernel works. But this behavior is rare.Now, you might say that this is because CVS is so prevalent, and you might be right. But projects were managed like this before CVS, too, and projects that don't use CVS (there still are some!) also usually work this way. You might also say that although most projects don't use this model, they should. You might be right there, too; but only time will tell on that count. I personally don't think it will have many advantages for most projects.
Subversion: The new-generation CVS (DevChannel) Posted May 31, 2004 9:45 UTC (Mon) by josander (guest, #19785) [Link] > Agreed. BK, Arch and Monotone all seem to be revision control> systems designed to work the way open source development is > done - distributed Distributed? Glad you said it (thanks)! You will find some Subversion based options from the link below (and don't forget to read the "Dispelling Subversion FUD" doc while you're there): http://subversion.tigris.org/project_links.html Jostein Chr. Andersen
Subversion: The new-generation CVS (DevChannel) Posted Jun 1, 2004 18:07 UTC (Tue) by dvrabel (subscriber, #9500) [Link] Which revision control systems a project uses has little to do with how open its development is.
No-one expects the GNU arch citation Posted Jun 1, 2004 12:40 UTC (Tue) by pdc (subscriber, #1353) [Link] Yes, we know that GNU 'arch' exists as well. We know because every single article about a source-code control system gets a comment citing GNU 'arch', which in turn grows a thread irrelevant to the article at hand.Can I suggest that LWN add a disclaimer to all articles mentioning Subversion et al. to the effect of "There is also a system called GNU arch"?
No-one expects the GNU arch citation Posted Jun 3, 2004 7:27 UTC (Thu) by Peter (guest, #1127) [Link] There are just certain pairings that, in popular media and talkback forums, are never allowed to remain separate. When was the last time you heard about "Linux on the desktop" without prominent mention of Microsoft? Has there ever been anything published about Gnome or KDE - written by a third party, outside the actual Gnome or KDE camps - that did not mention the other? Have you ever seen an article about open source software beyond the Linux kernel, that did not mention Apache?
Subversion: The new-generation CVS (DevChannel) Posted Jun 16, 2004 21:54 UTC (Wed) by Aaron (guest, #22362) [Link] Just thought I would point out that two new Subversion community resource sites have just recently opened. These might make a good reference for anyone getting started with Subversion:Subversion Forums: http://www.svnforum.org Subversion Wiki: http://www.subversionary.org
|
|||||||||||