Re: Discussion of SCM_SVN Proposal

<mj@php.net> wrote : > 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. I don't understand why Clay should adapt his work to Horde when Horde is not in PEAR ? Could you let me know the idea behind that. It's like saying: "Could you have a look at the class XYZ in PHPClasses (or Hotscript or SF or ...) and adapt your code so that both can work together".. Shouldn't that be the opposite ? Personally, I already see a lot of use for SCM_SVN alone, without the overhead of yet another abstraction layer and without support for CVS. I can understand that Chora needs to support both SVN and CVS, because that's a feature for this application, but we are talking low level API here. As Clay said, using SCM_SVN in higher level applications shouldn't be a problem and those applications might actually benefit from the fact that this package offers access to all subversion commands. Bertrand Mansion Mamasam