Re: Discussion of SCM_SVN Proposal

On Thu, Apr 15, 2004 at 04:44:52PM -0700, Clay Loveless wrote: > I wrote my package because I need low level version control API capability > in a couple of apps I'm working on. > > I submitted SCM_SVN to PEAR because I like the code that lives in PEAR, for > the most part, and the PEAR project has no version control package (for > Subversion or anything else). > > The PEAR project _still_ has no version control package, so I think the > grounds for my proposal to PEAR -- "Hey, there's not a Subversion package in > PEAR! I bet PEAR could benefit from such a package! I'll write a Subversion > package for PEAR!" -- are still solid. > > It was not my intention to stir up some hornet's nest, or to propose > something that would be perceived by anyone as a competitor to Horde. I've > proposed a low level API for the PEAR project -- I'm just trying to fill a > small hole that I saw (and still see) in PEAR's otherwise robust offerings. I don't think you've caused any trouble. Here's my take on this: Your SVN package provides a solid interface to Subversion. It scratches your itch and I presume it's working well for you. That's the code that's being proposed here, and I support its introduction into PEAR. The second part of this discussion branched off into a thread about developing a driver-based SCM package. This is essentially what Horde_VC intends to be, and it's already well on its well to fulfilling that goal. Granted, it has a lot of rough edges from his Chora-based upbringing, but it provides a good API with three different driver implementations (CVS, RCS, SVN) that were non-trivial to develop. The one scenario I would *not* like to see coming out of all of this is the creation of a brand new SCM package that competes with Horde_VC (because that would just be wasted effort). Ideally, your SVN code gets folded into Horde_VC (which is then released via PEAR) or the Horde_VC_svn driver becomes reimplemented using your SVN package. I don't see a reason why anyone would even start to think about rewriting Chora to use a different SCM implementation, by the way. It already has one that works great and has plenty of room for expansion. -- Jon Parise (jon@php.net) :: The PHP Project (http://www.php.net/)