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

Re: Walking Merge History

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-09-14 03:29:27 CEST

"Hyrum K. Wright" <hyrum_wright@mail.utexas.edu> writes:
>> I'm not sure what you meant by "transmit deltas" in this context.
>> You're already implementing a callback invocation, analogous to
>> 'svn_file_rev_handler_t' -- isn't that enough? Maybe I just don't
>> understand, though.
>
> Sorry I was unclear. Basically, *if* we choose to expose this API
> through the RA layer, it would be something like get_file_revs(), only
> in reverse order, and capable of traversing merge history. Such an
> interface would probably be well served in sending deltas, akin to
> get_file_revs().

Hmm, but what are the deltas to transmit? These callbacks only return
metadata anyway, not (say) arbitrarily-sized file contents.

>> A thought: you don't need the 'stop_on_copy' parameter if you have the
>> boolean '*halt' in the callback's API already, right?
>
> Actually, I think we still do. A given invocation of the
> found_revision() callback won't know if it is the last revision before a
> copy. It could find out, but that would largely duplicate work the
> ancestry_walker would have already done.

Oh, the copy itself is not an event that triggers a callback?
(Perhaps it should be? And then that callback could set the *stop
flag?)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 14 03:25:57 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.