On 12/7/05, Hadmut Danisch <hadmut@danisch.de> wrote:
> Hi,
>
> sorry, if this was asked before, but I could not yet find anything
> about that matter.
>
> There are plenty of open source file formats (e.g. OpenDocument),
> which look like a binary format, but are actually just a zip archive
> of several files, mostly XML, but binaries like images etc. as well.
>
>
> How would subversion treat these archives? As plain binaries?
>
Yes.
The server treats all files as opaque binary blobs of data, and stores
binary differences between successive versions of files.
The client treats files as either binary blobs, or as text, based on
the metadata you attach to a file. If the client thinks a file is
textual, it will attempt to display diffs and perform merges using
line-based contextual differencing algorithms. If the client thinks a
file is binary data, then it won't attempt to display diffs or perform
merges.
> If I correct just a typo in a large presentation, which is actually
> just a changed line in one of the XML files, this impacs the whole zip
> archive.
Yes, possibly changing more bytes then than the original 1-line change...
>
> How would subversion deal with that? Would it store the complete
> binary as a diff, just because on XML line had been changed?
>
Yes, the server would compare the 2 zip files, and store a binary diff.
>
> What about auto-expanding zip archives and storing them as svn files,
> and auto-compressing when exporting the repository?
>
Many would argue that this is a bad idea, that it's not the server's
job to understand file formats, that that way lies madness. Would
would be the purpose of all that complexity? To save a small bit of
repository disk space when versioning compressed archives? Is it
worth it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 7 17:11:04 2005