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

RE: Switching off file compression for JPEGs in the repository

From: Cassimatis, Jim <Cassimatis_at_ali.com.au>
Date: 2004-11-17 06:36:19 CET

You hit the nail on the head. We need tuning options for large
files. Also, I agree that the pristine copy could in fact be part
of the problem. Where do we go from here?

Jim C
-----Original Message-----
From: Mike Mason [mailto:mgm@thoughtworks.net]
Sent: Wednesday, 17 November 2004 4:17 PM
To: Cassimatis, Jim
Cc: 'users@subversion.tigris.org'
Subject: Re: Switching off file compression for JPEGs in the repository

Cassimatis, Jim wrote:

>Yes, I have a specific problem. The problem is that we have some
>very large JPEGs (around 1GB) and the time taken to check
>them in is very long (more than an hour) so if I could prevent
>Subversion from running the file through it's binary differencing
>algorithm I imagine it would check-in much more quickly.
>
>
>
Is the problem with adding new files, or checking in new versions of
existing files? When things are slow, during the hour-long operation,
what's happening on the client and server machines? If you're using
Windows, you can use Task Manager to look at CPU and network usage
(right click the task bar at the bottom of the screen and choose Task
Manager).

It sounds like you might be trying to do stuff that Subversion isn't
very good at -- for instance did you know that a working copy for 1GB of
files will actually take up 2GB of disk space on the client? This is
because Subversion stores a pristine copy of each file the client
checked out, so it can do offline diff and revert, and send diffs up to
the server when a file change is checked in.

Subversion doesn't (yet) have any tuning options to help it handle large
files. Maybe we need a FAQ section on this kind of thing.

Cheers,
Mike.

----------------------------------------------------------------------
IMPORTANT NOTICES
This email (including any documents referred to in, or attached, to this
email) may contain information that is personal, confidential or the subject
of copyright or other proprietary rights in favour of Aristocrat, its
affiliates or third parties. This email is intended only for the named
addressee. Any privacy, confidence, copyright or other proprietary rights in
favour of Aristocrat, its affiliates or third parties, is not lost because
this email was sent to you by mistake.

If you received this email by mistake you should: (i) not copy, disclose,
distribute or otherwise use it, or its contents, without the consent of
Aristocrat or the owner of the relevant rights; (ii) let us know of the
mistake by reply email or by telephone (+61 2 9413 6300); and (iii) delete
it from your system and destroy all copies.

Any personal information contained in this email must be handled in
accordance with applicable privacy laws.

Electronic and internet communications can be interfered with or affected by
viruses and other defects. As a result, such communications may not be
successfully received or, if received, may cause interference with the
integrity of receiving, processing or related systems (including hardware,
software and data or information on, or using, that hardware or software).
Aristocrat gives no assurances in relation to these matters.

If you have any doubts about the veracity or integrity of any electronic
communication we appear to have sent you, please call +61 2 9413 6300 for
clarification.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 17 06:36:49 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.