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

RE: Autoexpanding ZIP archives?

From: André Pönitz <andre_at_wasy.de>
Date: 2005-12-08 07:18:17 CET

Hadmut Danisch wrote:
> Hi,

Hi.

> sorry, if this was asked before, but I could not yet find anything
> about that matter.

It was asked before.

> 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.
 
> 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.
>
> How would subversion deal with that? Would it store the complete
> binary as a diff, just because on XML line had been changed?

The diff would indeed be bigger than necessary.

> What about auto-expanding zip archives and storing them as svn files,
> and auto-compressing when exporting the repository?

This feature (and similar ones like general filters in
check in and check out) was requested several times but
so far nobody seemed to have been interested in actually
implementing it.

There are basically two points coming up in the discussions:
1. (religious) Everybody should use text everywhere.
2. (semi-technical) One cannot trust clients to have proper
   filter installed, so interaction with clients may fail.

The first point is even in the open source world invalid
as you have shown with your compressed documents. The same
goes for .png BTW which I personally would like to store
as .xpm on the server (and .xpm _is_ "diffable").

The second point is not entirely valid either. First of all,
e.g. one can make sure that zlib is available on the client
side by simply compiling it into the client. Secondly, most
 people do not care about "trivial" additional "soft"
 dependencies like gzip/gunzip or, say, xpdf or acroread
 when chenking in .pdf files.

A third point that's usually not mentioned is that there is
already a precedence of a "filter" in svn when handling line
endings.

So in the end there is not much left, but as long as nobody
wants to work on the feature, nobody will do so ;-}
I'd guess if someone threw enough money in the right direction
perception of the validity of the arguments may change...

Andre'

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 8 07:19:25 2005

This is an archived mail posted to the Subversion Dev mailing list.