[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: Julian Foad <julianfoad_at_apache.org>
Date: Fri, 13 Nov 2015 08:40:28 +0000

Greg Stein wrote:
> 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:
>>> 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.

I agree it's a key piece of the overall Subversion architecture. I'm
not planning to reinvent anything here: I presume we'll choose the Ev2
way.

- Julian
Received on 2015-11-13 09:40:51 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.