loggerhead navigation

Michael Hudson michael.hudson at canonical.com
Wed Mar 12 23:57:02 GMT 2008


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



More information about the bazaar mailing list