Since it isn't all that slow to just ask Mercurial for batches of data, there isn't really a need to put it into a database, especially since there is an extra

Since it isn't all that slow to just ask Mercurial for batches of data, there isn't really a need to put it into a database, especially since there is an extra cost of updating the database for every change to the repository. The real problem is string searching and concise data gathering syntax, which is what we are focusing on. In the case of Fossil, it may be possible to access the backend directly and do any selects or joins at that level. While it would be nice to access the data for any system with SQL, for instance, those languages are not suited for working with graph-oriented data, and so the implementation choice comes down to writing a language that transforms user queries into different forms for each system, or writing a language that accesses some underlying database that the repository data has been translated into. We had been taking the latter approach, but the entrance of revsets pushes us neatly into the former approach. We still have our code to do all the data scraping, so we could use it for example with svn or git (which also has its own subgraph selection mechanism). There also remains the fact that since we are students, we sometimes like to implement things just for the hell of it. Like databases. We've already got B[+]trees and a parser library, which I'm sure have been written thousands of times, but it's certainly a useful exercise to implement them. Besides, Go is light on libraries right now and it's nice to help them out.