Nice.  Looking at it, I could see value to faceting according to the 
"number of lines" property (distinguish large and small checkins).  This 
would call for something we've talked about before---a numeric range 
facet, rather than an enumerated values facet.  Would also be nice to 
facet on which module (string after /modules/ in the file path) and 
filename. 

This connects to another research interest of mine.  "Structured 
commenting" involves using properties and values, instead of english, on 
software comments.  We already see some of this in javadoc.  For 
example, we might use tags to annotate a particular checkin as a 
bugfix.  Or, there could be a "enhancement" property whose matching 
value on a number of distinct checkins indicates that all those checkins 
are directed towards the same code enhancement.  Once these comments 
existed, they would enhance faceted browsing.

Johan Sundström wrote:
> I've crafted a CVS checkins browser in Exhibit, which shows checkins
> to the Pike programming language:
>
>   http://exhibit.ecmanaut.googlepages.com/cvsview.html
>
> It scales to roughly a few weeks worth of checkins at a time before
> becoming sluggish. Until the arrival of a database.purge() method in
> the Exhibit API, reload the page to start on an (almost) empty stomach
> again.
>
> In making this exhibit, a concat() exhibit expression function was
> added. I also noted that the add() (and, conversely, multiply())
> functions available are so far somewhat broken by design; the data you
> operate on will be turned into a set prior to performing the
> operations, meaning that equal operands will only be visited once.
>
> In practice, that means that add(.files.lines_added,
> .files.lines_removed) will actually perform the operation
> add(uniq(.files.lines_added), uniq(.files.lines_removed)) which is
> often substantially lower than the total number of changed lines, when
> a checkin touched multiple files. Ergo: no Changed lines facet at this
> time.
>
> This Exhibit view configuration should lend itself easily to making
> similar Exhibits for other version control systems, if they just
> export their change sets as JSONP.
>
>   
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general

Reply via email to