Re: [PATCH 05/15] refs.c: update rename_ref to use a transaction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 28, 2014 at 12:56 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Ronnie Sahlberg <sahlberg@xxxxxxxxxx> writes:
>>
>>> commit 0295e9cebc41020ee84da275549b164a8770ffba upstream.
>>>
>>> Change refs.c to use a single transaction to copy/rename both the refs and
>>> its reflog. Since we are no longer using rename() to move the reflog file
>>> we no longer need to disallow rename_ref for refs with a symlink for its
>>> reflog so we can remove that test from the testsuite.
>>
>> Do you mean that we used to do a single rename(2) to move the entire
>> logfile, but now you copy potentially thousands of reflog entries
>> one by one?
>>
>> Hmmmm,... is that an improvement?

I think so. It makes to code a lot simpler and more atomic. As a side
effect it removes restrictions for symlink handling and eliminates the
two renames colliding race.
Though, a read and then rewrite thousands of reflog entries will be
slower than a single rename() syscall.

>
> I see some value in "keep the original while creating a new one,
> just in case we fail to fully recreate the new one so that we can
> roll back with less programming effort".  But still, we should be
> able to copy the original to new without parsing and reformatting
> each and every entry, no?

Is renaming a branch with a long history is such a frequent or time
critical event?
I timed a git branch -m for a branch with ~2400 log entries and it
takes neglible time :
  real 0m0.008s
  user 0m0.000s
  sys 0m0.007s


During the special rename case, we are deleting one ref and creating
another. For cases such as m->m/m or the reverse we must delete the
old file/directory before we can create the new one.

The old rename code did this by renaming the file out to a common
directory and then back to the new location. Which is fast (but a bit
...)
The alternative is to read the old file into memory, delete it and
then write the content back to the new location, which is kind of what
the new code does.

If this turns out to be a bottleneck we can change the io when writing
the reflog entries to use fwrite(). Lets see if there is a problem
first.

regards
ronnie sahlberg
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]