What does "#" mean in LCOV report? - lcov

I thought I had covered both cases for the while loop, but brcov doesn't show 100% due to that "#" alert:
hash symbol

From the genhtml man page:
--branch-coverage
--no-branch-coverage
Specify whether to display branch coverage data in HTML output.
Use --branch-coverage to enable branch coverage display or
--no-branch-coverage to disable it. Branch coverage data display
is enabled by default
When branch coverage display is enabled, each overview page will
contain the number of branches found and hit per file or direc‐
tory, together with the resulting coverage rate. In addition,
each source code view will contain an extra column which lists
all branches of a line with indications of whether the branch
was taken or not. Branches are shown in the following format:
' + ': Branch was taken at least once
' - ': Branch was not taken
' # ': The basic block containing the branch was never executed
Note that it might not always be possible to relate branches to
the corresponding source code statements: during compilation,
GCC might shuffle branches around or eliminate some of them to
generate better code.
This option can also be configured permanently using the config‐
uration file option genhtml_branch_coverage.

Related

Mercurial: Most recent change per file

I'm looking for a way to make Mercurial output a table like this:
File Most recent revision changing the file Date of that revision
==== ====================================== =====================
foo.py 44159adb0312 2018-09-16 12:24
... ... ...
This is just like github does it on the "Code" overview page. (screenshot from torvalds/linux):
"Most recent" could refer the date or to the DAG hierarchy relative to the current changeset, or maybe to the current branch. Perhaps the latter is more useful, but in my particular use case, it doesn't make a difference.
I'd also like to be able to provide a list of files or a subdirectory for which I want the table. (I don't necessarily want it for everything)
I am aware that I could do it using a small script, looping over hg log -l 1 <file>, but I was wondering if there is a more efficient / more natural solution.
You won't get around looping over all files. Yet with hg manifest you get that list of files. Then template the output as needed:
for f in $(hg ma); do hg log -l1 $f -T"$f\t\t{rev}:{node|short}\t\t{date|isodate}"; done
This gives output like
.hgignore 38289:f9c426385853 2018-06-09 13:34 +0900
.hgsigs 38289:f9c426385853 2018-06-09 13:34 +0900
.hgtags 38289:f9c426385853 2018-06-09 13:34 +0900
You might want to twiddle more with the output formatting. See the mercurial wiki for a complete overview of output templating.
Git will follow the commit DAG, because that's all it has. In Mercurial, you have (many) more options because you have more data.
Probably the ideal option here is follow(file, .) (combined with first or last as appropriate). But as hg help revset will tell you, you have the following options (I've shrunk the list to the obvious applicable ones):
ancestors(set[, depth])
Use this with the set being . to get ancestors of the current commit, for instance, if you want to do DAG-following a la Git. Or, use ::., which is basically the same.
branch(string or set)
Use this with . to get all commits in the current branch. Combine with other restrictors (e.g., parents) to avoid looking at later commits in the current branch if you're not at the tip of the current branch.
file(pattern)
Use this with a glob pattern to find changesets that affect a given file.
filelog(pattern)
Like file but faster, trading off some accuracy for speed (see documentation for further details).
follow([file[, startrev]])
To quote the documentation:
An alias for "::." (ancestors of the working directory's first parent).
If file pattern is specified, the histories of files matching given
pattern in the revision given by startrev are followed, including
copies.
modifies(pattern)
Use this (with any pattern, not just glob) to find changesets that modify some file or directory. I think this is limited to M type modifications, not addition or removal of files, as there is also adds(pattern) and removes(pattern). Use all three, or-ed together, to find any add/modify/remove operations.
first(set, [n])
last(set, [n])
limit(set[, n[, offset]])
Use this to extract a particular entry out of the revset.
When searching forwards (the default), last(follow(file, .)) seems to work nicely to locate the correct revision. As you noted, you have to do this once per file—it will definitely go faster if you write your own Mercurial plug-in to do this without reloading the rest of the system all the time.
Somehow more efficient / more natural solution can be:
create template|style for desired log output (I can't predict, which way will be better for you)
create alias for hg log -l 1 --template ... or hg log -l 1 --style ...
EDIT
A lot later, more correct solution (from recent discoveries) with hg grep
hg grep "." "set:**.py" --files-with-matches -d -q -T"{files % '{file} {date|age}\n'}"
Part of output in test-repo
hggit/__init__.py 7 weeks ago
hggit/git_handler.py 7 weeks ago
hggit/gitdirstate.py 7 weeks ago
…
You have to modify fileset in order to get results only for part of your tree (for all branches) and, maybe, template in order to fulfill your needs.
I didn't have fileset for selecting "files in branch X" just now, I think, it will be something using revs() predicate
"revs(revs, pattern)"
Evaluate set in the specified revisions. If the
revset match multiple revs, this will return file matching pattern in
any of the revision.
because some not published predicates (according to examples, see # "set:revs('wdir()'..." for referencing working directory) can be used for defining revset and I can't discover/predict the correct form for branch predicate

getting git log output in prettyformat

I have this command:git log --all --pretty=format:'%n{%n "CommitHash": "%H",%n "Author": "%an",%n "AuthorEmail": "%ae",%n "Date": "%ad",%n "Message": "%f",%n},'
Ho can I modify it to get this: "Merge":"....." and this: Merge branch 'master' of ..........
Those 2 things appear when you use the git log --all --graph command, but I trying to put the info that I would get with that command in the pretty format that I put above, and until now I could get everything except those 2 things.
You cannot get the "Merge":"....." with a format: it's simply not available that way.
You can get all the parent hash IDs using %p (abbreviated parent hash IDs) or %P (full parent hash IDs). Note, however, that you will get parent hash IDs of non-merge commits as well. The difference is, of course, that if there are two or more parent hash IDs—these will be separated by spaces—the commit in question is a merge commit.
The Merge branch 'master' of <url> text is simply the body of the commit message, in a merge commit in which whoever made the merge let git pull dictate the body contents. This is available via %b (body only) or %B (subject plus body). Once again, you will get this for all commits, not just merge commits.
If you are attempting to produce valid JSON from arbitrary commits (including message bodies), you should not attempt this solely with --pretty=format:... directives, but rather with an external program that can make any necessary changes to the message-body text so that it does not disrupt the JSON stream. For instance, a commit message body that contains a double quote or a newline will be a problem.

How to trigger an OpenNMS event with thresholds

it seems that it is not possible for me to trigger an event in OpenNMS using a threshold...
first the fact (as much detail as i can)
i want to monitor a html file, better, the content.
if a value is not what i expected OpenNMS should call be.
my html file:
Document Count: 5
in /var/lib/opennms/rrd/snmp/NODE are two files named: "documentCount" (.jbr & .meta)
--> because of the http-datacollection-config.xml
in my logfiles is written:
INFO [LegacyScheduler-Thread-2-of-50] RrdUtils: updateRRD: updating RRD file /var/lib/opennms/rrd/snmp/21/documentCount.jrb with values '1385031023:5'"
so the "5" is collected correctly.
now i created a threshold for this case:
<threshold type="high" ds-type="node"
value="4.0" rearm="2.0" trigger="1" triggeredUEI="uei.opennms.org/threshold/highThresholdExceeded"
filterOperator="or" ds-name="documentCount"
/>
in my collectd-configuration.xml is the threshold also enabled:
in my opinion the threshold of 4 is exceeded, because the value is 5. so the highTresholdEvent should be fired. BUT IT DOESNT.
so i'm here to ask if someone had an idea.
regards dawn
Check collectd.log with the following
tail -f collectd.log | grep -i thresholding
Threshold checking was moved to evaluate while the data is being retrieved a while back as opposed to a post process of rrd files.
Even with the log setting at info you should find some clues as to why the threshold rule is not matching any data.

Mercurial: TortoiseHg configuration to always prompt for manual resolve for all files when merging

We use Mercurial via TortoiseHg with the 'workbench'.
When merging branches, we often find the default (auto?) choice of updates is not what we want. We'd like to configure the tool to always prompt for any merge operation.
Each branch has some core files that we need to keep up to date between the two, but also some branch-specific files which need to be preserved.
If we update the core files in one branch we'd like to do a merge to get the latest core files in the other branch. However the default TortoiseHg makes automatic updates that we don't want.
Examples:
1) Branch '1' contains a file '1.xls' and branch '2' has an equivalent '2.xls' which are stored as binary. Merging '1' into a working directory based off '2' causes a delete of '2.xls' and an add of '1.xls'.
2) Branch '1' contains an updated file 'not_core.c' which has an equivalent 'not_core.c' in branch '2'. Merging '1' into a working directory based off '2' causes an unwanted automatic update of 'not-core.c' in '2'.
3) Branch '1' contains updated files 'core1.c' & 'core2.c'. Merging '1' into a working directory based off '2' causes an automatic update of both files, when we'd prefer a prompt to allow us to chose if these core files are updated. Maybe we want just 'core1.c' for now.
I have seen reference to setting 'mergetool.premerge = false' in mercurial.ini, and have tried some variants of this without success.
The ideal setup would be that the graphical manual resolve is triggered for every file that is different.
Can anyone help with a configuration that supports the functionality described?
Thanks, Ian
Three described cases have different nature in you case, you have to use different tricks for different cases
Cases 2 and 3 (non-conflicting changes in files of ranches) can be covered (TBT!) by disabling auto-merges in TortoseHG (Main menu - File - Settings - Global setting - TortoiseHG - "Auto-resolving merges": False /default - True/)
For case 1 (and other non-content changes - renames, changing attributes) situation is worse and automerge doesn't play: merge mirror history of changes from one branch to another, i.e if in common parent you have only 2.xls, which was deleted|renamed to 1.xls in source branch this change will be reflected in target.
You can try to use different "internal" merge-tool in such merges (when your prefer changes only from one branch - "dummy merge") - internal:local and internal:other. But - they work only for changed content (again!)
Maybe Keep "My" or "Their" files when doing a merge from TipsandTricks section will help (you can join mentioned merge-revert-resolve into new command in [aliases] and use it instead of ordinary merge, when needed)
You can configure this using the merge-patterns and merge-tools sections of hgrc. This set up allowed me to force kdiff3 to be used in my test:
[merge-patterns]
** = noautomerge
[merge-tools]
noautomerge.executable = kdiff3
noautomerge.args = $base $local $other -o $output --qall
noautomerge.priority = 1
noautomerge.premerge = False
This will turn off the automatic pre-merge that Mercurial does and start up kdiff3 instead.
It will do it for all files but it you might be better to amend the merge-patterns section to be a little more specific if that is possible.
Also, be aware of the possibility that your merge tool might automatically resolve the merge itself and if that happens look for command line options to turn that feature off.

Script to adjust history in an RCS/CVS ,v file

In preparation for a migration to Mercurial, I would like to make some systematic changes to many thousands of ,v files. (I'll be editing copies of the originals, I hasten to add.)
Examples of the sorts of changes I'm after:
For each revision whose message begins with some text that indicates a known username (e.g. [Fred Bloggs]), if the username in the comment matches the Author in the ,v file, then delete the unnecessary username text from the commit message
If the ,v contains a useful description, append it to the commit message for revision 1.1 (cvs2hg ignores the description - but lots of our CVS files actually came from RCS, where it was easy to put the initial commit message into the description field by mistake)
For edits made from certain shared user accounts, adjust the author, depending on the contents of the commit message.
Things I've considered:
Running 'cvs log' on each individual ,v file - parsing the output, and using rcs -m to change this history. Problems with this include:
there doesn't seem to be a way to pass a text file to rcs -m - so if the revision message contained singled and/or or double quotes, or spanned multiple lines, it would be quite a challenge quoting it correctly in the script
I can't see an rcs or cvs facility to change the author name associated with a revision
less importantly, it would be likely to start a huge number of processes - which I think could get slow
Writing Python to parse the ,v file, and adjust the contents. Problems with this include:
we have a mixture of line-endings in our ,v files - including some binary files that should have been text, and vice-versa - so great care would be needed to not corrupt the files
care would be needed for quoting of the # character in any commit messages, if it fell on the start of the line in a multi-line comment
care would also be needed on revisions where the last line of the committed file was changed, and doesn't have a newline - meaning that the ,v has a # at the very end of a line, instead of being preceded by \n
Clone the version of cvs2hg that we are using, and try to adjust its code to make the desired edits in-place
Are there any other approaches that would be less work, or any existing code that implements this kind of functionality?
Your first approach may be the best one. I know that in Perl, handling quotation marks and multiple lines wouldn't be a problem. For example:
my $revision = ...;
my $log_message = ...;
system('rcs', "-m$revision:$log_message", $filename);
where $log_message can contain any arbitrary text. Since the string doesn't go through the shell, newlines and other metacharacters won't be reinterpreted. I'm sure you can do the same thing in Python.
(As for your second approach, I wouldn't expect line endings to be a problem. If you have Unix-style \n endings and Windows-style \r\n endings, you can just treat the trailing \r as part of the line, and everything should stay consistent. I'm making some assumptions here about the layout of ,v files.)
I wrote a Python library, EditRCS (PyPi) that implements the RCS format so the user can load an RCS file as a tree of Python objects, modify it programmatically and save to a new RCS file.
You can apply a function to every revision using mapDeltas(), for example to change an author's name; or walk the tree using getNext() for something more complicated such as joining two file histories together.