C. Michael Pilato wrote:
> Branko Čibej <brane@xbc.nu> writes:
>
>
>> Garrett Rooney wrote:
>>
>>> On 11/15/05, Jim Blandy <jimb@red-bean.com> wrote:
>>>
>>>
>>>> I guess I'm surprised that we need three ways of doing essentially the
>>>> same thing: comparing revisions in the repository and transmitting
>>>> their differences.
>>>>
>>>>
>>> It's a combination of providing the right info and avoiding sending
>>> info that isn't required. Personally, it seems like the fact that we
>>> already have this kind of API underneath (we use it for svnadmin dump,
>>> for example) indicates that there is a use case for exposing this sort
>>> of API, as opposed to requiring people to do backflips to make the
>>> existing APIs bend to their needs.
>>>
>>>
>> 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.
>>
>
> In short, no.
>
> In medium, of course we could but the maintenance wouldn't justify it.
>
> In long, the update algorithm is entirely different than the replay
> algorithm.
>
> Update is all about calculating the simplest delta between two
> arbitrary trees, more-or-less ignorant of history, and assuming that
> the editor implementor has no knowledge of the repository other than
> the "source" tree -- it exists to drive the update of a working copy.
> The arbitrariness of the trees allows for them to be rooted anywhere
> (not just '/' ... not even at history-related places!). The ra_update
> UI is reporter-based, intentionally empowering it to build just such
> an arbitrary tree.
>
> The replay algorithm is rooted at '/', assumes the editor has full
> knowledge of the repository, and attempts to replay the normalized
> actions of a single revision regardless of the efficiency of those
> actions. There is no need for a reporter in this interface, as the
> source tree must comform to very strict standards (single revision,
> rooted at '/', etc.)
>
> I suppose you could shoehorn in something, but I frankly don't see the
> point.
>
I still don't see what the difference is, semantically, between "replay
revision BAR" and "update from / at BAR-1 to / at BAR". I understand
that the exact datasets that are sent back today are different, but I
still think that replay can be seen as simply a special case of update.
The cost of actually changing update in such a way that it can be used
to replace replay might be large, perhaps too large to bother at this
point. But in the long run, I think it would make sense to at least
investigate the possibility.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 16 17:50:08 2005