[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: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 13 Nov 2015 11:59:11 +0100

> -----Original Message-----
> From: Julian Foad [mailto:julianfoad_at_apache.org]
> Sent: vrijdag 13 november 2015 09:40
> To: Greg Stein <gstein_at_gmail.com>
> Cc: dev <dev_at_subversion.apache.org>
> Subject: Re: Merge 'svnmover' demo tool to trunk
>
> 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.

The Ev2 work is still not complete, and I think some of your experimental work shows shortcomings in the Ev2 approach, for which Ev2 doesn't provide a solution yet.

Currently the test wrappers still guesswhere it should fetch a pristine from: BASE or WORKING (or anything inbetween). We can never release the code until at least those things are guaranteed stable.

I don't think we can just make a final decision on the final future approach here yet...

        Bert
Received on 2015-11-13 11:59:36 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.