On Mon, 04 Oct 2010, Roman Chyla wrote:
> i wanted to see the two installations and compare them and run
> profiling
This looks very much like what I'm doing when merging, for example.
Sometimes/often I want to check if a new feature branch does not bring
some new kwalitee issues with itself. To take today's example of Joe's
#296, I do:
$ cd modules/websearch/lib
$ git-check-kwalitee-change master tmp-joe-296 \
./search_engine_query_parser*.py
which performs behind the scenes roughly the following:
- checkout master
- install (WebSearch lib only)
- run kwalitee tests on query parser files
- checkout Joe's #296 branch
- install (WebSearch lib only)
- run kwalitee tests on query parser files
- compare the two (ignoring line numbers[1])
- report whether we have same/more/less kwalitee issues
- checkout back the branch I was in before I launched the checks
- reinstall it back
It takes precisely 21 seconds on my laptop to do all this for Joe's #296
branch, and it helps me to verify that the branch is fully OK from this
point of view.
Naturally, you can run keyword extraction and profiling and whatnot
while branches are being switched, as needed. Since you basically do
not need to edit the older bibclassify version (I presume?), then this
type of branch switching technique could be cheap for your as well.
Unless you do more things than only comparing results and profiles?
> But we can have a look, sure
Don't hesitate, if you want.
[1] Comparing stuff while trying to fuzzy-ignore line numbers is
necessary due to code movements, but it is not ideal since it could
mask some kwalitee movements too. Ideally, our codebase should be
kwalitee warning free, which would enable a stricter comparison and
a better Bitten green/red flags and stuff. Our hackathons should
help us with this, but we are progressing slowly in this department.
Anyway, let me send another email on this topic.
Best regards
--
Tibor Simko
