-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Karl Fogel wrote:
> 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.
Yeah, I've put some more thought into it, and that's the way I'm going
to go.
>> * 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.
Sounds good.
> 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().
> 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.
>> 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.
There will at least be some kind of ordering, but I think we can make it
pretty flexible. The docs are sparse and need to be filled out. I'll
do that once I have a better idea of how the interface will work.
>> 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.
No problem. Working on a branch is probably best anyway, since I'll
initially be breaking stuff, but I still want version control, and the
ability for people to see changes as they happen.
Thanks for the suggestions!
- -Hyrum
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG6awsCwOubk4kUXwRAh5PAJ9p0YHzHGWLQ59HLUzNnGiRaT8TTACgyXgG
2H7Dom/E6jkeF4/m0649Sf0=
=Dv1G
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 13 23:28:14 2007