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

Re: CPU usage during commits

From: Simon Butler <simon_at_icmethods.com>
Date: 2006-05-24 20:33:41 CEST

On May 24, 2006, at 9:34 AM, Ryan Schmidt wrote:

> On May 24, 2006, at 18:15, Simon Butler wrote:
>> On May 24, 2006, at 7:44 AM, Ryan Schmidt wrote:
>>> On May 24, 2006, at 16:02, Sinang, Danny wrote:
>>>> In http://svnbook.red-bean.com/nightly/en/svn-book.html , it says :
>>>> Specifically, each time a new version of a file is committed to
>>>> the repository, Subversion encodes the previous version
>>>> (actually, several previous versions) as a delta against the new
>>>> version.
>>>> On average, we'll be checking in 10 MB PDF or TIFF files . Will
>>>> this consume a lot of CPU or Disk I/O ? If so, how much ?
>>> Only BDB repositories do this. FSFS repositories do not do this.
>> now i'm confused. for FSFS repositories what is the sequence of
>> operations for large binary files? i thought it was:
> The behavior is identical for binary and text files. Subversion
> sees them no differently.
>> 1) compare new version to previous version held in the working
>> area, generate delta
>> 2) transfer binary delta to repos and store
> When you commit changes, yes, a delta against the pristine copy in
> the working copy is computed and sent to the server, regardless of
> repository type. (The working copy on the client does not know or
> care how the repository is stored on the server). How the data is
> subsequently stored in the repository differs based on repository
> type. BDB stores the complete current version and rewrites the
> previous revisions to be deltas against the current revision. FSFS
> on the other hand stores a delta against some previous revision
> based on some algorithm.

can anyone explain why we need a binary diff at the repos? what is
the algorithm for determining which previous revision is diffed for
the FSFS repos delta? it seems like this is redundant

> I understand that Subversion has a good binary delta algorithm and
> that it is used for all files, text or binary, and that
> improvements in the algorithm are certainly welcomed.

reducing redundant delta calculation would be the first step here.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 24 20:35:12 2006

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.