[Jim, I just left a rambly voice-mail about this on your phone.
Anyway, this email should be a better summary of things. :-)]
Greg Stein's pointed out a number of things about the editor
interface, which we're still digesting over here. It would be great
if you (Jim) could read over the thread(s) and comment. I know you're
busy with some other stuff today, so however much time you can spend
on it would be great.
needed. The prime example of a case where it might be desirable is
update: when the delta comes back from the server, you want to know
that all the revision numbers the wc sent in its initial state-report
are still true, so that the delta can be safely applied.
However, this could be solved with strictly client-side record
keeping, and right now I think that would be best. As you have
pointed out before, delta editors are really about expressing
differences between arbitrary trees -- the inclusion of ancestry
information is merely a nod to the specific kinds of trees Subversion
most often deals with. Were we to start including the target
revisions as well, though, it would start feeling silly. :-)
That's my thought right now. However, Greg mentioned a lot of things,
and it will take a while to digest it all; so my initial reaction that
the editor interface doesn't need changing might just be reflexive
conservatism. Let's all think & then talk tomorrow about it.
Here are all the threads, I believe:
[ Greg Stein ] ancestor path / revision
[ Greg Stein ] two revnums of interest (was: Re: ancestor path / revision)
[ Greg Stein ] absolute paths (was: Re: ancestor path / revision)
[ Greg Stein ] computing paths, revision numbers (was: Re: ancestor path ...
[ Greg Stein ] property names (was: Re: grumble, grumble)
[ Greg Stein ] storing the absolute path in the WC (was: Re: ancestor ...
[ Greg Stein ] replacing items (was: Re: ancestor path / revision)
[ Greg Stein ] Re: "path" during a commit walk
-K
Received on Sat Oct 21 14:36:17 2006