[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: Any interest in a Ruby source code repository module modeled
From:       ChrisO <ceo () nospam ! on ! net>
Date:       2005-08-07 23:31:09
Message-ID: 42F6989B.9040202 () nospam ! on ! net
[Download RAW message or body]

Lothar Scholz wrote:
> Hello ChrisO,
> 
> C> I posted this in the Perl c.l.p.misc and c.l.p.modules newsgroups, and
> C> while it's a long shot I would be able to port this to Ruby if there
> C> were any interest, I could certainly be tempted to do so since I have
> C> more than a passing fancy for Ruby (just little time and opporunity to
> C> use it).
> 
> C> But if no one in the Perl world wants this and the Ruby world is 
> C> receptive to it, maybe I would port this to Ruby.
> 
> I like the idea, even when i think it will be almost impossible to
> come with a good solution that gets all the VCS under one API as
> concepts are too different (it's much much more functionality in there
> then simple SQL).
> 
> I would maybe like to help you, but only if it runs on Python.
> Or better, implementing the ideas in C and write wrapper's for many
> languages.

Hmmm, as someone else pointed out, it looks like in the Ruby world, 
something like this may already exist.  It certainly looks very much the 
same to me (eg. wcs or vcs).

As for Python and C...  Don't tempt me with ANOTHER OO scripting 
language!!  ;-)  I've always been interested in Python as well (and 
dabbled in it some), but I have limited time.  Which speaks to the C 
solution straight on.  It's not a bad idea to provide a C API that other 
scripting languages can wrap around (a la MySQL, etc.), but I just don't 
have the time to take up C for this.  And I'm not even sure going that 
direction is worth the effort involved, though I admit the idea has merits.

As for all the different ways the SCRs work, I admit this as well.  Part 
of a Ruby or Perl solution is that you find you have the ability to 
unify them somewhat using the approach I have suggested.  I found this 
to be more true than I thought.  And I was surprised to be able to get 
the interface down to something consistent and usable across multiple 
SCRs as well.

For those things which absolutely cannot be unified, one could, as in 
the Perl DBI world, start creating SCR specific modules to handle any 
specific SCR features one owuld still want in Ruby (eg. SCR::VSS, 
SCR::CVS, SCR::PVCS, etc.)  Perl does this with the DBI interface. 
There are speciifc DBI modules that handle the specifics on MySQL, or 
Oracle, or Ajax DB that can't come under the DBI umbrella.  My thought 
on the SCR thing was that the same direction could take place for SCR.

My approach would be to get the simple and unifying elements done first 
then come up with a scheme for handling those things that simply could 
not be incorporated under the SCR umbrella.  Provide a direction for 
this, and then let those be developed as people need them.  If a good 
plugin interface is provided, people will write the code when they need 
it and it can enjoy some robusteness and simplicity and logic in 
approach IMO.

-ceo

[prev in list] [next in list] [prev in thread] [next in thread]