Greg Hudson <ghudson@MIT.EDU> writes:
> On Sat, 2003-11-01 at 15:07, Shlomi Fish wrote:
> > I favour option #2 for the time being and ghudson backed me up. Two very
> > prominent figures whom we talked with on #svn, were not fond of the idea,
> > though. What do you think?
>
> I think people would have an easier time commenting if they had a better
> idea of what you're proposing, so I'll try to elaborate.
>
> I think what we fundamentally need (for diff and for other operations if
> they are changed to allow peg-revisions) is a function which maps <rev,
> path, historical-rev> -> <rev,path>, using the FS history API. For
> instance, in our repository, it would map
>
> <7534, "/trunk/subversion/libsvn_ra_svn/editorp.c", 6000>
>
> to
>
> <5609, "/trunk/subversion/libsvn_ra_svn/editor.c">
>
> You can currently do this sort of mapping using svn log, but it's a big
> waste.
Shlomi, for your record-keeping, vote-tracking purposes, this is the
same API that Sander and I have been recommending. So, to further
clarify your options #1 and #2, this lookup will always have to
happen. The only question is whether it
(1) Each subcommand, given [PATH, PEG, [RANGE-X, RANGE-Y]], calls
to a new RA interface to resolve [PATH, PEG, [RANGE-X, RANGE-Y]]
to [[REALPATH1, RANGE-X], [REALPATH2, RANGE-Y]]. Then, back on
the client side, the subcommand uses this "real path"
information for its main operation.
(2) Each subcommand passes [PATH, PEG, [RANGE-X, RANGE-Y]] as
parameters for its main operation to the server, which performs
the mapping described above before actually responding to the
client with the results (which are now based on the mapped
paths/revisions).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 3 16:08:33 2003