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