Re: [RFC] Introducing different handling for small/large transactions
On Thu, Jan 15, 2015 at 3:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
> Stefan Beller <sbeller@google.com> writes:
>
>> In ref_transaction_commit
>> * commit the .lock file to its destination
>> * in case this is a deletion:
>> * remove the loose ref
>> * and repack the packed refs file if necessary
>
> Don't you need to repack and then remove the loose one, though?
> Otherwise you would expose a stale packed ref in the middle to the
> other readers, no?
Show 22 quoted lines
>
>> The larger transactions would be handled differently by relying
>> on the packed refs file:
>> In ref_transaction_update:
>> * 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
>>
>> * Any update(delete, create, update) is put into the locked
>> packed refs file.
>
> I am not sure if you mean (a) keep updates only in-core, to be
> flushed at the commit time, or (b) each and every update in the
> large transaction results in rewriting the entire packed-refs.lock
> file, only to be renamed to the final name at the commit time.
> I am hoping it would be the former.
I wasn't sure which I mean. The first one is obviously better to do.
Show 7 quoted lines
>
>> * Additionally we need to obtain the .lock for the loose refs
>> file to keep guarantees, though we should close the file
>> descriptor as we don't wand to run out of file descriptors.
>
> Yes, this last point is important.
>
Stefan Beller <sbeller@google.com>