Thanks… we did that exact thing actually, it’s the basis for our Versioning Toolbox. The tricky part wasn’t getting it to work for SVN, it’s getting it to work uniformly for any source control system. The Versioning Toolbox doesn’t offer a query language per se, but it does offer a consistent UI across all source control systems to get this type of info.

However, the whole time we worked on it, you couldn’t help but feel that it was a replication of work. It’s equivalent to interfacing to a legacy database by making a second database with tables to match your needs, then replicating on a regular basis.

The SVN toolkit sounds good, I’ll check it out. It would be nice, though, if all source control implementations thought through these needs as well.

select author where file = “x” and line = y
svn annotations

Across all files, which version’s check in comments contain a specific string pattern?
select revision_number, file where comment like “x”
svn ide filter

select file, revision_number where author = “x” and checkin_date >= y
svn filter on name and by hand see the days

select top 5 revision_number where file = “x” order by lines_changed
you can do that only manually by now, but its not hard to write. you just get history of the file and compare it with each other.

Svnkit is great library to access svn, if you make it good people will use it and you can make next great open-source project. it could use pseudo-columns. Or even better idea would be to export all the normalized data to db and let db handle sql. you could also give it update option(so you would only have to import everything once, i know that svn has dump option). it could be fun. think about it.

And I believe they are quite far in the standardization part aswell as they index quite different vcs systems. No dvcs of course

Anyway, quite a lot of wishful thinking you have there… I think USB is the only example that more or less works always.

Nice post. Yes, it sure would be nice if more things could be standardized to the extent that SQL/databases are.

But look at SQL! It has got to be the most successful and “permanent” IT technology/language ever. It’s more than 25 years old, but still going very strong.

Part of the reason for this is the strength of the relational model. Part of it is that databases are, well, permanent. More so than applications.

I think the main reason the different VCS systems are so different is that the model is still changing. I like the Subversion model a lot better than the CVS one. But I think DVCS systems will change this again.

Regards

John Hurst

There might be short-term gains to be had by creating this sort of standardized interface, but in the long term it will become an albatross to systems attempting to revolutionize version control workflows.

You could allow the protocol to support the features of each VCS (in the future) and make it so you can write translators to map the features of one VCS to the other if necessary.

That you failed to include ideas from dvcs systems adds up to fail.

Version control systems have widely differing fundamental models. Trying to pave over these differences with common terminology would probably be deceptive at best.