C. Michael Pilato wrote:
> Branko Čibej <firstname.lastname@example.org> writes:
>> Garrett Rooney wrote:
>>> On 11/15/05, Jim Blandy <email@example.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
> 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
> 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
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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 16 17:50:08 2005