[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: binary file size limit? (4.2GB retry - success)

From: Travis P <svn_at_castle.fastmail.fm>
Date: 2004-03-12 17:17:15 CET

On Mar 12, 2004, at 8:20 AM, Ben Collins-Sussman wrote:

> C.A.T.Magic wrote:
>
>>> 1. copy the working file to .svn/tmp/, in case the user changes it
>>> during the commit. if eol or keyword translation is on,
>>> 'detranslate'
>>> these things when copying.
>> in my test case it was a binary file and no keywords on,
>> so this was a pure copy, nothing was modified.
>> so maybe skip this pass on binaries-without-props?
>
> No, read what I wrote: what if the user changes the file while you're
> streaming it over the network? We *cannot* simply push the working
> file over the network. We need to push a copy of it that is out of
> the user's sight. The translation stuff is just a sometimes thing;
> the copy needs to be made regardless. We're either going to do a
> straight copy to .svn/tmp, or a 'translated' copy. But the copy has
> to happen.

>>> 4. the client gets the new revision number from the server; it then
>>> copies the .svn/tmp/ file into .svn/text-base again.
>> here too, no need to copy the non-modified binary-file-without-props
>> back into the repos. it's already there.
>
> I think you mean, "copy back into the working copy"?
>
> Anyway, the thing that got committed is now the new .svn/text-base/.
> It needs to get into .svn/text-base/ somehow. This is not an optional
> thing.

Couldn't svn be using /tmp for temporary files on systems that support
such a thing? If the WC is on a shared network volume, using .svn/tmp
will generate a lot of unnecessary fs overhead (and is thus much
slower). On the other hand, given the statements about (4), maybe that
temp file could be moved/renamed to become the text-base file rather
than yet another copy. Maybe this is already done efficiently and I'm
just unaware of that and misreading this conversation.

-Travis

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 12 17:25:56 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.