First: I think this idea is the way to go!
"Hyrum K. Wright" <hyrum_wright@mail.utexas.edu> writes:
> Some other questions:
> * Should we have separate callbacks for flagging merging and "end of
> branch" revisions, or just add flags on the existing callback?
Separate callbacks, IMHO.
> * Should we implement this walker in as public API, so that the client
> libraries can use it directly? What would be the best way to do so?
> (If we did do that, we'd need to transmit deltas, similar to
> get_file_revs().)
Keep it private for now, with a note that it's fine to make it public
if/when other libraries start needing it. Better to develop the API
internally, and make it public only after it's been tuned, anyway.
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.
A thought: you don't need the 'stop_on_copy' parameter if you have the
boolean '*halt' in the callback's API already, right?
> This is great at traversing one line of history, but what about multiple
> lines? Unlike the delta editor where a node is either a directory or a
> file, in the case of ancestry, a revision can be both a merging
> revision, as well as a revision that somebody made edits to. Should
> there be multiple callbacks? Which order should they come in? Is there
> a way to send multiple lines of history streamily?
A suggestion: state explicitly that the order of callback invocations
is undefined, because you want maximum freedom to tweak the walk
driver to be as efficient as possible, at least for now. Or maybe
there can be a partial ordering, but just feel free to document
yourself as much leeway as needed, guided by driver implementation
constraints.
> In some ways, I feel that my current implementation of 'blame -g' is
> pretty hacky, and doesn't have a very sound theoretical backing. I know
> that there are some bugs in there, and actually implementing an ancestry
> walker would go a long way toward improving correctness.
I agree, these kinds of abstractions almost always make the code
cleaner and (sometimes) more correct.
> Well, having heard nothing but a deafening silence, I'm going to create
> a branch and commit some of the work I've already done to it. I don't
> have much, but it may give people a little bit better of an idea of what
> I'm proposing.
Sorry, just catching up on mail, hence the delay.
> -Hyrum
>
> [1] http://www.red-bean.com/kfogel/beautiful-code/bc-chapter-02.html
Heh, glad you liked it :-).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 13 07:15:21 2007