"""If this is true, something is able to generate pack files that are colliding. This shouldn't really be possible, since if we have the content, we shouldn't think we need to pull it in again.
I guess if you are doing concurrent pulling from the same branch to the same repository, since the first update hasn't finished yet, it doesn't see the content is already present. And the second fetch starts before the first one finishes, doing exactly the same work.
I don't have an immediate solution, but I do think this could be a handle on the problem.
"""
branching the same upstream revision into a shared repository from two branches will generate colliding packs.
I think the race is well analyzed. Possible fixes that come to mind:
- move to obsolete during the critical section
- read-after write [check the pack isn't still present[seems still racy]]
"""If this is true, something is able to generate pack files that are colliding. This shouldn't really be possible, since if we have the content, we shouldn't think we need to pull it in again.
I guess if you are doing concurrent pulling from the same branch to the same repository, since the first update hasn't finished yet, it doesn't see the content is already present. And the second fetch starts before the first one finishes, doing exactly the same work.
I don't have an immediate solution, but I do think this could be a handle on the problem.
"""
branching the same upstream revision into a shared repository from two branches will generate colliding packs.
I think the race is well analyzed. Possible fixes that come to mind:
- move to obsolete during the critical section
- read-after write [check the pack isn't still present[seems still racy]]