ZIP files in working tree

[Jelmer Vernooij]

On Thu, 2010-03-25 at 16:54 +0100, Martin von Gagern wrote:
> On 25.03.2010 16:28, Jelmer Vernooij wrote:
> > Why would such files have to be treated differently between branches
> > and working trees? Can you give an example session operating on such a
> > file? 
> Sure.
> 
> 1. Create ZIP-based file in Microsoft Word, Apple Keynote, or similar
> 2. Save file, but keep the editor open
> 3. Add file and commit
> 4. Ask someone to edit an image embedded in the document
> 5. Change file in the editing app, which is still open
> 6. Save and commit
> 7. Look at changes in bzr qdiff, trac-bzr, loggerhead or similar
> 8. Merge the changes you requested in comment #4
> 9. Click "Revert" in the editing app to see this change
> 
> So what we have here is a number of features important to me.
> 3. Don't have to ignore the ZIP based app, and don't have to do this:
>    unzip - add new members - commit - delete unzipped dir
> 4. that person can edit the image even without the bzr plugin or
>    the (proprietary) app I use, simply editing a file

> 6. The commit only stored the delta of archive members. If the ZIP were
>    committed as a large binary file, then the whole compressed stream
>    of that file would change, as would almost all offsets in the file,
>    causing more data to be stored in the repo.
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.

> 7. I'd like to see the change to the XML file, or whatever the format
>    has embedded into the ZIP. Not just "binary files differ".
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. 

> 8. Three-way merges could be done with a custom merge handler, I agree.
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.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20100325/5eaed852/attachment.pgp