[gambit-list] Revision control systems Scheme interface

Guillaume Cartier gcartier at jazzscheme.org
Fri May 25 11:19:13 EDT 2007


Hi Christian,

Personally I have 2 needs for a revision control system:

1- High priority. Just being able to use it for my projects. In that 
respect, using the tool's command line interface is acceptable. In this, 
I think GIT is lagging because it was developed for Linux which is why I 
am considering Mercurial.
2- Low priority. Creating a Scheme interface to it and GUI tools on top 
of that interface. For this a programmatic interface like you say is 
being developed for GIT would be great. Interfacing to Mercurial would 
be harder as we would have to interface to the command line tools and 
parse their output.

You talk about funding. Do you have any ideas on that? Personally all 
funding is still coming for my personal pocket so that any low priority 
project like this will always have to be done as a hobby.

I don't think I would have time or expertise to help in the Scheme 
interface to GIT through Gambit. My contribution to the project would 
clearly be more into building nice multi-platform GUI tools on top of 
this interface if you or anyone else gets to doing it.

Guillaume

Christian Jaeger wrote:
> "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