On May 5, 2010, at 10:12, Les Mikesell wrote: > On 5/5/2010 8:46 AM, Brendan Farr-Gaynor wrote: >> > >> Thanks for your response! Running local copies of the environment doesn't >> seem practical in this case, my guys are working on 10+ projects at a time >> all of which can be in different states and which need many different >> modules in place via apache and php which would take forever to setup and >> even support across multiple workstations. Not having to worry about client >> machine consistency keeps things sane (in my opinion). When the commits are >> fast, the central model works well, I'm just trying to figure out a way to >> keep them fast.
I agree with Andy; you shouldn't be committing code that hasn't been tested at all. Having used Subversion to develop web sites myself, in an all Windows shop except for my Mac, I understand the desire not to have to set up a local web server on each development machine. Fortunately, you don't have to. We set up our web apps so they would run from anywhere on disk, so we gave each developer an account on our central Linux development web server and had each developer check out working copies of their projects inside their public_html folder, which they could then access via http://dev.example.com/~username/. They could access this working copy on their Windows development machines by mounting their Linux home directory via Samba. They could modify files and test as many times as needed, and commit only once they were actually done. This makes your Subversion commit logs much more meaningful. There are some caveats to having working copies on a file server, but for us it mostly worked fine. >> The network *shouldn't* be an issue, traffic is fairly light and is gigabit >> to all of the machines. (I'm not sure how to test this beyond some pings). >> We do have a very small commit hook which updates an Apache web root with >> the changed file so that developers can see their changes in-browser. (how >> could I check the speed of this?). We don't commit *large* binaries, in our >> web projects however there are lots of common .jpg's and .png's for our >> interfaces each weighing in at no more than 100k. We're not updating these >> often though, could these be the big problem? >> >> Yes, we are serving the repo via Apache. I will try a restart to see if >> things feel faster. (Should I be watching memory usage on Apache in this >> instance?) > > Why don't you run viewvc or websvn for browser access so you don't have to > wait for anything extra during commits? Just in general, disk seeks are the > slowest operation on a computer and anything you can do to avoid them will > speed things up even if you don't know the exact details about them. If you > only have one drive, it would help to put the repository on a different one > so the apache logs don't compete for head position. Most OS's will use added > RAM for filesystem cache and speed things up indirectly by avoiding the need > to seek for repeated reads. There are also some subtle things that can slow > performance like having apache set to log client hostnames and a DNS server > that responds slowly on reverse lookups. I don't think running ViewVC or WebSVN is related to what the OP wants to do. ViewVC and WebSVN are great for seeing the contents of a repository -- in this case, the HTML or PHP or Ruby source code. But if you actually want to see what the resulting web site will look like and have PHP or Ruby interpret that code, you have to do what the OP is already doing -- check out a working copy and auto-update it in a post-commit hook, as described in the FAQ: http://subversion.apache.org/faq.html#website-auto-update Finally, a quad-core Xserve should be so amazingly much more horsepower than you would need just to run Subversion; it should be able to handle 5173 other tasks at the same time without breaking a sweat. My suggestion for where to begin troubleshooting would be with the post-commit hook you have that updates your web root. Try disabling that just for testing. There's a good chance that will almost completely eliminate the commit delay. If so, I can suggest some ways to speed this up.
