On Mon, May 20, 2013 at 10:23:24PM +0200, Mattias Engdegård wrote:
> When trying to consolidate file copying into svn_io_copy_file, I ran
> into the code around workqueue.c:590 which derailed my plans somewhat:
>
> /* With a single db we might want to install files in a missing
> directory.
> Simply trying this scenario on error won't do any harm and at
> least
> one user reported this problem on IRC. */
>
> Apparently added in r1142088, the exact motivation behind the code
> remains somewhat unclear. Does anyone remember precisely what prompted
> it, and what, if anything, it is needed for today? (The "won't do any
> harm" and "at least one user reported this problem on IRC" parts are
> red flags here; those phrases suggest that the code attempts to do
> more than promised, and that's almost as bad as not doing enough.)
>
Have you checked IRC logs for the day r1142088 was committed on?
> The reason why it is troublesome is that it makes it hard to use
> svn_io_copy_file for the "atomic copy" (copy to temporary + rename)
> pattern in run_file_install, since the "helpful" code attempts to
> create some missing directories if the final rename fails, and then re-
> try the rename.
>
> But we want svn_io_copy_file to take care of it, because it already
> does an atomic copy, and it appears fairly clearly to be the right
> place for any file copy improvements. Of course we could use
> svn_io_copy_file for an atomic copy to a temporary, and then a second
> rename to the final destination, but that would be wasteful and silly.
>
Just for clarify, I assume you want to make run_file_install() use
svn_io_copy_file() when translation (keyword expansion, etc) is not required?
And when translation is required, you would... retain the current "translate to
tempfile and atomically rename" approach?
Daniel
> Why improve file copying? Because it consumes a fair bit of time and I/
> O bandwidth of many operations, such as checkouts and updates. In
> addition, exact file copies account for almost half the disk space
> used by a working copy, and being able to use fast and space-
> conserving COW copies where available would be nice.
>
> There are also possibilities of server-side file copies (NFSv4.2,
> SMB2) as well as new client-side file copying APIs (win32 has
> CopyFileEx; copy_range or something similar may be coming to Linux).
>
Received on 2013-05-20 22:41:06 CEST