I'm working on designing a microformat that can be used to indicate the location of VCS (git, svn, etc) repositories related to a web page.

I'd appreciate some web standards-savvy eyes on my rel-vcs microformat rfc.

If it looks good, next steps will be making things like gitweb, viewvc, ikiwiki, etc, support it. I've already written a preliminary webcheckout tool that will download an url, parse the microformat, and run the appropriate VCS program(s).

(Followed by, with any luck, github, ohloh, etc using the microformat in both the pages they publish, and perhaps, in their data importers.)

Why? Well,

  1. A similar approach worked great for Debian source packages with the XS-VCS-* fields.
  2. Pasting git urls from download pages of software projects gets old.
  3. I'm tired of having to do serious digging to find where to clone the source to websites like Keith Packard's blog, or cariographics.org, or St Hugh of Lincoln Primary School. Sites that I know live in a git repo, somewhere.
  4. With the downturn, hosting sites are going down left and right, and users who trusted their data to these sites are losing it. Examples include AOL Hometown and Ficlets, Google lively, Journalspace, podango, etc etc. Even livejournal's future is looking shakey. Various people are trying to archive some of this data before it vanishes for good. I'm more interested in establishing best practices that make it easy and attractive to let all the data on your website be cloned/forked/preserved. Things that people bitten by these closures just might demand in the future. This will be one small step in that direction.a
also define links to "browse vcs" sites
I also often search a while to discover the web interfaces to the source code repositories of projects. I prefer to browse a little through the code before checking out. So I search first for the web interface and afterwards for the checkout/clone url.
Comment by thomas [koch.ro]
Should not it point to trunk
I think either webcheckout should automagically switch to trunk or the specification should mention that the links should point to trunk. I doubt somebody is really interested in checkout of full SVN repository.
Comment by cihar.com
comment 3

I agree about the links for CVSweb and the likes. I wrote about the two types of CVS (pserver and anoncvs, or more likely, cvs-over-ssh) in http://kitenet.net/~joey/rfc/rel-vcs/discussion/ and sincerely hope nobody uses cvs-over-rsh any more (but then, pserver needs to die too…).

Comment by mirabilos [myopenid.com]
Surely pointing to a branch is OK too?

For svn, sure, pointing to a tag or some sort of repository root is unhelpful, but I don't think it's necessarily fair to say "always point to trunk" either - if pointing to a particular branch would be more appropriate for a page, that would be good too.

For git you'd just point to the repository anyway - there isn't a standard way to address a branch. If git was a real URI scheme then perhaps it'd have such a mechanism...

Comment by smcv [pseudorandom.co.uk]
abuse of @type

Putting things like git and svn in the type attribute seems like an abuse of the link element - type is defined to be a MIME type, and neither git nor svn is a MIME type. (The type="text/x-wiki" hack for "edit this page in a browser" is similarly abusive - it looks like a MIME type, but clearly isn't. The MIME type of a web form is still text/html, even if you're using it to edit a wiki.)

I can see the problem that it tries to solve, which is that given a http URI, you have no idea whether it points to a git, svn or bzr repository. Presumably you'd prefer webcheckout to avoid downloading $uri/info/refs to check for git, doing a PROPGET to check for svn, downloading _darcs/inventory to check for darcs, and doing whatever the check for bzr is...

Comment by smcv [pseudorandom.co.uk]
svn trunk
Yes, for svn it should point to trunk or some other tag/branch/directory. Unless you really want them to check out the whole repo. I've corrected my svn example.
Comment by joey [kitenet.net]
type abuse

I agree, it's mild abuse to use "git" as a mime type.

The only alternative seems to be something like rel="vcs-git". Perhaps taking the whole vcs-* namespace like this is better?

Comment by joey [kitenet.net]
re: also define links to "browse vcs" sites
I don't understand what would be the value in making the link to the repo browser have a rel attribute marking it up. Such a link is visible to the user, in the web browser, and should have a description that makes sense in the context (ie, the "History" link at the top of this page).
Comment by joey [kitenet.net]
re: also define links to "browse vcs" sites
It would be useful for find this link easier. Not directly by user, but for example by some indexer or by an extension to browser such as Operator for Firefox. Anyway target of most microformats is not an user directly, but through some program.
Comment by cihar.com
This seems to be also usable for web-applications (cloud-computing).
Comment by akfoerster.de