> From: sussman@collab.net [mailto:sussman@collab.net]
>
> "Bill Tutt" <rassilon@lyra.org> writes:
>
> > > I am inclined to think that the solution to this problem might be
as
> > > simple as the removal of svn_fs_link() from the filesystem
interface.
> > > Currently, svn_fs_link() is used only by the repository layer's
> > > reporter vtable() implementations, and by some test code (I
think). I
> > > wonder if perhaps svn_fs_copy() is sufficient for all places where
> > > svn_fs_link() is currently used?
> > >
> >
> > I'm not sure why the reporter layer uses this. IIRC when analyzing
the
> > places that called filesystem code this TXN_ID that the reporter
vtables
> > are building are aborted anyway. This seems wrongheaded and
performance
> > horrible eventually.
>
> Bill, FYI: this is how updates work. The client builds a perfect
> "mirror" of its working copy as a txn on the server. Then the server
> walks two trees, comparing the txn to some revision, and sends back a
> tree-delta. Then the txn is tossed.
If there isn't a technical reason to have the data in the repository,
then it's a useless time drain to stick it there. The tree should just
be constructed in memory, and never ever be committed to the repository.
i.e. No wonder SVN's performance numbers suck so badly. :)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 28 17:49:41 2002