From: "Hervé Cauwelier" <herve@itaapy.com>
To: git@vger.kernel.org
Subject: Re: Multiblobs
Date: Fri, 30 Apr 2010 11:14:04 +0200 [thread overview]
Message-ID: <4BDA9F5C.2080808@itaapy.com> (raw)
In-Reply-To: <loom.20100428T204406-308@post.gmane.org>
On 04/28/10 21:13, Sergio Callegari wrote:
> If you store a structured file as a multiblob, you can use a blob for each
> uncompressed element of content. For instance, when storing an opendocument
> file you could use a blob for manifest.xml, one for content.xml, etc... (try
> unzip -l on an odt or odp file to get an idea). When you edit your file only a
> few of these change. For instance, if we talk about a presentation, each slide
> has its own content.xml, so changing one slide only that changes.
I'll obviously let the Git experts answer you, but I can answer about
OpenDocument itself.
In a presentation each slide is a <draw:page/> inside a single
content.xml. So if you change one slide, the whole XML will serialize
with a different SHA.
And maybe you'll add style to that slide, or probably OpenOffice.org
will generate an automatic style, so styles.xml will also change. Adding
an image also changes manifest.xml, along with storing the image itself.
OOo will surely record the last slide displayed when closing the
application, so settings.xml will change too.
So, all in all, for a single slide, 30 to 80 % of the Zip content may
change.
Unless you are talking about a dedicated application to store and
generate on-the-fly office documents, built on top of Git, you're better
not touching the contents the user is entrusting git to store, and write
a .gitattribute not to compress them in a pack.
You may also be interested in the git-bigfiles project that was
mentioned last week.
http://caca.zoy.org/wiki/git-bigfiles
--
Hervé Cauwelier - ITAAPY - 9 rue Darwin 75018 Paris
Tél. 01 42 23 67 45 - Fax 01 53 28 27 88
http://www.itaapy.com/ - http://www.cms-migration.com
next prev parent reply other threads:[~2010-04-30 17:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-28 15:12 Multiblobs Sergio Callegari
2010-04-28 18:07 ` Multiblobs Avery Pennarun
2010-04-28 19:13 ` Multiblobs Sergio Callegari
2010-04-28 21:27 ` Multiblobs Avery Pennarun
2010-04-28 23:10 ` Multiblobs Michael Witten
2010-04-28 23:26 ` Multiblobs Sergio
2010-04-29 0:44 ` Multiblobs Avery Pennarun
2010-04-29 11:34 ` Multiblobs Peter Krefting
2010-04-29 15:28 ` Multiblobs Avery Pennarun
2010-04-30 8:20 ` Multiblobs Peter Krefting
2010-04-30 17:26 ` Multiblobs Avery Pennarun
2010-04-30 9:14 ` Hervé Cauwelier [this message]
2010-04-30 17:32 ` Multiblobs Avery Pennarun
2010-04-30 18:16 ` Multiblobs Michael Witten
2010-04-30 19:06 ` Multiblobs Hervé Cauwelier
2010-04-28 18:34 ` Multiblobs Geert Bosch
2010-04-29 6:55 ` Multiblobs Mike Hommey
2010-05-06 6:26 ` Multiblobs Jeff King
2010-05-06 22:56 ` Multiblobs Sergio Callegari
2010-05-10 6:36 ` Multiblobs Jeff King
2010-05-10 13:58 ` Multiblobs Sergio Callegari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BDA9F5C.2080808@itaapy.com \
--to=herve@itaapy.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).