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