Great news! Siddharth Kalra, a student at Seneca College, is going to work on Mercurial history browsing this semester.
The (vague) goal of the project is to take the now-familiar mercurial-central shortlog page and make it awesome. In case you haven’t seen it, Dirkjan Ochtman’s graph view is already a step in the right direction. It’ll probably be a starting point for Sid’s work.
What should Sid change? I have a few ideas:
- It would be great to have the history scroll “forever” up and down, like a tumblelog.
- Sometimes when I’m looking at history, I can’t tell if the changes I’m looking at happened in the mainline or in a branch. So ideally the page would show major lines of development in different colors–for example, blue for mozilla-central, orange for tracemonkey. This is possible using information from those repos’ pushlogs.
- Pushlog information could also be used to make those special paths relatively straight, with other smaller branches and mini-merges happening to the side or hidden by default with some kind of collapse/expand widget.
- It should show more information about each changeset, if it can be done in an unobtrusive way. I would like to know which directories were touched and roughly the size of the diffs.
- Often I wish I could filter the history by file or directory.
- A vertical timeline would be nice, so the location of a changeset on screen would tell something about when it was developed or pushed.
- It would be great to be able to zoom in and out and see weeks, months, years of work.
This is a call for ideas. What would you like to see? How can hgweb do a better job mapping the multiple timelines of this sci-fi adventure?
You might consider starting with the pushloghtml page, which is what the Mozilla community seems to use, rather than the shortlog page, which isn’t very useful to begin with.
Search history restricted to a particular date range and directories. (when a bug is found to start on a particular build from a month ago, need to find what was changed since the previous build, in relevant directories)
It would be nice if I could view more than 10 entries at a time in the changelog.
The thing that I use HG web for the most is digging through logs for a given file.
Specifically, I find myself looking at some piece of code wondering “why was this code written this way” or “what is this code trying to do”.
Today it is quite painful do dig that information up. HG Blame allows you to see who last changed a given line, but often times that is generic cleanup patches that didn’t actually change the functionality. So you have to figure out the revision before that change by looking at the HG log and go to the previous revision, then find the code again, and repeat the process until you find the last patch to make a functional change.
Bonsai was somewhat better in this regard. It at least showed you the checkin comment for every given line and jump to that revision. You could then manually step one revision further back since the version numbers were numeric.
It would be great if the HG log page contained links to the previous version for every line.
Nice point, Jesse.
Sid, Ted Mielczarek did another “better shortlog” page, which you can see here:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=sep+10+2008&enddate=now
The most important thing here is that the dates it’s showing you are the dates those changes were *pushed* to mozilla-central, not the dates they were *committed*. As Jesse mentions the commit dates aren’t very useful.
This makes the history linear (a huge relief) and to some degree makes it obvious when a merge is big and when it’s little.
In addition to what Jonas said, bonsai had the nice feature of being able to easily see the list of files touched by a checkin. This would be really nice in hg as well; I used to actually skim the bonsai log looking for changes the files I cared about and looking through the diffs…
One other comment. I just filed a bug on hg annotate being really slow: see http://www.selenic.com/mercurial/bts/issue1310
I have not played with the current hg page much, only to do date-searches for regression ranges.
I like the suggestions above about making it much easier to do date-range queries. My biggest use case here is to hunt down regression ranges, so anything to make that easier would be appreciated.
Additionally, being able to query by the person that checked in the patch and by source code directory would be super helpful, as I used those features in bonsai quite a bit.
It would be nice if the checkin could have links to official builds built from that changeset.
That is link to the ftp folder of the builds if the files exists. This would make it easier to test changes and find regression ranges.
I would like to see https://bugzilla.mozilla.org/show_bug.cgi?id=448707 fixed.
It’s really difficult now to find out which patch caused a regression. This was much, much easier with bonsai queries.
Also, I really miss the blame view that bonsai had.