ZIP files in working tree

[Martin von Gagern]

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.
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".
8. Three-way merges could be done with a custom merge handler, I agree.
9. Having to zip things up in a separate step would be annoying.

> Would you like "bzr st" to report on the fact that only a single file in
> a zip file has changed?

Yes, I guess that would be consistent.

For bzr st, that would be the consequence of implementing a working tree
wrapper the way I have in mind. However, I now realize that such a
wrapper would not be enough, because I want ZIP file members to be
automatically added or deleted when the ZIP file changes. So that
editing in a ZIP-based app feels like editing plain text: you don't have
to worry about added or deleted files, you only do bzr commit to commit
your edit.

> If so, is there any reason not to just include the contents of that file
> in the working tree rather than using a zip file?

Those apps don't work on directories, they work on files, which they
consider mostly opaque to their users. At least in my experience. Some
versions of Apple iWork can open a directory, but when you save the
document, the app stores things to a ZIP, deleting the directory. Tough
luck if the dir representing the document also was the root of the only
existing bzr branch of that document, and the save destroys all history.

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/50188c13/attachment.pgp