ZIP files in working tree

[Martin von Gagern]

On 25.03.2010 17:25, Jelmer Vernooij wrote:
> If you don't require the bzr plugin, you can't do delta's specific to
> ZIP files because the optimal deltas your plugin creates wouldn't be
> interpretable by bzr instances that don't have that plugin.

Yes they would. Without the plugin, bzr would give you a directory.
Users without the plugin would have to zip the resulting dir in order to
make it accessable to the application dealing in ZIP files.

> Wouldn't you rather want to see a diff that actually explains the
> differences in terms of ODT or Word? E.g. "Image XY in section 1.2 has
> changed" or in qdiff actually see the different images? 
> 
> The ZIP file in this situation is just a format, so I don't see how it
> should be presented as such to the user. 
> 
> Again, I think that custom merger should be specific to
> OpenOffice/Word/etc. Users shouldn't have to care that those formats are
> really zip files with XML files underneath.

In a perfect world, every app would know not only how to edit its docs,
but also how to diff and merge them, both two-ways and tree-ways. But we
are so far from that perfect world, that I'd rather see a diff between
XML files than between binary files, because that's all I'd get in most
cases. And to be honest, I wouldn't want to be an application developer
in such a perfect world, unless I were allowed to make it less than
perfect. You're asking a lot.

But even in a perfect world, there are cases where I'd consider a look
into the ZIP file to be of advantage. Plain text diffs can be displayed
on web pages without additional requirements (thus my trac-bzr example)
or piped to simple scripts. Generating them is much faster than starting
huge office applications and loading bulky documents with lots of
embedded multimedia, so a "bzr diff -c 1234" will tell me what actually
changed much faster than an application-assisted diff. I also can't see
all those applications providing annotate functionality and stuff like
that in addition to diff and merge.

I know there is a choice between what you consider more important, the
document as an opaque entity accessible through an application, or the
ZIP file as a container format with an internal structure open to
inspection. Currently, you either have the first and a binary file in
bzr, or the second and the manual zip/unzip that involves.

I'd like to make that gap a bit narrower, but stay on the structured
side as far as repository storage is concerned. A simple ZIP file merger
would narrow the gap as well, but not as much, and it would stay on the
opaque side for storage.

Greetings,
 Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20100325/d0b5b867/attachment.pgp