Discussion of SCM_SVN Proposal

Discussion of SCM_SVN Proposal First off, thanks to everyone who's commented on my SCM_SVN proposal -- I appreciate the feedback, and I'm glad to see that I've hit on something that may have some legs. Rather than respond to each comment individually, seems like a batch reply / opening of discussion is more efficient. So, here goes. 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? RE: Clay works with Horde/Chora vs. Horde/Chora adopts Clay's package I'm flattered by the invitations to get involved in Chora development. I think the Horde project is an impressive one, and certainly Chuck, Jon and company have made truly outstanding contributions to the PHP community and open source community as a whole. In other words, I think Horde is great. I've spent a fair amount of time today reviewing the Horde::VC package, as well as browsing the current Chora tree. Good stuff, and there's no questioning that Chora is a solid and popular application. 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. I feel my time is best spent on making the low-level Subversion package as tight and efficient as possible. That way an application like Chora, which focuses on CVS/SVN/RCH repository browsing can benefit from it, while another application (say a version-controlled Wiki or shopping cart app that wants to transparently version-control its product descriptions) can benefit from the repository editing capabilities of the package. 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. 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 know there's more to be said on this topic (by myself and others) -- but that's my current thinking at the moment on this. I hope we can have a flexible discussion about it -- I'm not firmly set in stone one way or the other, but I will say that my leaning is what I've stated above. RE: Driver architecture ... and Tools_SCM? It would only take an afternoon or so to convert SCM_SVN to Tools_SCM with a Subversion driver in the bag. Perhaps that's the happy medium here? I would be willing to proceed on to writing the CVS driver to go along with it. I'm no CVS wizard, but I get by alright. I would definitely appreciate any assitance the Horde guys were willing/able to offer on the CVS driver based on their experiences with Chora and Horde::VC to date. 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. A note of concern I have about any version control abstraction layer -- there are some things that simply cannot be done easily (or _at all_) with CVS that can be done with Subversion. (See: http://osdir.com/Article203.phtml for a decent summary of some of these things.) I would not be in favor of any abstraction that would essentially cripple Subversion into being CVS-compatible just for the sake of a unified API. For example, I think Subversion's "move" capability for moving/renaming files (or directories) within a repository without losing revision history is fantastic. There simply isn't any way to do this with CVS without hacking the repository directly ... something that I would be reluctant to automate with an abstraction layer. So do you drop "move" support from the abstraction layer? Or do you include it and simply add "Note: Not implemented/available with CVS/RCS drivers" to the docs? I support the latter -- after all, PHP itself is littered with documentation notes stating "Not supported on Windows PHP platforms" for function _______. Let's open a discussion on Tools_SCM -- I would be happy to lead this package, and would take on the challenge of a CVS driver that would emulate as much in the way of Subversion functionality as possible, leaving what's impossible indicated as such in the documentation. SUMMARY My thoughts in a nutshell break down into two options: A) Let's keep SCM_SVN/Tools_SVN a standalone PEAR package, and add a SCM_CVS (or Tools_CVS) package to PEAR ... either of which Horde may or may not choose to adopt for use in Chora/Horde::VC. B) Get going with Tools_SCM with seperate SVN and CVS drivers that are as compatible as possible _where_ possible, with an abstraction layer that maintains maximum functionality for all drivers. (Meaning that SCM::Log('somefile.txt') works across all drivers, but SCM::Move(str SRC, str DST) may not work for some drivers.) Whew! Sorry about the long message -- thanks for making it this far. Looking forward to the discussion! -Clay -- Killersoft.com