On 11/15/05, Jim Blandy <jimb@red-bean.com> wrote:
> On 11/15/05, Branko Čibej <brane@xbc.nu> wrote:
> > The real question here is, why do we need a new API at all? Can't we
> > simply add copyfrom info to ra_update? And wouldn't doing that magically
> > make svn_repos_update and svn_repos_replay identical (for a certain
> > combination of parameters)? Making the API smaller is a good thing.
>
> That's exactly where I was going. The information Garrett wants
> should certainly be available, and of course we need to avoid
> transmitting or recovering information when it's expensive if we're
> just going to throw it away at the other end, but it doesn't follow
> that we should make the same data look like four or five different
> sorts of requests.
It's certainly possible to extend diff/update to do this, but the main
reason I haven't gone down that road is that replaying a single
revision isn't very complicated, it gets somewhat more complex when
you take into account authz stuff, but still, it's not all that bad.
On the other hand, the reporter code is very complicated, and I'm not
sure that adding another mode of operation there, and increasing that
complexity, is worth the gain of not adding a new RA API. Sure, what
I'm doing does add some complexity to the svn_repos_replay API, but it
seems that in the end, it still results in less total complexity.
> (I think it's odd the way URL vs. URL comparisons use a reporter,
> which is allegedly for describing working copies, to specify the
> 'from' tree, but I guess that's just expressing the simple case in
> terms of the harder case, which makes sense.)
>
> So we could have a function that takes an editor and a 'to' URL, and
> provides a reporter (like diff2), but also takes a bitmask indicating
> what sorts of information that editor is interested in: text deltas;
> property deltas; copyfrom info; ... anything else? The goal would be
> to re-implement all the existing calls sending deltas from repo to
> client in terms of this one call.
This is certainly a possible approach. I'll take some time tomorrow
and look at what would be required to add it to the reporter code. It
may turn out to be easier than I expect, and it would give us the
advantage of being able to replay the difference between arbitrary
revisions (i.e. skipping over revisions you don't care about), which
would be an interesting ability to have.
I still suspect that it will be rather complicated to retrofit this
ability into the reporter code, and making that part of the codebase
more complex does not seem like a good idea to me.
-garrett
Received on Wed Nov 16 06:08:16 2005