Shawn O. Pearce wrote:
> OK, so I think this is a valid test case, and as it turns out,
> it passes with the library unmodified:
>
> --8<--
> + public void testPathCompare() throws Exception {
> + assertTrue(new FakeTreeIterator("a", FileMode.TREE).pathCompare(
> + new FakeTreeIterator("a", FileMode.TREE)) == 0);
> +
> + assertTrue(new FakeTreeIterator("a", FileMode.REGULAR_FILE).pathCompare(
> + new FakeTreeIterator("a", FileMode.REGULAR_FILE)) == 0);
> +
> + assertTrue(new FakeTreeIterator("a", FileMode.REGULAR_FILE).pathCompare(
> + new FakeTreeIterator("a", FileMode.TREE)) < 0);
> +
> + assertTrue(new FakeTreeIterator("a", FileMode.TREE).pathCompare(
> + new FakeTreeIterator("a", FileMode.REGULAR_FILE)) > 0);
> + }
> ----
Okey, I'll post a new patch with just those test cases, no changes to
the pathCompare, so we at least have those tests.
> Which means whatever problem you have been seeing in the decorator
> code is different than what we were originally thinking. Perhaps you
> are trying to use the tree iterator APIs in a way that they aren't
> meant to be used (like passing in full paths where only a path name
> component is expected?), or there is something else lurking that
> we don't understand.
Ahh, I see. My patch was based on the assumption that 'a/b' was a valid
comparison, since I was seeing similar comparisons in live code. But as
you say, that's probably due to how I use the iterators. I will go back
and investigate how I ended up with 'a/b' paths in the first place.
Thanks :)
Tor Arne
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
