subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Merge 'svnmover' demo tool to trunk
Date Thu, 12 Nov 2015 23:31:41 GMT
On Thu, Nov 12, 2015 at 4:37 PM, Julian Foad <julianfoad@apache.org> wrote:

> On 12 November 2015 at 17:11, Greg Stein <gstein@gmail.com> wrote:
> > On Thu, Nov 12, 2015 at 4:44 AM, Julian Foad <julianfoad@apache.org>
> wrote:
> >> I want to bring this to trunk because I can't do this on my own. I
> >> think it's the number one most important thing that Subversion needs,
> >> and so I passionately want to make it work in some way. I have done a
> >> big batch of solo thinking and scratched hundreds of sketches on scrap
> >> paper, which was productive and resulted in what I think are some good
> >> ideas, but there are still some big gaps in how to fit them together
> >> into a real Subversion.
> >
> > A quick perusal shows that this model reads entire files into memory.
> That
> > isn't workable.
>
> Of course reading entire files into memory isn't workable for a real
> product, yes, well spotted! But dealing with the file text content is
> ancillary to the element-tracking principles that this demo is
> demonstrating. Those aspects don't depend on reading the full file
> text into memory. That's just one prototyping shortcut among many.
>

While I agree with that generally, I think it needs to be considered.

In Ev1, the driver gave the receiver a window handler, and the receiver
pushed content back to the driver.

In Ev2, the driver gives the receiver a stream, and the receiver pulls
content as needed.

That change in data flow was *huge*. Lots of our code had been set up to
assume certain push/pull directions, and had to be rejiggered to cope with
the flow change.

As a result of that experience, I think simply carrying around content
misses a key piece of the puzzle.

Cheers,
-g

Mime
View raw message