launchpad-dev team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/25/2011 7:45 PM, Max Kanat-Alexander wrote:
> 	Hey folks! The next step for improving codebrowse is to get loggerhead
> trunk running on launchpad. This will require the following things:
> 
> 	1) Improve the test suite coverage for loggerhead so that we have fully
> automated tests that prove that it works, and don't have to worry about
> deploying new technologies into production.
> 
> 	Currently some of the existing tests fail. Also, I suspect that the
> test suite needs more coverage--particularly for all the various
> combinations of options that loggerhead can take. (For example, tests
> should be run with and without the on-disk cache.)
> 

I put together a branch which merges trunk into the pqm branch, and gets
the test suite passing again.

  lp:///~jameinel/loggerhead/merge_trunk

There are still some items which I wasn't 100% clear on

 a) In 'inventory.pt' you deleted the /annotate link, while in pqm it
    was the /view link. I presume this was in favor of the /raw link.
    I went ahead and left both /view and /raw, though from the
    discussion I've followed, it sounds like we want to use /view.

    This means that the formatting on the Inventory page is a little
    bit off. Presumably because of extra links that aren't accounted
    for in the css. (See attached screenshot)

 b) Other small merge conflicts were treated pretty easily. It
    generally amounted to:
     In pqm you changed X => Y, but in trunk that whole section was
     deleted.

 c) Also some conflicts (and one test failure), because ViewUI and
    AnnotateUI now pass around a dict 'values' rather than taking
    individual argument parameters.


This is also missing the one-line patch I wrote against trunk, because I
figured that can easily be evaluated independently.


The tests I ran were:

 bzr selftest -s bp.loggerhead

which I assume covers all of the loggerhead tests. Though I can't
guarantee that. I also tried to walk around to a few pages to make sure
nothing looked broken.

The one link which was *really* slow was: "view changes to this file"
 http://localhost:8080/devel/changes?filter_file_id=ez_setup.py-20090421205932-napgtlfomiuomid3-3

Getting information for ChangeLogUI: 85.644 secs

  On a second run it dropped to:
Getting information for ChangeLogUI: 36.571 secs

  But on the pqm-branch it was:
Getting information for ChangeLogUI: 3.401 secs
Getting information for ChangeLogUI: 2.964 secs

I'm poking at the code, and it is stepping back over the ancestry one
revision at a time, and seeing what revisions were merged by the given
rev, and comparing it to the new revisions we want at each step. I have
a much more efficient query for this in history_db, we just need to use
it. (For the above query, using Querier.get_mainline_where_merged()
takes 20ms to find the exact same revisions that it takes 2-3s for the
existing loggerhead-pqm code and 40s for the dumb
interface-to-history-db code.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1B9d4ACgkQJdeBCYSNAAOvcACeMpgZYF0f7rtYN4xvtF+hkBOo
DQcAni2bv85Cym7XYULdEA6kqBdJcmWZ
=rUCh
-----END PGP SIGNATURE-----

Attachment: inventory_misaligned.png
Description: PNG image