Stacking and VersionedFiles, a state-of-the-patch mail

[John Arbash Meinel]

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

Robert Collins wrote:

...

| Concretely tree building needs all the files for a revision. So
| Some_verb(revision_id)
| is all we need to generate the right stream.
| However, merge only wants some files - typically the basis file which
| may not be local -
| Some_verb([list_of_text_keys])
| is appropriate there.
|
| We could do:
| Some_verb(revision_id) -> stream
| And then filter to handle the second case, but in (say) open office
| trees, that would suck.
|

Well, you could always have:

Some_verb(revision_id, [optional_filter_list])

If the list is missing, it returns everything for the revision, if it is
supplied, it returns only those entries.

Alternatively, another open other question: Are we requesting:
~  a) file_id @ revision_id or
~  b) file_id @ the revision of the inventory @revision_id.

your first api seems to be about the other. If we need the former, then we
pretty much need a list anyway.

John
=:->

| Likewise, doing tree building by asking fora  list of keys for open
| office will send a huge amount of data over the wire :).
|
| Not to fear though! I think the approach of having a new shallow branch
| be preseeded with the content needed to build the tree fixes this
| because we can ask locally for a list safely, and the fetch code works
| at the revision graph level - we just need the (previously discussed)
| flag for fetching streams to ask for fulltext capability.
|
| -Rob
|
|

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

iEYEARECAAYFAkhRQnQACgkQJdeBCYSNAAO8ywCg1/p6+lvDk6Q99yrxqVb41f0g
OgMAoKvWMRHd3g01C0b9wNmjL3rtbpGM
=/AtY
-----END PGP SIGNATURE-----