Issue #31 resolved

P1D1::The graph jiggles back and forth sometimes.

Blake Winton
created an issue

Clone http://hg.mozilla.org/comm-central/ Scroll down to revision 5624. Then, very slowly, scroll down to revision 5620. Notice how the line pops in and out as you go back and forth between those two revisions.

Thanks, Blake.

Comments (30)

  1. Jason Harris repo owner

    Ahh... Not a bug, or at least something that I don't see how to change. Just like Mercurial, when I do a graph representation I only look so far into the future and so far into the past. If not sometimes for a big repository there would be say 1000 different branchings and all the branches in the graph would be squished to the left.

    Thus the graph has to be a local graph. And the graph extends off screen by a certain count which seemed appropriate in testing... I think its 10 revisions forward and 10 back or something I could look up the code...

    Then simply when you are scrolling at one point the graph is a straight line with no branchings, and then a little later when you scroll down a bit, the graph has branchings (or vice versa), so horizontally the graph is shifted. Thus the jiggling is intentional.

    Resolution: As designed. (I wish I could change bitbuckets classification from invalid but its the closest thing that matches.)

  2. Blake Winton reporter

    Perhaps the graph has to be a local graph, but I think that if you have data from a previous scroll, you could use it to get things to move around less.

    Also, is there a way for me to find out what calls you're making to get the data that you use to create the graph? I'ld like to look through it by hand, and see what's changing.

  3. Anonymous

    I agree with Blake; this is a serious usability problem that doesn't need to be there (see Murky.app for example, or any number of similar history viewers for Git). A related problem is that the colors assigned to individual branches/heads aren't kept consistent.

  4. Jason Harris repo owner

    Dave, can I get you to file a new bug about the color of the branch. That is a bug and can be made to work. The problem with keeping the graph static in its columns is that in bigger repositories there is often many many branches in parallel. Especially if it is a busy repository. If you have the width of the graph being defined by the maximum branches the branches soon all bunch up into just one thin line. (I originally had it static but when I went looking at large systems all the history got scrunched up.)

    The graph *has* to be local to deal with larger systems. Murky currently can't deal with larger systems at all. Eg try opening http://hg.services.openoffice.org/hg/DEV300 in murky and it just hangs. I will post the example system I used which had a ton of branchings to illustrate this point later...

  5. Blake Winton reporter

    I (still) think you could keep old data around to use when calculating the position of branches, and reduce the jiggle quite a bit that way.

  6. Jason Harris repo owner
    • changed status to open

    Ok... Ok... :) :) I'll think about how we can do this if we have a continuous connection from one point to another. But for instance if the repository has some 200,000 changesets, if you jump to the middle you just do not have the time to build the full graph for 200,000 changesets and still be vaguely interactive in your responses.

    Thus at the very least the graph has to start locally... I think I can code it so it stays the same color, I am just not sure about the jiggling:

    The code is all in

    - (void) computeColumnsOfRevisionsForLimits:(LowHighPair)limits
    

    Which basically starts at the highest revision in the limit and works its way down to the lowest revision in the limit. The limits are determined in:

    - (LowHighPair) logGraphLimits
    

    And in here I can probably look at where we have been historically.

    Or I could cache the column of the node, but doing this gives other undesirable behavior... One consequence is that the main "trunk" is not always in column zero... But I have heard the complaints... I'll do something ;)

  7. Paul Sargent

    I just wanted to say that this is a major issue for me, although I understand it's not necessarily easy to fix.

    As the repo I work with is very branchy, the dancing graph makes it impossible to follow a branch back to its source. The changing order of branch thread is especially jarring, but even just adding/removing threads sends my head for a loop.

    I don't care if the diagram is consistent if I jump from revision to revision, but it must stay consistent, or at least animate removing / adding a branch, while scrolling.

    Anything as long as it allows branches to be traced by eye when they run over several screens.

    May I suggest http://www.selenic.com/repo/linux-2.6/ as a good test repo.

  8. Jason Harris repo owner

    Thanks for your comment... I'll definitely try and fix this somehow... I just don't know exactly how yet :) On the repo example you gave with some 200,000 commits its one of those examples where you just can't precompute the entire graph before drawing local history... I'll think of something :)

    Thanks, Jas

  9. Anonymous

    I would think that if you stored the position and colour of the nodes you had calculated, then you could use that when calculating what position and colour new nodes should get.

    (And if you can point me at the code that tries to determine all of this, I'll be happy to take a stab at it.)

    Thanks, Blake.

  10. Jason Harris repo owner

    Its in - (void) computeColumnsOfRevisionsForLimits:(LowHighPair)limits in /Development/MacHgDev/MacHg/Classes/LogEntryModel/LogGraph.m

    I think this will be slightly tricky... You will have to cache this in the RepositoryData structure, and clear it when this gets re-initilized.

    Good luck & Thanks!! Jas

  11. Jason Harris repo owner

    Ok I have done work on this. It has basically required a complete rewrite of LogGraph.m and I have something going now but it still has bugs in it, eg the incomplete revision is not totally correct, and a few other things. But sometime in the near future I'll release a new version with these changes...

  12. Anonymous

    I just wanted you to know that this is a complete deal breaker for me. I'm not trying to be a ungrateful or harsh, MacHg is the best Hg client for Mac hands down, but this problem makes it almost useless, because as other have said, you can't follow a branch, you simply get lost because of all the jumping. If you work with several people, following branches to their source is essential. As it is I have to resort to hg serve to get a clear picture of the repo.

    I'm used to TortoiseHg in both Windows and Linux and it works perfectly in this regard. Maybe it has to do with Tortoise only loading a subset of the changesets at a time. Perhaps you could take a look at their code.

    Again, please don't take it the wrong way, you've done a great work, but this is a very important issue.

  13. Anonymous

    I'd also like to state that me and my colleagues find the graph very beautiful but of limited usefulness since the jiggling makes it impossible to follow a branch. Have to fall back to "hg log -G" for that. If you could improve on this issue we'd be really grateful. Maybe it's possible to chose the color according to the branch, so that at least the color is consistent, that would already help a lot. Thanks a lot.

  14. Log in to comment