Re: Discussion of SCM_SVN Proposal

Hi Martin, > Can you (in a few words) sum up the differences between your package and > VC? Sure ... Based on my read-through of Horde's VC package, VC: - is still Horde-framework dependent - has a fair amount Chora application-specific logic related to displaying output, validating input options from Chora interface forms, etc. - is focused on read-only access to repositories - requires repositories to be on the same server as the VC installation My SVN package: - Only depends on XML_Parser - Contains low level-only code (no application or display logic). It interfaces with the svn command line tool, and outputs either raw output or structured output (XML or PHP Arrays). - Supports the complete SVN feature set (not just read-only, but read/write) - Like the svn command-line itself, can access repositories located anywhere A Tools_SCM package would be driver-based, with SVN and CVS drivers that reflect what I've said above about my existing SVN package. (Full tool feature set support, no application-specific logic, etc.) Note: This is based on my assessment of the two packages in their current states. There's nothing saying that VC couldn't be adapted to support more features, and that the Chora and Horde stuff can't be removed completely. However, that gets into the overhead issue I'm talking about -- why go through the trouble of doing all that when VC and/or Chora could just adopt dependency on a PEAR Tools_SCM package that is free of all that from the beginning? > I do not think there is much overhead: All Horde packages in the > framework/ directory already seem to be "pearified". So packaging them > is more or less only a matter of running "pear package" in the right > directory. In the end the only difference would be that the source code > is not kept on PHP's CVS server but on cvs.horde.org. > > Merging your code into Horde's codebase sounds like *the* way to go for > me. Having two version control packages with nearly exactly the same > features would be a pity. Please have a closer read-through of the Horde VC package -- I think that upon a thorough review, the two packages cannot be said to have "nearly exactly the same features". Can you say a little more about your last paragraph? PEAR itself has more than one package for a variety of things, and while I haven't been around for all the discussion of those packages, it seems that no real damage is being done by having two DB abstraction layers, and several template packages. I'm not trying to spark a "competing packages" discussion here -- because there _is_ no competing PEAR package for version control. -Clay -- Killersoft.com