On Thu, Jan 15, 2015 at 02:36:11PM -0800, Stefan Beller wrote: > So for here is my proposal for small transactions: > (just one ref [and/or reflog] touched):
The implication being that a "large" transaction is any with more than one update. I think performance may suffer if you do not also take into account the size of the packed-refs file. If you are updating 5 refs and there are 10 in the packed-refs file, rewriting the extra 5 is probably not a big deal. If there are 400,000 in the packed-refs file, it probably is. I'm not sure where the cutoff is (certainly the per-ref cost is less for packed-refs once you have started writing the file, so there is probably some crossover percentage that you could measure). > * detect if we transition to a large transaction > (by having more than one entry in transaction->updates) > if so: > * Pack all currently existing refs into the packed > refs file, commit the packed refs file and delete > all loose refs. This will avoid (d/f) conflicts. > > * Keep the packed-refs file locked and move the first > transaction update into the packed-refs.lock file This increases lock contention, as now independent ref updates all need to take the same packed-refs.lock. This can be a problem on a busy repository, especially because we never retry the packed-refs lock. We already see this problem somewhat on GitHub. Ref deletions need the packed-refs.lock file, which can conflict with another deletion, or with running `git pack-refs`. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
