Garrett Rooney <rooneg <at> electricjellyfish.net> writes:
> > 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.
Of course I'd like to see a dir_delta that is capable for giving copy_from
information and we just export that function with ra, rather than the
tailor-made apis for client-level commands.
But it's not there. And the logic for creating copy_from across many
revision is complicated, what if it's copied from the revision that is
included in the range of the delta? how about delta on two paths?
Do we map the copy_from information?
Before someone get to sort all these out, I am +1 on exporting the
existing and useful repos_replay. This is particularly useful for
SVN::MIrror, as it's trying very hard to reverse engineer the actual
changes made in a certain revision, and reduce the traffic over ra.
Cheers,
CLK
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 16 15:46:02 2005