On 2/17/06, Barney Boisvert <[EMAIL PROTECTED]> wrote: > > I have yet to see any of the problems you ran into -- I've implemented > > SVN for several clients with as many as 20 developers and we've > > accessed through svn with no lockups. You were using the filesystem > > backend (not BDB)? When I've seen lockups, it's always been BDB-based > > repositories (esp on Linux), which is somewhat deprecated. > > The problem lies in the way svnserve operates. It's not a > client-server model, it's a direct access method (basically identical > to file:/// urls, just with the ability to access across the network).
I'm not sure this is 100% accurate -- one of the design goals of SVN was to have an abstract network layer for allowing multiple ways to access the repository. Thus the svnserver and apache/mod_dav_svn options. > With FSFS, the backend now allows svnserv's problems to not cause > issues, but it doesn't change the fact that it's not a real > client-server structure. Apache, on the other hand, is a real server > for a client-server architecture. Depends on your needs -- svnserve is far easier to set up, generally faster, and simpler to configure. It also supports SSH tunneling, which is a bonus in some situations (though I think svn+ssh is a pain to configure) > > The exact same situation applies to the "mixing access methods" > scenario. The FSFS backend is will isolate your repository from the > issues inherit to mixing access modes, but it doesn't change the fact > that mixed-mode access is a bad idea. In exactly the same way you > don't run myisamchk on your MySQL tables if the server is still > running: that's mixing filesystem access and client-server access, and > it's a bad thing. The SVN folks don't seem to think so http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.multimethod Note that the bulk of the problems are related to (a) BDB and (b) Linux. > So yeah, as long as you're using FSFS, you probably won't have issues > with svnserv, but Apache's still a better route to go if you have the > option. You also need Apache to run Trac, which, if you ask me, is > more of a reason to use Subversion than most of the actual Subversion > features. : ) +1. Hearty agreement on that -- Trac is a strong reason to switch from any SCC provider to SVN. I think we're in agreement in general, but I think that the basic svnserve server is far more capable that you give it credit for and don't want people to think you *must* install Apache to use svn with 2+ developers. SVN will work fine with svnserve and the recommended FSFS backend. It's also worth pointing out lots of Unix-y folks are *still* running Apache 1.3, while SVN *requires* Apache 2. Two copies of Apache can be quite a load on busy dev servers :) That said, running under Apache not only gives you better scalability, but much better authentication and authorization options (eg hooking into existing LDAP or MS AD dbs), the ability to browse through a repository, and with SVN 1.3, the ability to use Apache to do custom logging of requests and the ability to browse all repositories located under a parent -- which is pretty cool. I typically make my life easy and just install under apache running on port 3690 (the svnserve port) so it doesn't interfere with existing IIS/Apache installs. So to summarize -- try SVN, especially with Trac. But don't let Barney convince you that you're bad for using svnserve :) -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:232734 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
