[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: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: 2007-09-14 04:07:30 CEST

Hash: SHA1

Karl Fogel wrote:
> "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.

True. An RA API could be built on top of this which does return the
file contents, though. But, now that I think of it, that's immaterial
to this discussion, anyway.

>>> 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?)

The three callback triggers I'm planning now are:
 * An "interesting" revision (i.e., one in which the node changed). A
   typical, non-branching copy is such a revision. This will get called
   on every revision which the walker finds interesting.
 * A merging revision, which gets called after the first callback if a
   revision is determined to have a merge in it.
 * The end (beginning) of a merging line of history, IOW, the point the
   branch occurred.

To restate your question: could we add a fourth callback ("this node was
copied from somewhere else, here's where"), and let the callback
determine if the walker should halt or not? Is this right?

- -Hyrum
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 14 04:04:01 2007

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