loggerhead navigation

[Michael Hudson]

Robert Collins wrote:
> 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

Right.

> 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.

Right.

> So, without dropping down into specific use cases, I think
> loggerhead needs to allow one to not use:
> bzr log

I think this is more-or-less covered, especially if we get the display
of merged revisions done right, as mentioned in some other thread.

> bzr annotate

Duplicating the functionality of raw "bzr annotate" isn't very hard,
or much of a goal, imho.

> bzr viz

This one is harder :)

I wonder if it could be done without resorting to dynamically
generated image maps.

> bzr info

There's nothing like this now, but there's no reason there couldn't
be, I guess.

> bzr diff

Covered, I think, though not in full 'arbitrary revisionspec' glory.

> bzr grep

This sounds expensive -- you'd have to extract the fulltext of each
file in a particular revision?

> and still get things done.

I agree this is a good way of framing the goal.

> 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.

Well, modulo the fact that loggerhead is a pain to set up (a different
issue, IMHO), yes.

> 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).

This goes back to what I was saying about duplicating raw 'bzr
annotate' not being a very ambitious goal, I guess :)

I can think of some interesting things to do here, but lets get the
basic stuff right first.

> 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 :).

So we should add 'bzr missing' to the above list?

Loggerhead certainly considers each branch to be an island currently.

> 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.

You mean entire revision graph should be merge sorted?  I think that
could work, especially with ways to jump across to the next mainline
revision and so on... hm.

Thanks for the thoughts.

Cheers,
mwh