Re: Discussion of SCM_SVN Proposal

Quoting Clay Loveless <clay@killersoft.com>:

RE: Category placement I agree with Tobias' suggestion that SCM_SVN should perhaps be placed under "Tools and Utilities" instead of a new SCM category. My question, though, is what would the name be? phpDocumentor obviously doesn't adhere to the naming convention (grandfathered in), but new packages there should be ... Tools_*? Utilities_*? Or perhaps both would be acceptable in that category?

I don't think the category name should be required as a class prefix. It'd just be unnecessary overhead.

My intent with the SVN package is to create a low-level bridge to the Subversion command line. (Akin to the way PHP's native low-level MySQL functions bridge with MySQL.) Someday, I hope someone with greater C skills than mine will take the Subversion C libraries and build a bona-fide PHP extension with them. Until then, a PEAR-housed SVN package should act as the stand-in. With such a package, any application (or framework) that wants easy access to some or all of Subversion's capabilities can include the PEAR-housed SVN package.

That is the idea (if not, perhaps, the current reality) behind the current VC package as well.

I wish I had time to get deeply involved in Horde -- unfortunately, I don't. Given the current state of SCM_SVN (roughly 90% feature-complete), it could theoretically be dropped into the Horde framework _today_ to beef up the SVN side of Horde::VC and Chora. On the other hand, rolling what I've done into Horde::VC and then rolling it back out to a new PEAR proposal seems like an awful lot of overhead to me.

As opposed to rewriting VC_svn to use SCM_SVN and adding another layer for anyone who wants to use Chora with Subversion? That sounds like overhead to me...

SO -- to sum up, at this point I lean towards Horde adopting an additional PEAR dependency on the SCM_SVN (or whatever it winds up being called) package ... that is, if Horde wants to take advantage of the work I've done.

I can pretty much guarantee that won't happen. I'd rather peek at your code for ideas/examples for improving the VC svn driver than add another layer of abstraction to Chora's dependancies. I mean, I'm willing to be flexible, but ... why?

After reviewing Horde::VC, there are still a number of Horde-specific bits in there (such as require_once 'Horde/Cache.php' calls, etc) ... and I feel it may be easier/more efficient to get the ball rolling with a fresh Tools_SCM API with a SVN driver to get it off the ground.

And rewrite Chora from scratch to use it, ditching all of our experience and bugfixes in the process? In my experience, writing something from scratch is rarely more effective than refactoring existing code if the goal remains the same. As for the Horde cache class, I know the that PEAR purists here will hate this answer, but that's just a matter of installing another package; especially easy once PEAR channels are working. But a version of VC that actually got into PEAR would probably drop that and push the caching back into Chora itself somehow. -chuck -- "Regard my poor demoralized mule!" - Juan Valdez