Greg Stein <gstein@lyra.org> writes:
> Well... making the skelta perform any kind of a state change is the basic
> issue. If it is viewed simply as a preflight test, then you're okay. The
> *real* change comes later and (hopefully) succeeds. (but the race condition
> between skelta-OK and delta-apply could let in other changes and thus the
> delta could still fail)
Yah. So, maybe we should bring them back in this fashion later.
> The skelta is nice from the standpoint of finding basic problems before
> transmitting that 10M file over the 56k uplink.
>
> However, if the tree format is tweaked/munged/tossed, then the large file
> uploads could come at the end of the change set. This would allow a failure
> to abort the change set before bothering with the file uploads.
>
> If you keep the tree structure, then I'd recommend keeping the skelta
> concept.
Yah, either way. The loose-preflight-check concept can be added at
any time (even in the tree structure, one could substitute
forward-references for text deltas and send the actual vcdiff data
after the tree delta has been transmitted, to make the pre-commit
check happen sooner).
> 2) As the file arrives, it is stashed directly into the SVN repository. When
> the delta stream is constructed, it simply refers to the files that are
> already present in the SVN repository.
This makes most sense to me, too. You just construct all the nodes as
the data comes in, just don't link them up until all changes have been
received.
> Hmm. Okay... I guess I'd rewrite my email as "the XML form is moot. my
> second point is that the ideal situation is that the client network library
> has change-items pushed into it. it marshals and transmits those. the server
> then pushes the change-items into the server-side SVN library."
>
> Part of this ideal also arises out of the recognition that the tree and
> linear forms are equivalent. Consider the client side:
>
> while walking_working_copy():
> generate_change_XML()
>
> Each of those generate_change_XML() calls can be viewed as an "event." Sure,
> the sequence has a bunch of element-start and element-end markers which
> create a tree or a scoping, but the fact is that you have a sequence of
> events. A simple example:
>
> <replace name="file1">
> <file>text-delta</file>
> </replace>
>
> is equal to the following event sequence:
>
> START: replace
> ATTR: name=file1
> START: file
> CDATA: text-delta
> END: file
> END: replace
>
> The "digger" thing in the current code is all about transforming an XML tree
> into a meaningful sequence of events. Each of those callbacks is an event:
> delete, entry_pdelta, add_directory, replace_directory, etc.
>
> Imagine if the the server simply called those callbacks directly. Why use a
> tree structure? As long as the sequence of calls was identical. The above
> example issues a replace_file() call. Does it matter whether replace_file()
> was called during a tree structure walk or via a sequence of calls?
I see what you mean. Yeah, it doesn't matter much, except for the
difference that the `name' attribute in the XML is further qualified
by its position in the tree -- i.e., you determine the full path by
the tree that's been walked so far. Whereas in the flat event
sequence, the name has to be a full path relative to the top of the
repository.
In other words, the difference is that with the tree format it is
impossible to give the sequence of events the wrong order. Changes to
directories are always seen before changes to their children. This is
a very useful guarantee, certainly for the client and I think also for
the server. Hmm:
A flat event sequence derived from a tree will always be in order.
A tree derived from a flat event sequence may be out of order; or
rather, one can't always derive a valid tree from a flat sequence.
So I think the "extra work" you're doing to convert XML-ly trees into
event sequences may not be so extra after all. It's true that callers
of the networking library could simply make sure to always generate
their events in order, but the XML intermediate _forces_ them to do so
-- if they don't, they'll end up with an invalid XML tree. By always
converting from a tree, you guarantee that the event sequence is in
order.
Does that make sense, or am I being early-morning bogus? :-)
> No problems. Just simplifications and a reduction in the amount of code that
> needs to be implemented. e.g. why deal with XML parser code if it isn't
> going to be used? You know me: "pragmatic" is my favorite word. I love to
> avoid writing code :-)
What were they? Laziness, impatience, hubris? :-)
> "heads down" meant busy doing a brain dump into the document. I've spent a
> good while reviewing docs and thinking/planning/designing. It is simply
> taking me a bit longer than I had envisioned to get it all onto "paper."
Am reading...
Received on Sat Oct 21 14:36:06 2006