Wolfgang Hoschek

I think that's what the DEBUG level is intended for, conceptually. If all third party libs would log.info() in debug related places there'd be a sea of distractions in everyone's...

@allanjude @behlendorf Indeed, please don't let this PR die. It's really needed a lot. FYI, I figured out an awfully hacky workaround for my backup setup where a ZFS pool...

Yes, indeed. Wolfgang. On Dec 15, 2011, at 1:25 PM, Tatu Saloranta wrote: > Hmmh. Actually, checking complexity again (re-reading code I wrote), am I missing something if I suggested...

I think a java.util.PriorityQueue would work just fine, no? At least that's what we ended up using for our external merge sort impl a few years ago. BTW, every time...

Just for reducing code I guess. I think they're all binary heap impls with the same performance characteristics. Here is an outline of how we reuse the entries: ``` /**...

The comparison function may be expensive and so reducing the number of comparisons (e.g. with a log n PriorityQueue) is important. Also, I think because external merge sort works with...

I agree! In addition would be great to exclude all files (not just directories) that match at least one of a given set of file name patterns, for example: `--exclude...

Would invite so much more use and experimentation!

@aliFrancis Yeah, a simple python file with a set of functions would be great! For example along the lines of [01-Major-TOM-Filter.ipynb](https://github.com/ESA-PhiLab/Major-TOM/blob/main/01-Major-TOM-Filter.ipynb) or similar.

If something that isn't tightly integrated is ok, you could easily build something like this by grepping the output of `bzfs --compare-snapshot-lists`.