Git development
 help / color / mirror / Atom feed
From: Martin Fick <mfick@codeaurora.org>
To: repo-discuss@googlegroups.com
Cc: jmelvin@codeaurora.org, jgit-dev@eclipse.org, git@vger.kernel.org
Subject: Re: Preserve/Prune Old Pack Files
Date: Wed, 04 Jan 2017 09:11:55 -0700	[thread overview]
Message-ID: <5172470.bsscxDU4yv@mfick1-lnx> (raw)
In-Reply-To: <24abd0ed58c25ce832014f9bd5bb2090@codeaurora.org>

I am replying to this email across lists because I wanted to 
highlight to the git community this jgit change to repacking 
that we have up for review

 https://git.eclipse.org/r/#/c/87969/

This change introduces a new convention for how to preserve 
old pack files in a staging area 
(.git/objects/packs/preserved) before deleting them.  I 
wanted to ensure that the new proposed convention would be 
done in a way that would be satisfactory to the git 
community as a whole so that it would be more easy to 
provide the same behavior in git eventually.  The preserved 
pack files (and accompanying index and bitmap files), are not 
only moved, but they are also renamed so that they no longer 
will match recursive finds looking for pack files.

I look forward to any review (it need not happen on the 
change, replies to this email would be fine also), in 
particular with respect to the approach and naming 
conventions.

Thanks,

-Martin


On Tuesday, January 03, 2017 02:46:12 PM 
jmelvin@codeaurora.org wrote:
> We’ve noticed cases where Stale File Handle Exceptions
> occur during git operations, which can happen on users of
> NFS repos when repacking is done on them.
> 
> To address this issue, we’ve added two new options to the
> JGit GC command:
> 
> --preserve-oldpacks: moves old pack files into the
> preserved subdirectory instead of deleting them after
> repacking
> 
> --prune-preserved: prunes old pack files from the
> preserved subdirectory after repacking, but before
> potentially moving the latest old pack files to this
> subdirectory
> 
> The strategy is to preserve old pack files around until
> the next repack with the hopes that they will become
> unreferenced by then and not cause any exceptions to
> running processes when they are finally deleted (pruned).
> 
> Change is uploaded for review here:
> https://git.eclipse.org/r/#/c/87969/
> 
> Thanks,
> James

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation


       reply	other threads:[~2017-01-04 16:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <24abd0ed58c25ce832014f9bd5bb2090@codeaurora.org>
2017-01-04 16:11 ` Martin Fick [this message]
2017-01-09  6:21   ` Preserve/Prune Old Pack Files Jeff King
2017-01-09  7:01     ` Mike Hommey
2017-01-09 10:55       ` Jeff King
2017-01-09 16:20         ` Martin Fick
2017-01-09 16:17     ` Martin Fick
2017-01-10  9:14       ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5172470.bsscxDU4yv@mfick1-lnx \
    --to=mfick@codeaurora.org \
    --cc=git@vger.kernel.org \
    --cc=jgit-dev@eclipse.org \
    --cc=jmelvin@codeaurora.org \
    --cc=repo-discuss@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox