On Fri, Aug 27, 2021 at 11:42 AM Evgeny Kotkov
<evgeny.kot...@visualsvn.com> wrote:
>
> Mark Phippard <markp...@gmail.com> writes:
>
> > Suppose I am using this feature for binaries, which I think is the
> > main use case. Using whatever tool I produce a modified version of my
> > binary file. At this point in time, there is nothing in the text-base
> > because I have not done any SVN operations other than checkout.  Since
> > it is a binary, other than maybe running status my next likely command
> > is going to be commit. Are you saying that during the processing of
> > this commit the client will first fetch the original text base from
> > the server before doing the commit? That seems sub-optimal.  Perhaps
> > you are only doing this for diff or revert which would make perfect
> > sense?
>
> The current state is that the commit is going to fetch the original text-base
> before sending the delta.
>
> It should be technically possible to implement a behavior where the commit
> sends a delta if the local text-base is present, and a fulltext otherwise.
>
> (Although as far as I can tell, we would have to extend the delta editor to
>  allow us to send a fulltext against an existing file, and the optimization
>  would only work for newer servers.)

This is just from memory of a list conversation that probably happened
10+ years ago now but ... if you use a generic WebDAV client with a
SVN server and you commit changes to an existing file the WebDAV
client is just sending the server the latest full text (no deltas) and
the server knows how to handle it. So theoretically some of what is
needed to support this sort of commit ought to already exist in our
server code.

Karl is the one with the current use case so he would be better to
comment but I tend to think of the full text has to be fetched to do a
commit the net improvement might be minimal. Using less disk space is
good but unless all clients are on a really fast network it seems like
commit performance will be abysmal. Also, it has already been
established the main driver for this request is binary files where no
one cares about diff and would be fine with revert needing to fetch
the file etc. I believe all would be fine if update just always pulled
down full files as well. So if we could minimize when a full text has
to be fetched that would be the ideal.

Mark

Reply via email to