Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[M155] Update Git, drop MIDX writes #1422

Merged

Conversation

derrickstolee
Copy link
Contributor

This PR does two things:

  1. Updates Git to include the slow commit-graph write fix from commit: remove parse_commit_no_graph() git#168. Also see [M153 Hotfix] Update Git to revert slow commit-graph write #1420 for the M153 hotfix.

  2. Removes the multi-pack-index writes from the PostFetchStep and instead only writes the multi-pack-index during the PackfileMaintenanceStep. In order to get the most out of the step, we need to ensure we have a multi-pack-index before running the expire and repack steps. Also, we can only expire the packs from that day if they are contained in the multi-pack-index.

If we agree that we should send (2) as a hotfix to the M155 release (in addition to (1), which is necessary), then I'll create a hotfix PR to that branch.

See microsoft/git#168 for full details.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
The multi-pack-index write is taking a lot of memory. Instead of
writing it with every prefetch (every hour) let's write it during
the packfile maintenance step (once a day).

This will lead to a few packs not covered by the multi-pack-index
between runs, but that will not be a huge loss to
performance.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
@derrickstolee
Copy link
Contributor Author

Related: #1421

}

string multiPackIndexLockPath = Path.Combine(this.Context.Enlistment.GitPackRoot, MultiPackIndexLock);
this.Context.FileSystem.TryDeleteFile(multiPackIndexLockPath);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see we were doing this before too, but why do we always try to delete the lock file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Git will fail if the .lock file exists, as it thinks another process is writing to that file. It does not inspect handles.

So, if a power-outage killed our Git process, then that user would never get an updated midx without this deletion of the .lock file.

We use the shared object cache lock to avoid multiple processes modifying this data.

@derrickstolee derrickstolee merged commit acc1fc2 into microsoft:releases/shipped Aug 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants