[ copying dev@, where we should probably continue this discussion ]
On Fri, Apr 2, 2010 at 1:51 PM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
> I just read this and had a few questions. I'm not sure if this list or
> the dev list is more appropriate.
>
> I think this was somewhat addressed in the posting but my question is...
>
> How complex is the svn code. I have been doing this a long time. I
> understand well object oriented coding. Is my understanding that svn is
> written in C++ correct? Or is it C? I have never worked on low level stuff
> like file systems or device drivers or graphic systems. All my experience is
> with data driven line-of-business apps. Would I struggle with the svn code
> base? (Yes I know that is hard to answer).
>
Subversion is written in C, with the test suite and other supporting bits
written in Python. That being said, the code is relatively well-documented,
and pretty straightforward for folks who have programming experience.
> I would like to get more involved in the dev side of an open source
> project. My two consideration would be NAnt or svn. With NAnt I have the
> advantage that it is written in C#, the language and environment I work in
> daily. But, svn is a great project and I would like to be able to help.
>
Feel free to scratch your own itches, but we're always looking for able and
interested developers. I assume you're subscribed to the dev@ list?
> Now a more specific question about the FS-NG and svn 2.0. Is the plan to
> move to a database back end such as SQLite as is happening with WC-NG? It
> seems that this would be easier to extend than something file system based
> with text based metadata files, etc. Also, it could allow for, if supporting
> MySQL for example, a more distributed server side component with multiple
> servers in different locations all accessing the SQL backend. Has
> consideration been given to and object base db like MongoDB which would
> facilitate new features without major data conversion steps being needed?
>
The only discussion about new backends that has happened so far is what type
of features and APIs it should support. Ideally, the correct abstraction
levels would be chosen such that users could plug $DB_OF_CHOICE or other
storage mechanisms into a more generic FS or repository layer. But all
those types of decisions are a long way off.
Thanks,
-Hyrum
Received on 2010-04-02 22:28:11 CEST