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

Re: [RFC] Reverse blame

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-09-18 18:45:58 CEST

Daniel Berlin wrote:
> On 9/18/07, C. Michael Pilato <cmpilato@collab.net> wrote:
>> Hyrum K. Wright wrote:
>>> I've started to get down the road of having a generic ancestry walker,
>>> and I'm starting to realize how idiotic our blame implementation is. By
>>> having to wait for svn_repos_get_file_revs2() count up all the revisions
>>> on the server and then send them to the client, we wait a lot of time
>>> and resources. The ancestry walker lends itself to sending file
>>> revisions in a streamy way, as they are found, youngest to oldest.
>>> This, in turn, leads toward a youngest->oldest blame implementation,
>>> instead of our current oldest->youngest implementation.
>>>
>>> I'll like to propose that we resurrect Dan Berlin's old reverse blame
>>> patch, found here:
>>> http://svn.haxx.se/dev/archive-2005-03/1036.shtml
>> If there are no compat issues (or we've addressed them suitably), and
>> performance gains to be had, need we even discuss this? +1.
>
> I don't remember whether I ever solved the issue of simply closing the
> connection when we finished, instead of telling the server "you don't
> think we are done, but we're done here!"

Well, we have a mechanism for this now -- the blame callback receiver needs
only to return SVN_ERR_CEASE_INVOCATION as a code for "stop calling me!".
Whether or not it's cool to just drop the server connection is not something
I can answer. But the various RA layers can, if they wish, choose to
perform this operation in chunks, requesting batches of, say, 20 revisions
at a time, and checking for a request to cease callback invocation between
chunks. Right?

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Tue Sep 18 18:46:09 2007

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.