On Tue, Jan 31, 2012 at 10:55 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Tue, Jan 31, 2012 at 23:27, Hyrum K Wright <hyrum.wright_at_wandisco.com> wrote:
>>...
>> One of the purposes the "commit plan" could accomplish is establishing
>> a priori what content the server has, and what content we need to
>> send, identified via sha1. Thus, if a commit is something like a
>> merge, where most of the content is already on the server, the client
>> doesn't have to transmit that information again. (Though maybe this
>> is already served by the lazy-load semantics of the Ev2 contents
>> streams.)
>
> Ah. Right. Forgot about that part.
>
> Yes, the server can say "don't send C1, C2, C3 to me". Typically, that
> list will be empty, but sure: sometimes we can save delivery of
> content. Also note that the list of checksums [to not send] needs to
> be preserved from Step 1 to Step 2 of the commit process. Some sort of
> stateful commit process object needs to be carried between the two RA
> steps.
>
>> Another (complimentary?) approach might be to totally divorce content
>> from structure. Just remove contents streams from Ev2 completely.
>
> I'm not sure that I like this approach. That goes back to the "save
> state across two API invocations" that we had before. It also means
> every Ev2 receiver will need to have some out-of-band way to receive
> the content or manage an interaction with a "checksum to content"
> mapping subsystem.
>
> Sounds yucky, or I'm not understanding your suggestion.
It does require some state to be maintained, but not as much as it
appears at first blush.
In the current delta editor, we have to keep all these file batons
around, since we need to tie a particular apply_txdelta call to a
given file. If we deal in the currency of hashes, all that state goes
away. The add_file/alter_file callbacks have told us the content they
expect, and we trust that at some future date that content will get to
the destination.
Because the content has essentially a UUID, we don't need to maintain
per-file state while we wait for it to arrive, we just need a simple
list of things we're expecting, and a way to ensure they get sent.
"Here's the tree; here's the content; I'll let you sort out what
matches to what." Or even "Here's the tree" "Thanks, I need the
following content" "Okay, here's the content you want."
Does that make sense?
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-02-01 07:50:56 CET