[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge 'svnmover' demo tool to trunk

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 12 Nov 2015 17:31:41 -0600

On Thu, Nov 12, 2015 at 4:37 PM, Julian Foad <julianfoad_at_apache.org> wrote:

> On 12 November 2015 at 17:11, Greg Stein <gstein_at_gmail.com> wrote:
> > On Thu, Nov 12, 2015 at 4:44 AM, Julian Foad <julianfoad_at_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
Received on 2015-11-13 00:31:46 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.