loggerhead navigation

[Robert Collins]

On Tue, 2008-03-11 at 18:00 +1300, Michael Hudson wrote:
> So I've spent a little while trying to clean up loggerhead's navigation, 
> which has always confused me a bit.
> 
> The idea I've been working with is for every page to be 'contained' in 
> some sense in, or at least associated with, some possibly filtered line 
> of revisions.  So for example, the front page view is rather easy: it's 
> just the mainline of the branch with no filtering.  Clicking on the 
> 'changes' link next to a file takes you to a view that shows which 
> mainline revisions merged revisions that changed the file.  If you look 
> at a revision that was merged in to the mainline of the branch, then the 
> line of revisions is taken by working backwards along the chain of 
> leftmost parents.  This all seems to work reasonably well, and means 
> that every view can have a previous and next link in a sensible way and 
> so on.

One of the things I find annoying about current history viewers is that
they are little more than a flat view of the history
- /revs/revision/path, and /paths/path/revision

At the sprint I described my desire for a web interface as 'google maps
for vcs data'. Putting aside the interesting but not that useful idea of
exporting the vcs history as map tiles, what do I mean? As a web history
viewer, loggerhead is a proxy for [currently readonly only] bzr client
operations. So, without dropping down into specific use cases, I think
loggerhead needs to allow one to not use:
bzr log
bzr annotate
bzr viz
bzr info
bzr diff
bzr grep

and still get things done.

Heres an interesting use case as a what-if: I have a file foo.c on local
disk. I want it annotated - can we do that with loggerhead.

Another one: I'm looking for a missing line, how can I find it? (I guess
its select two lines in an annotated view and expand them somehow).

Another: I'm looking at branch X, great related data would be to see how
much of X is new versus X's submission location - and note that ideally
I don't have to have both branches managed by the same loggerhead :).

In response to the specific question you asked, I think that within a
branch the same revision ordering used by bzr should be used by
loggerhead, and used consistently. All the file versions will be in
history, so this is reasonable to do.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080313/36903583/attachment.pgp