Repository.insert_data_stream contract [Re: [MERGE] Packs. Kthxbye.]

John Arbash Meinel john at arbash-meinel.com
Fri Oct 19 18:51:29 BST 2007


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



...

> 
> To write a good docstring for this, we need to figure out if it can (and should)
> work with a stream from a repository in a different format.  I guess some
> streams have to be incompatible, e.g. a repository supporting tree roots can have
> changes that cannot be represented in a repository that doesn't support tree
> roots.
> 
> So I think perhaps this docstring should say that the encoding is
> format-specific?  e.g.

If you aren't willing to go to some sort of arbitrary serialization format,
then I definitely think it should be marked as format specific. And the stream
itself should have a format marker, and the deserialization should break if the
marker is incorrect.

It actually looks easier than I thought to add the parents list to the knit
data chunks. Which would make indexes fully redundant (you could regenerate
them from only the knit data.) And I'd like to possible have that format change
merged for packs.

In doing so, the actual stream would now be invalid from Knit1 => PackKnit1.

I believe I'll change the _check_header, etc, code enough that this will force
the fetcher to break. So at least it will be data safe. But it would be nice to
have it fail earlier.

Oh, and you would need to have some repository format detection code to figure
out what streams you could get.

It *might* be best to have a 2 stage request. You could possible request a
specific stream format, or a list of supported formats that you could convert
from. And the far end could figure out what stream to send you.

This could also be a solution for the "push" problem. Except it goes back to
adding state. (You first have to ask the remote repository what format it is
in/what streams it will accept, and then you send the correct stream format.)

However, this goes back to where you want to hold that kind of state. Obviously
you don't want to send a 10MB Knit1 stream, just to have it fail and then send
a Knit3 stream. So we bring back the "how stateless is stateless" argument.
Arguably this is a state of the remote repository, and not the actual protocol.
But could you upgrade the repository in the meantime?

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHGO6hJdeBCYSNAAMRAr3lAKDPTniAnnMTOTQ/oacSkbsn1Vv/HwCfVnKK
Ix+IFXwgGeoJ721SQ4smGoM=
=w4UD
-----END PGP SIGNATURE-----



More information about the bazaar mailing list