The post by Christian where he talked about doing a Scheme interface to GIT has made me realize how useful a scheme interface to a good revision control system would be in my projects. If enough people feel the same way, maybe we could start a small project and build one. It should not be a lot of work.
Anyone knows about any Scheme interface in existence that could give us a head start?
Also, it should not be too hard to support many revision control systems by building the interface in a generic fashion that would delegate to specific interfaces.
Guillaume
Afficher les réponses par date
"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.
Personally, though I'm not a committer to Gambit Scheme, I am extremely leery of revision control systems other than the two tried and true open source ones, cvs and subversion, and of those two, I prefer subversion as a user. All of the others either have some hidden gotcha or are lightly used. For example:
Darcs -- hidden gotcha is that it's written in Haskell git -- lightly used, only exists because of the Linux kernel mercurial -- lightly used
Moreover, most of the IDEs and other development tools interface to cvs and subversion. So unless you've got some *hard* requirement that subversion can not meet, I'd recommend subversion.
M. Edward (Ed) Borasky wrote:
.. I'd recommend subversion.
I don't think Subversion is a wise choice.
When new concepts are coming, it's time to move on. Maybe you can wait until IDE support for the newer systems is there until you try them. Maybe I'll have to learn how to use git-svn or SVK to be able to work with the sources in a useful way if that is what Marc is choosing. Maybe that's a waste of time, maybe I'll sometimes need that knowledge when working for a company which is using Subversion. Joy would more be on the side of Darcs when it is coming to adapt new concepts.
Christian.
M. Edward (Ed) Borasky wrote:
Darcs -- hidden gotcha is that it's written in Haskell
No argument. Compiling Haskell on a non-mainstream system is murder. Even OS X had a showstopper bug for an unsually long time.
git -- lightly used, only exists because of the Linux kernel mercurial -- lightly used
Not really lightly used. Git is hosting the X.org codebase. Mercurial hosts the Mozilla code base. *Either* of those code bases dwarfs the Linux kernel.
http://git.or.cz/gitwiki/GitProjects http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial
Moreover, most of the IDEs and other development tools interface to cvs and subversion.
If this is your argument, you shouldn't be recommending SVN.
Most IDE's and devlopment tools interface to CVS, period. The Subversion plugins are *just* starting to come online and most of them are still pretty flaky.
-a
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.
-
Andrew Lentvorski -
Christian Jaeger -
Guillaume Cartier -
M. Edward (Ed) Borasky