I suspect the problem here isn't about working copy efficiency, it's
the fact that we delta-encode every file that gets stuffed into the
repository, even if it's something as simple as committing a file to a
local file:/// repository. That takes a lonnnnnnnng time on huge
binary files.
On 8/28/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> On 8/28/06, Jeremy Cook <jeremy.cook@bccs.uib.no> wrote:
> > Thanks for the feedback, It wasn't all that obvious that I could solve
> > this by using a newer APR by googling and reading the FAQ. Large files
> > are mentioned in the FAQ, but not quite in a way that led me to a
> > solution.
>
> I'll take a look at the FAQ and see if I can find a place to mention
> the APR version issue.
>
> > Anyway I have now reinstalled using newer APR and APR-util and it does
> > indeed seem to be working with 2GB and 3GB files. However it all takes
> > so long using svn with these AVI files that I might find some other
> > way...
>
> For what it's worth, I believe there have been some changes in
> Subversion 1.4.x (not out yet, but real soon now) that may help this a
> bit. There are a few parts of the working copy library that now do
> things in a streaming manner instead of using multiple passes over a
> given file (writing it to disk in between steps). Not sure if that'll
> matter for your use case.
>
> Additionally, if you have a use case which is much faster in another
> system, I believe Dan Berlin recently mentioned on this list that he
> was curious about such things, and would be willing to try to make the
> necessary changes to Subversion to speed it up for those use cases, if
> he could get some test cases to work with.
>
> -garrett
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 28 15:20:16 2006