> 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). 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. 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. 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. : ) cheers, barneyb On 2/17/06, John Paul Ashenfelter <[EMAIL PROTECTED]> wrote: > On 2/15/06, Barney Boisvert <[EMAIL PROTECTED]> wrote: > > > I would also recommend > > > getting svnserve running and use the SVN:// protocol. > > > > I'd recommend against this. If you can set up Apache 2 and run > > Subversion through the included WebDAV module, that'll give you a far > > more robust and scalable solution. In particular, it will avoid > > locked repositories that result from concurrent access - something > > that svnserve (and file:/// access) can't protect against. If you've > > only got one developer, probably not a huge deal, but if you've got > > two or more (or forsee it in the future), I'd recommend the Apache > > route from the start. > > While I certainly prefer the full-fledged Apache setup for SVN (partly > b/c of the far more robust authentication and management options) 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 Apache setup is harder I think for IIS shops, since there's no > Apache familiarity. But it isn't rocket science. If you are an Apache > shop, then by all means go straight for Apache -- you get WebDAV > access for your non-techie users as well, which is a huge bonus. > > > At the very least, NEVER mix access modes. Do everything through the > > same mechanism, whichever you choose. Apache does some internal magic > > to speed certain operations, and it plays eggbeater with your > > repository if you then connect with a file:/// or svn:// connection. > > This applies repository wide, so if you have three projects in a > > single repository, make sure they're ALL accessed via the same > > protocol. That means updating EVERY working directory if you change > > protocols in the future, which is a very strong argument for picking > > the right one from the get go. > > SVN has the built-in relocate command which handles switching > repository URLs -- you *will* get into weird situations if you update > some files in a working dir with file:///, some with http:// and some > with svn://, but I locally use file:///, svn://, and http:// > interchangably *between* projects. YMMV -- Windows servers, > Windows/Mac clients. > > -- > John Paul Ashenfelter -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:232731 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
