[gambit-list] Revision control systems Scheme interface

Christian Jaeger christian at pflanze.mine.nu
Fri May 25 10:42:18 EDT 2007


"Interfaces" could mean several things.

(a) process (pipes, parsing) based interface to existing external tools.
(b) interface to existing tool *libraries*
(c) direct "interface" to the repository data, meaning a reimplementation.

As mentioned I've already done part of (a) for git (parsing git-log
output). This is also the approach stgit (written in Python) is using.

There has been a Google SoC project proposition about creating working
library versions of the git tools. From what I hear this project is on
it's way now. From reading the git mailing list, it will probably not
become reentrant, though. This may or may not be a problem for you (for
writing web applications using multithreading, chances are high that it
is a problem; forking or starting separate processes being a possible
workaround, which probably won't work well on Windows).

I don't know why GIT is slow on cygwin; one reason could be process
startup/forking overhead (but some tools, like git-log, don't fork/exec
at all, so they should be as fast as on linux--are they?). Another
reason could be stuff that might not be directly mapped by cygwin
(handling of file descriptors? mmap? no idea). If you want a fast
windows version, (a) or possibly also (b) would not be solutions
(without reworking the git code). Reimplementation in (mostly-)Scheme
could avoid process startup and mmap usage. I've never programmed for
windows (if necessary I could try to get into it enough for this stuff).

I'm relatively confident to be able to write an implementation for
reading and writing single-object files, reading and writing pack files,
and the infrastructure for git-log, -add, -rm, -commit and trivial merge
functionality in about three weeks if I'm getting funding for it (800
USD would be enough). The more higher level parts like e.g. merging of
files and remote interaction would not be included in this work (I could
probably take care of those too with more funding; but I don't think I
will ever need those in my own future work). However, I would take care
that performance is good (this could include LRU caching, if necessary,
and taking into account the hints about the problems on Windows), and
that it's reentrant for Gambit threads and that other Gambit threads
aren't being blocked for inordinate amounts of time. So I think what I
can offer is in-process and properly multi-threaded lowlevel git
repositoriy handling which should work equally well on Windows; the
stuff on top of it may be large enough (or then maybe not) to be afraid
wanting to reimplement it; maybe others would do it with less funding,
or maybe for those tasks the normal git utilities or the forthcoming git
library are working well enough. (BTW note that I would reuse the C
xdiff code used for handling deltas in pack files, which is GPL, so the
license of the whole thing would probably have to be GPL. Unless I'm
also being funded for reimplementing xdiff.)

A possible alternative solution, if the performance issues are only
process forking/startup overhead, may be to take the Git tools code and
basically call their main functions, but leave them up running for reuse
as long as possible (they'll exit on error, for example, might leak
memory, require reinitialization code or other evil hackery). I hear
someone tried this already for calling from Perl. I'd probably link them
with Gambit to have Scheme on both sides of the pipes (this should make
development and communication somewhat easier). I'm not so sure whether
I'd want to invest time into this kind of solution; it might be better
to wait for the Git library.

Regarding generic interfaces, I don't know. I only know CVS, Git and a
bit of Arch, SVN and Darcs. Developing generic interfaces would probably
be a task to be done by someone writing an application, after individual
interfaces to multiple systems are already there. Possible starting
points for digging out knowledge could be the git-svn, git-arch, git-cvs
tools, and maybe the versioning system access code in Eclipse. (Actually
I'm an Emacs user, but I'm not aware of a multi-versioning repository
interface in Emacs. Is there any?)

Christian.




More information about the Gambit-list mailing list