Hm, on second thoughts, does BufReader<BufWriter<File>> actually work? Suspect not.

I think the encode/decode should be factored out more, but I'll leave that up to you.

z

I stopped following the code around PathRecurse handling - I assume its implementing a chunk of Mercurial-defined logic.

Nits mostly.

I couldn't find any existing unit tests to update.

Getting more fancy, you could define VLQEncode/VLQDecode traits, then implement them for u64 and i64 (with zigzag), and perhaps other integer types if it makes sense/is useful.

In D698#12222, @durin42 wrote:

I can't see that keeping Debian releases possible. In my view if "no more than 2 or 3 stable releases" is a hard requirement for rust, we may as well stop having the discussion now.
(Alternatively: convince me with documented success cases that binaries built by a newer Rust than is in a given Debian release are somehow plausible and acceptable.)

I don't have any particular opinion about which Python binding to use - they all seem a bit rough. I think there's some interesting scope for doing things like using custom derive to automate converting between Rust and Python representations, and iterators/futures/generators to do the conversions of large structures lazily.