You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Shlomi Fish <sh...@vipe.stud.technion.ac.il> on 2003/11/01 20:07:10 UTC

Issue #1093 APIs Change

One thing that is clear now, is that we will have to trace the history of
a file from its peg revision down to the revision to compare. The question
has arised where should we do it:

1. In the client side, above the repository access layer.

2. In the server side in libsvn_repos.

Now #1 would be simpler to implement and won't break compatibility.
However it will cause two log commands to be have to be performed over the
network, which will slow things down considerably. This violates
Subversion's "time is proportional to operation's cost" principle.
Furthermore, the history that is traced in option #2 will have to be
somehow traced in option #1, and we might as well not do it over the
network.

But it does break compatiblity.

A good compromise may be to add a new operation to trace the history of
files in a flexible way to the ra layer. This is of course, if there isn't
any way to already do it with the current schemes of things.

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?

Regards,

	Shlomi Fish


----------------------------------------------------------------------
Shlomi Fish        shlomif@vipe.technion.ac.il
Home Page:         http://t2.technion.ac.il/~shlomif/

An apple a day will keep a doctor away. Two apples a day will keep two
doctors away.

	Falk Fish

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Issue #1093 APIs Change

Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson <gh...@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

Re: Issue #1093 APIs Change

Posted by Greg Hudson <gh...@MIT.EDU>.
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.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org