Project Name
Adding Functionality to the Browser Based UI for Mercurial History Browsing, hgweb
Project Description
Mozilla is just starting to use an exciting new distributed version control tool: Mercurial.
One of the exciting things about Mercurial is that the history—the list of all the changes that have ever been checked in—is not linear. It frequently has branches and merges. This is actually a good, important feature, as you know if you've read a little about distributed version control. The downside is that the history becomes a maze of twisty little passages. Benjamin Smedberg's demo shows the history of a repository with lots of merges (each box is a check-in; you can click on the boxes to move around).
There have been a couple attempts at showing history in an intuitive, graphical way. Mercurial comes with a web UI for browsing the repository, including history (here's what it looks like). It also comes with an "hg glog" extension that draws history as ASCII art, and an "hg view" extension that does roughly the same thing with a little GUI. Sadly, none of these applications qualifies as awesome.
The project's goal is to rectify this sad situation by writing an awesome browser-based UI for navigating Mercurial repository history.
Resources: jorendorff, bsmedberg
Project Leader(s)
Siddharth Kalra
Project Contributor(s)
Project Mentors
- Jason Ordendorff (jorendorff)
- Dirkjan Ochtman (djc)
- Ted Mielczarek (ted)
- Benjamin Smedberg (bsmedberg)
Project Ideas
September 23rd, 2008
| Hgweb ideas
|
- We have to make sure you understand hg
- we have to decide on some very small thing that you can get running very soon
- we should talk it over and make sure it's clear how to do it
- we should plan to meet up later and brainstorm some, once you've had a chance to play around with hg
- Ideas from the blog post by jorendorff
- jorendorff's ideas
- History scroll forever, up and down. Something like a tumblelog
- Able to identify whether what one is looking at is in the mainline or a branch
- Major lines of development color coded i.e. blue for mozilla-central, orange for tracemonkey etc...
- This is possible using information from those repos’ pushlogs
- Pushlog info could 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 sort of collapse/expand widget
- Show more info about each changeset, but only in an unobtrusive way
- Be able to know which dirs were touched and roughly the size of the diffs
- Be able to filter the history by file or dir
- A vertical timeline
- Location of a changeset on screen would tell something about when it was developed or pushed
- Be able to zoom in and out and see weeks, months, years of work
- Showing dates of when changes were "pushed" to mozilla-central, not the dates they were "committed"
- This makes the history linear and to some degree shows if a merge is big or small
- Jesse Ruderman Ideas
- Consider starting with the pushloghtml page, which the Moz community seems to use, rather than the shortlog page
- Gc Ideas
- Search history restricted to a particular data range and dirs
- because 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 dirs
- RyanVM Ideas
- Be able to view more than 10 entries at a time in the changelog
- Jonas Sicking Ideas
- Uses HG web to digg thorugh logs for a given file
- Wondering "why was this code changed" or "what is this code trying to do"
- Today it is painful to dig this info up
- HG Blame allows you to see
- who last changed a given line, but many times that is just cleanup patches that don't change the functionality
- ability to see who made changes that actually changed the functionality
- Bonsai had better functionality
- Showed checkin comment for every given line and jump to that revision
- You could then manually step on revision back since the version numbers were numeric
- HG log should be able contain links to the previous version for every line
- Boris
- Bonsai had the feature of being able to see the list of files touched by a checkin
- Clint
- Anything to make hunting down regression ranges
- Able to query by the person that checked in the patch and by source code directory.
|
January 15th, 2009
| DPS911 - Project Description and Plan
|
|
I will be continuing my work on hgweb for this new course. I’ve had a talk with jorendorff and ted regarding the bugs I can try to fix. I have various options that I can take on. There are definitely things available that I can continue to work on throughout the semester.
Ideas for Releases
Ideas for Releases
bug 459727 - pushloghtml should show more than 10 entries at a time
There are still issues with this bug that need to be fixed. The basic functionality works but there are some things that still need fixing. Things like the buglink functionality, loading more entries according to screen size, optimizing the code for efficiency etc still requires work.
History that is filtered by directory
Filtering the pushlog according to the directories touched. According to jorendorff this is a large feature that will require work. I told him that we were required to put out releases every 2 weeks so he recommended that I choose one large feature to work on (this one). I can implement this feature and improve its functionality for at least a few releases.
Hg Annotate is very slow
This is a bug that people have been working on for a while. Files using Hg Annotate are taking forever to load in any browser in comparison to loading the same file in bonsai. This is a medium difficulty bug that I could fix in maybe 2 releases or so.
Expand/Collapse functionality for files touched
Last semester I fixed a bug that added files touched functionality to the pushlog. My bug passed the review but now I want to add expand/collapse functionality for the files touched.
Goals
My goals are to give priority to the bugs that users want done. I will probably start by working on the pushloghtml should show more than 10 entries at time bug and then see what I want to work on next.
Ideally I would like to get all the four ideas I have listed above done but it is hard to say whether that will be possible. Inevitably there will be issues with my patches and I will have to probably dedicate some releases to bug fixing.
Possible Problems
Last semester’s experience with this stuff means that I won’t have a large learning curve. It should be smooth sailing but problems will definitely creep up. I will probably get stuck and will require help. In that scenario I will need to consult somebody with more knowledge than myself. Usually ted, jorendorff and djc are available but if they are not, then there might be issues.
My project doesn’t involve waiting for anything or for anybody to do anything (except when I will be waiting for reviews) so in the end everything is on me to get things working.
|
Project Details
| v0.1 Release Details
|
-
to get pushloghtml working on my machine (some progress made on this part)
-
to locate the source files that dictate the amount of pushlog entries that get displayed and then alter it to display more entries
-
Turns out that there was some miscommunication and I need to add an AJAX scrolling feature that dynamically loads more changesets
-
to add code that allows expand/collapse functionality (apparently all I need is a js lib according to humph)
-
Turns out that there was another miscommunication as Ted has already added this feature. Look here. However the patch has some problems that will need to be fixed. I might fix this for my 0.2 release (undecided for now)
To release v0.1 on time
|
| v0.2 Release Details (More Information) (Final result)
|
-
To continue work on bug 459727
-
Implement a loader GIF (View here)
-
Getting the correct Chronological order when adding more entries OnScroll (View here) (Final result)
-
Getting merge changesets to show up correctly when adding more entries OnScroll (View here) (final result)
-
Making sure the new entries that load OnScroll comply with bug 445560 (Expand/Collapse feature) ==> REMOVED from v0.2 - this functionality should wait until the expand/collapse functionality itself is approved and goes live. This should be a separate bug
-
To make buglinks work
-
To make changeset links work
-
To get the correct date formating
-
On first page load show 20 entries instead of 10 (View here)
-
To get the correct author names (right now, sometimes it returns the email address while other times the name of the author) (View solution here)
-
To fix ted's patch for bug 445560 (View here)
-
To implement "the which files were touched by a changeset" feature for bug 448707 (View here)
|
| v0.3 Release Details (View here)
|
-
Problem with my patch for bug 445560 (View here)
-
Fixed problems with my patch by adding 2 new patches (View here)
-
Fix 1: Should use ids instead of dates
-
Fix 2: Should store unique identifiers in the class instead of the id of the tag
- My patch for bug 448707 approved! (View here)
-
Implementing the Graph view for the pushlog
-
Downloading Dirkjan's (djc) Graph view's source code (View here)
-
Getting djc's Graph view running on my computer (localhost) with hg serve (View here)
-
Understanding how djc's Graph view works (View here) (View here 2)
-
Coding the Graph view for the pushlog
-
1st interation - Make it look similar to the coal template's graph view (View here)
- Final Result of the Graph view (View here)
-
Added bug link feature
-
Formatted correctly to look similar to other gitweb_mozilla pages
-
Added on mouse over tooltip functionality
-
Problem with my patch for bug 459727 (View here) (fix for my patch)
-
To calculate the max use SELECT COUNT(*) FROM ... instead of asking for all the rows and then counting them
-
getMaxEntries called, then 'start' used once the user scrolls. But the user might scroll before the first result comes back, while start is still zero -- a race condition.
-
The JS code isn't consistently indented
-
Patch seems to contain some non-ASCII characters. Bugzilla doesn't render it properly. Consider using an HTML entity reference, like – or —, instead of an actual Unicode character.
-
In a few places the b tag is used where the server uses the strong tag; be consistent
-
Loads more results when the user scrolls. What if the initial results don't fill up the window?
-
Better to move CSS and formatting to stylesheets where possible
-
Problem #1 explained in comment #9 by jorendorff still existed with my new patch (it is fixed, view here)
-
Improved the bug link feature for bug 459727 (View here)
- My patch for bug 445560 approved! (View here)
- v0.3 complete!
|
Project News
| DPS909 Timeline
|
|
September 18th, 2008
- Picked the Mercurial History Browsing project
September 23rd, 2008
September 25th, 2008
September 26th, 2008
September 28th, 2008
September 29th, 2008
October 1st, 2008
October 2nd, 2008
October 3rd, 2008
October 5th, 2008
- Problems with getting pushloghtml to work here. Work in progress...
October 6th, 2008
- Multiple email conversations asking djc and bsmedberg about a "no module found" error relating to simplejson and pysqlite2
October 7th, 2008
October 8th, 2008
October 9th, 2008
October 13th, 2008
October 14th, 2008
October 16th, 2008
October 17th, 2008
- Email conversation asking questions about the json-pushes script
October 18th, 2008
October 19th, 2008
October 23rd, 2008
October 29th, 2008
November 3rd, 2008
November 4th, 2008
November 5th, 2008
November 6th, 2008
November 7th, 2008
November 8th, 2008
November 10th, 2008
November 11th, 2008
November 12th, 2008
- Had a discussion with ted and bsmedberg about the issue explained by the blog post here
- Edited the blog post about not getting the right author name. The edit provides a solution to the problem
- Edited the blog post detailing my problem with ctx.parents()[i].description()
- Chatted with ted about a problem with not getting the correct author name. Sometimes the email was being shown while other times the actual name was showing up
November 13th, 2008
November 15th, 2008
November 16th, 2008
November 19th, 2008
November 24th, 2008
November 29th, 2008
December 1st, 2008
- Had a discussion with jorendorff on the Graph view
- Made celebratory blog post about my patch for bug 448707 being accepted
- Made a blog post about understanding how graph data is passed from the server side to the client side
December 2nd, 2008
- Made a blog post about completing the 1st iteration for the graph (View here)
- Made a blog post about problems identified by jorendorff concerning my patch for bug 459727
December 3rd, 2008
- Added a new patch for hgpoller for bug 459727
- Added a new patch for hg_templates for bug 459727
- Blogged about the above patches here
- Made a blog post explaining a fix concerning a problem with my newly submitted patch (see above) for bug 459727. Problem #1 explained in comment #9 by jorendorff still existed even with my new patch
December 4th, 2008
December 5th, 2008
- Had a chat with jorendorff and ted
- Talked about who should be the reviewer for bug
- Talked about continuing on and working on this project next semester
- Final discussion for the project for this semester
- Made a blog post about another patch of mine getting approved for bug 445560
December 7th, 2008
- Made a blog post about implementing the graph view
- Made a blog post about completing v0.3 release
|
January 2009
| Date
|
|
Comments
|
| January 13th, 2009
|
|
Had a discussion with jorendorff and ted about what I will be working on this semester.
|
Project Bugs
External Links
