On Tue, Jun 20, 2023 at 09:43:46AM -0400, Derrick Stolee wrote:
This version is not ready. The backwards compatibility story is
incomplete.
I'm also late to the party, but I agree with Stolee here, having come to
the same conclusion about needing to support reading older (corrupt) Bloom
filters when possible (i.e. when paths contain no bytes which have their
high-order bits set), and assuming the filter contains all paths
otherwise.
commitGraph.changedPathsVersion: Which version should we _write_
when writing a new commit-graph? Defaults to '1' but will default
to '2' in the next major verion, then '1' will no longer be an
accepted value in the version after that.
I am not sure if there's a situation where we'd ever want to not write
the newer versions when starting a new commit-graph (or chain) from
scratch.
I think that follows from what you and I are both suggesting w.r.t
backwards compatibility. If that's the case, I think that we could in
theory drop this configuration setting altogether.
Or, at the very least, we should be able to change it change only what
version we *write*, not read. I think this is what you are suggesting
above, but I am not 100% sure, so apologies if I'm just repeating what
you've already suggested.
The tricky part is that during the commit-graph write, you will
need to check the existing filter value to see if it matches. If
not, the filters will need to be recomputed from scratch. This
will change patch 4 a bit, but it's the right thing to do.
Yup, good suggestion.
Thanks,
Taylor