[RFC] Bundles as repositories

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> I don't see grabbing from a URL where someone looked at the bzr branch
> with 'loggerhead' as *any* safer than grabbing from the URL of a bundle.
> In both cases its possible for the data the human looked at, and the
> data the computer received to differ. The only real way to avoid this is
> to have a top-level hash that can be used to check validity after pull
> or whatever completes.

Yeah, but when you look at a bundle in your mail client, save it to
disk, then merge it, you have a right to expect that what you saw in
your mail client is what the bundle with (attempt to) do.

> I think this is a reasonable approach - to be sure I got you, you are
> proposing that we 'couple prelude-presence with base64 wrapping of the
> pack file?'

Yes.

>> Single-parent MPDiffs ought to be easy to convert into knit deltas
>> without extracting any fulltexts.  You'll pay the cost of gzipping, but
>> not of file comparison.
> 
> If its easy to turn into a knit delta then its easy to use as one too -
> without paying the knit unzip cost :).

Wouldn't the knits get mad at me if I stuck uncompressed deltas into them?

> 
>> And heck, I haven't ruled out bundling knit hunks either.
>>
>>> I'm also thinking that it would be nice if everything for a merge
>>> directive could live in-branch ready to be used.
>> I'm confused.  As opposed to living in the repository?
> 
> I mean the 'commit message to use' and 'branch to submit to' data being
> stored in the branch.

Well, since we already store the submit branch, I don't think there's
more needed.  But how would you get the commit message?  Prompt the user
in advance for it?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGd14q0F+nu1YWqI0RAvdRAJ9E7h6LZWzU/3zQvZKGRA2V6e28VQCfXm1J
tWJE4jRVU3cjTyAEu2fapcs=
=mGoS
-----END PGP SIGNATURE-----