User Details
- User Since
- Oct 17 2018, 3:58 AM (17 w, 5 d)
Fri, Feb 15
Wed, Feb 13
Tue, Feb 12
@yuja I'm trying to find a compromise between our points of view : I'd like very much it to be run automatically (hence an integration test), and you want to be parametrizable. So, I'm pushing a version that has these two properties, working with env variables, since command-line arguments are already used by the testing framework. Hope it'll suit you, if it doesn't, I'll put it in examples and find a way to run it anyway
Tue, Feb 5
@yuja we don't need a seed to reproduce: failed examples contain all the information (that's a difference with the Python version)
Mon, Feb 4
@yuja now that 4.9 is out, I'm getting back to this.
Fri, Jan 25
Jan 16 2019
@yuja the doc you're linking is about integration tests, so it wouldn't apply to these tests which are really unitary in my mind. Usually the main difference would be the access to the private constructs that the integration tests can't perform, but it's true that most of these implementations are public anyway.
Jan 14 2019
@yuja I talked with @lothiraldan about this today. It turns out that it'd be better to provide a basesheads returning a set directly from the MissingAncestors object (I do have a Rust implementation for heads).
Jan 11 2019
Jan 10 2019
Jan 5 2019
Jan 4 2019
@yuja this new version exports the LazyAncestors name to Python, expecting revlog.ancestors to do the right thing (as a factory then). I agree that the destiny of the older rustlazyancestors is to disappear, but I'd prefer to wait a bit before doing that
@kevincox I'd agree in principle, but since we only have one caller, whose role is precisely to abstract those differencies, we decided that we actually don't need to maintain that convention (and rustext can ne considered a foreign module, so that this is not really a breaking of the naming convention for new classes within hg)
Dec 27 2018
@yuja about the lazy importer, and just to clarify: so you're saying it's not worth it to delay until rustext is actually used. I'm fine with that, will do it.
I didn't amend that patch yet, but you might have received notifications due to evolve of the whole stack.
Does the class name actually matter? Personally I don't care if
lazyancestors() function returns a LazyAncestors object. We'll anyway
need a wrapper function to make pure ancestors and rustext ancestors
compatible.
@yuja, thanks for the queueing !