On 5/2/2019 2:02 PM, Ævar Arnfjörð Bjarmason wrote:
>
> But those are separate from any back-compat concerns, which is what I
> think makes sense to focus on now.
Thinking more on this topic, I think I have a way to satisfy _all_ of
your concerns by simplifying the plan for incremental commit-graph files.
My initial plan was to have the "commit-graph" file always be the "tip"
file, and it would point to some number of "graph-{hash}.graph" files.
Then, we would have some set of strategies to decide when we create a new
.graph file or when we compact the files down into the "commit-graph"
file.
This has several issues regarding race conditions that I had not yet
resolved (and maybe would always have problems).
It would be much simpler to restrict the model. Your idea of changing
the file name is the inspiration here.
* The "commit-graph" file is the base commit graph. It is always
closed under reachability (if a commit exists in this file, then
its parents are also in this file). We will also consider this to
be "commit-graph-0".
* A commit-graph-<N> exists, then we check for the existence of
commit-graph-<N+1>. This file can contain commits whose parents
are in any smaller file.
I think this resolves the issue of back-compat without updating
the file format:
1. Old clients will never look at commit-graph-N, so they will
never complain about an "incomplete" file.
2. If we always open a read handle as we move up the list, then
a "merge and collapse" write to commit-graph-N will not
interrupt an existing process reading that file.
I'll start hacking on this model.
Thanks,
-Stolee
