Jon Parise [2004-04-14 17:19 UTC] Have a look at the Horde VC package (http://cvs.horde.org/cvs.php/framework/VC/). It provides unified version control support for CVS, RCS, and Subversion.
Tobias Schlitt [2004-04-14 17:43 UTC] I like the idea of having an OO interface to things like Subversion and CVS. Anyway, a new category is not necessary IMHO - it would fit into the "Tools" categorie. A common interface for SVN, CVS,... would be cool (as the comment above describes it), so it should be checked, that the API is open enought to fulfill this need (driver architecture).
Bertrand Mansion [2004-04-14 17:53 UTC] Simply great !
Thanks for the good work :)
Chuck Hagenbuch [2004-04-14 17:55 UTC] Horde's VC:: API is already used by Chora (http://cvs.php.net/) to provide a frontend for either CVS or Subversion, so it's pretty broad. I'd love to get someone more focused on the SVN side working with the VC API to flesh it out/troubleshoot.
Markus Wolff [2004-04-14 20:42 UTC] Definitely a great idea... I'll wait with my +1 to see how the discussion about the Horde package will turn out. It would be cool if all available manpower can concentrate on just one implementation, but I'd also be okay with a standalone SVN package... well, I'll wait and see for now :-)
Paul Jones [2004-04-14 20:52 UTC] This package looks excellent; what a great idea!
As noted, HORDE has a similar package.
There is precedent for proposing HORDE packages to PEAR (c.f. Text_Diff). Perhaps a wise course would be to attempt a merge between the proposed package and the existing HORDE base, then proxy-propose the HORDE package back to PEAR. Of course, this would require the willingness and approval of both Clay and the HORDE guys. I think in the end both PEAR and HORDE would benefit from this track.
This is not to denigrate the work Clay has done here; it is good work based on a good idea. I'd like to see it in PEAR either way: as an evolution of the current proposal, or as a proxy from HORDE.
Stefan Neufeind [2004-04-14 22:47 UTC] I'd like to see such a package in PEAR. But however, as noted before, it would also be good to have a common API (as common as possible) to access various repositories. The Horde-package might be a very good basis for this, though I haven't had time to inspect it deeply. If there are any special functions for SVN or whatever they should surely be added, but a common API for all be maintained.
I'd really appreciate if Clay could work together with the Horde-people. And if a common package is the result, with maybe a bit adjusted or fine-tuned API, I also hope that Horde (e.g. Chora) will be open to depend on the "official" PEAR package.
Alan Knowles [2004-04-18 00:23 UTC] As far as I can see, in relation to horde -
Horde_VC provides an abstract layer (with drivers) to access Versioning control systems:
SCM_SVN provides a single interface to all the svn commands.
From what I could see of Horde_VC - writing a backend driver that used SCM_SVN, would be a very simple matter. - infact it would probably improve the design of Horde_VC??? - the driver would become a single class, rather than the current 5+ in a single file..
General Comments
-----------------------
Name needs lengthing.. Versioning_Svn_client or something..
SCM_SVN::init() - should be loadDriver or something.
SCM_SVN::init() not clear why fetchmode/stackret are not in the options array?
usage example at top of SVN.php would be helpful. (probably move/copy i t from factory)
you can use @version@ for the version string - it gets replaced by the installer.
Consider merging SCM_SVN_Common into SCM_SVN -
SVN_ADD:
if (!is_array($this->options) || sizeof($this->options) < 1) {
could be simplified.. (empty arrays eval to false)
if (!is_array($this->options) || !$this->options) {
** actually this looks like a standard piece of options checking... - perhaps refactor into Common, or factory
Constructors for commands appear redundant (could this code go in factory?)
looks like the option building could be refactored
a) str_replace('_','-', $opt);
$options = array(
targets => value
config-dir => value
auto-props => boolean
svn_path => ignore
path => ignore
)
.. then do a generic argument building?
you should really do escapeshellcmd inside the prepare statements - this means the libraries are 'safe' to use on the web.... - without considerations..
- did I miss something - the code mentions an xml parser the return values for things like list, but I could not see any examples anywhere..
BTW:
I also played around with SVN:
- cheesy streams wrapper.
http://devel.akbkhome.com/svn/index.php/akpear/Stream_Subversion/Subversion.php
= copy to file on commit hook for subversion.
http://devel.akbkhome.com/svn/index.php/akpear/Subversion/CopyCommit.php
** enables live testing on remote server of all stuff submitted to svn.. (without having apache read from a webdav mounted filesystem. = slow as hell..)
Chuck Hagenbuch [2004-04-26 02:55 UTC] Sounds great!
|
