SVG-edit has far exceeded my expectations in the seven months since I've been working on it. The people I've met there have been amazing and it's been really fun to watch the project grow both in members and in capabilities. Without the people working on it, people like Alexis (now the top contributor) and wormsxulla (whip-cracker on UI translations) and others, there wouldn't be a project - that much is obvious. But would you like to know the secret sauce in the SVG-edit project? Of course you would.
One of the surprising factors in SVG-edit has been using GoogleCode in combination with Subversion. Let me tell you why:
Linked Information
Everything is an issue in SVG-edit. This is the way we keep track of things to do. This is the way other people discover things they can work on. This is the way we prioritize features for a release. This is the way we identify good first bugs for new hackers to work on. This is the way we sort problems into browser-specific, usability, interoperability categories. This is even where we put requirements and design decisions.
Making almost everything an issue is good because GoogleCode has some magic that detects revision commit messages and message comments and inter-links the two. For instance, if I fix issue 436, I might do:
$ svn ci -m "Fix Issue 436: Fixed the foo thing"
This shows up in GoogleCode here and provides you a link to the issue.
Now in the issue itself, I can mark it as Fixed and mention the revision that fixed the issue:
Fixed in r1275
Once again, GoogleCode provides a link to the revision when you look at the bug.
This kind of tracking takes a little bit of discipline, but it's not that bad and the payoff is worth it. It really helps other developers keep tabs on what's been solved where and how.
Host It
Since SVG-edit is a 100% client-side application (i.e. everything happens in the browser, no server component), and since Subversion allows you to specify MIME types by setting properties on files, we can convince GoogleCode to host the entire project in runnable form for the purposes of demo-ing the code.
This applies to the trunk as well as any branches and tags. For instance, you can actually see the evolution of SVG-edit over time:
Or you can look at the latest trunk build.
Or you can host the file in a web page by using <iframe> element like I've talked about before.
The fact that GoogleCode servers host the repo and also support web serving the content is immensely powerful: it means we don't have to administer a source code repository and we don't have to pay for a dedicated server or bandwidth costs to demo the software. Furthermore, because it's a browser-based app, users don't have to download anything, they can try out the code right on the spot.
Incidentally this is also one of the strengths of a web app in the first place: Zero downloads.
Tracking Down A Regression
GoogleCode's hosting of the svn repo doesn't stop at branches/tags. In fact, you can look at ANY revision in the browser directly. Coupled with the fact that we don't really require a build step means that it is very easy to track down a regression.
git has this cool feature called bisect that allows you to hunt down when a regression occurred by seeking forward/backward across revisions in increasingly smaller increments, building each revision and testing until you find the first revision in a branch that exhibited a problem.
We can do this much easier in SVG-edit using Subversion on GoogleCode. Let's say one day we notice a problem in the trunk and we're at r1200. Well, we might decide to try out the editor at revision 1000 to see if the problem existed then. If the problem did not exist, we hop ahead 100 revisions to r1100 - was the problem present then? If so, hop back 50 revisions to r1050. Repeat in the browser until you isolate the earliest revision where the problem occurred, then add a comment to the issue and go review that revision.
Totally amazing capability and no more difficult than changing a revision number in the browser location bar. I have to credit Narendra Sisodya, the project founder, with uncovering that little nugget.
Not a Nirvana
There are still some grips/nits I have with GoogleCode+Subversion:
- Being able to serve gzipped JavaScript would be great
- Being able to display the current revision number in SVG-edit
- The wiki markup needs significant improvements
But this is free hosting and project management software, so I can't complain too loudly. 🙂
So, that would be somehow easy for single file projects, which doesn’t seem to be the case [1]… (Good for modularity, of course!) If it was, then you simply needed to add the appropriate SVN keyword(s) [2] and parse them with JavaScript afterward. 🙂 Note that I’m not sure if this works while directly accessing repository files (it’s the SVN client’s job to turn something like
$Rev$into$Rev: 123$so…I’ve recently reported a tightly related issue [3] in SVGWeb you’ll probably want to take a look at. 😉 The current idea is to use an SVN utility command such as
svnsvnversion(or TortoiseSVN’s SubWCRev [4] or evensvnwcrev[5], which are similar) in order to fetch the highest revision of all files in a subtree. The disadvantage is that it needs to be run in a working copy.Cheers,
Helder
[1] http://code.google.com/p/svg-edit/source/browse/#svn/trunk/editor
[2] http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html
[3] http://code.google.com/p/svgweb/issues/detail?id=356
[4] http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html
[5] http://svnwcrev.tigris.org/
Hi Helder,
I did try to use SVN keywords ($rev$) but the issue is that the source you browse on googlecode is not a working copy, so you get $Rev: xxxxx$ in your working copy, but $Rev$ when fetching the JS from the googlecode web server.
See the getVersion() function in svgcanvas.js.
Regards,
Jeff