In my previous comments, you should read "emacs" as "your favorite editor", the point being that a TEXTAREA in a browser in not anyone's favorite editor.

It sounds to me like the reason you consider changing the .pm files difficult is that it's outside the way of doing things that you have adjusted to. The steps are basically the same. When I build a cluster, I typically share the code on NFS so that I don't need to copy it to multiple machines. I think loadng code without restarting should be discouraged because of the memory problems it causes, but Apache::Reload would allow you to update that stuff in the same way you currently update the database.

You certainly could write a web interface to perltidy and a POD viewer, and a modified test harness, etc., but to me it all looks like wasted effort. Those things (and many other handy tools) already exist for working with files.

There is a larger issue with scalability. With only a few people submitting patches, it will work to have an RCS-like system for simple revisions. Other people may simultaneously work on a patch that breaks because of an interaction with a patch you submit, but it's unlikely. If more people were working on the code, the chance of conflicts would increase. That is what a develop => test => release cycle prevents. You also can't make large changes that affect many parts of the system without effectively halting all other development. That's what branches are for.

I should take another look, because it sounds like things have improved a lot in terms of test environment and that was what stopped me cold before.