Do not require the source files when merging coverage data

[deviantintegral]

I was attempting to merge coverage reports on a different machine than what generated them, and I was ending up with empty reports. It looks like the filter does a file_exists() check on each file, which was failing for me.

Is there some reason we have to validate the file exists, instead of just assuming the file names are valid? If so, it would be good if here or in the phpcov CLI tool the 'merge' command documented this caveat.

[sebastianbergmann]

Yes. Once #386 is implemented it should be possible to perform the merge operation without the source files.

[cooperaj]

I've been attempting to use phpcov to merge coverage reports built in CI containers into a single report that I can push to Coveralls and have hit upon this issue. Because the source files are in a different location in the particular context that this CI task runs it's unable to find the files and is giving me empty reports.

I have looked through the code and hope to build a workaround by rewriting the file paths in the CodeCoverage object but this would be a much better solution.

[cs278]

I currently workaround this using sed -i "s,'$(pwd)/,getcwd().'/,g" output.cov, however changes on master are going to make this impossible: be7e048

[cooperaj]

This is what I ended up with https://github.com/cooperaj/php-coverage-path-fixer. Shouldn't be affected too much by that change.

I mean, it'll break horribly, but the technique is sound and it'll be fixable.

[cs278]

I mean, it'll break horribly, but the technique is sound and it'll be fixable.

Unfortunately you will need to resort to reflection to get access to all of the properties that need fixing.

@sebastianbergmann Now that the coverage data is stored as serialized objects this problem is harder to workaround. Is there anything that could be added to the library to allow people to rewrite a common path prefix in one go without having to mess around with reflection?

[AndrewFeeney]

If I'm understanding the problem properly, storing the paths as relative paths as suggested in this issue #925 might mitigate this issue for some people if all that is different is the root project path, and the files are still present on the second system. Though, I appreciate that's a less fundamental solution to the problem it might be easier to implement and solve 80% of use cases.

I'd be happy to have a look at putting in a PR if @sebastianbergmann has appetite for that?

[sebastianbergmann]

I am sorry for the messy situation that I created here.

#925 (and sebastianbergmann/phpcov#115) are in the way of merging code coverage reports that were generated for the same code but on different systems / in different paths. The best way to address this issue, I think, would be to change the merge() method: find the base path for paths in $this, find the base path for paths in $that, map between the two.

To address sebastianbergmann/phpcov#109, we need a PR that implements #874 for serializing a ProcessedCodeCoverageData object to a file and vice versa without relying on serialize() / unserialize().

To address this issue, we need a PR that implements #386, and I have honestly no idea how that problem could be tackled. Ideas, or better yet: patches, welcome.