On 10/19/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> On 10/19/07, Philip Martin <philip@codematters.co.uk> wrote:
> > "Ben Collins-Sussman" <sussman@red-bean.com> writes:
> >
> > > If I were to remove this forced log execution, I'd have to come up
> > > with some clever way of allowing the textdelta to apply against the
> > > not-quite-real-yet file. Hm.
> >
> > I suppose that ideally you would apply the textdelta to a temporary
> > file in .svn/tmp and then write log entries to move it into place, I
> > don't know how hard that would be.
> >
> > On a side issue, does this copyfrom stuff have a performance issue?
> > During a checkout none of the copyfrom sources are going to exist in
> > the working copy and yet rather than simply retrieve the final version
> > the code first retrieves an old version and then retrieves a delta.
> > In an environment where all development is done on branches it's
> > possible that all files will have copyfrom data.
> >
>
> epg brought this up, since we first discovered this bug while doing a
> large checkout. :-)
>
> I think what you say above is a good argument for 'svn checkout' to
> explicitly *not* request that the server send copyfrom args, and
> instead let the server behave the old way (just always send fulltexts
> to the client). 'svn update', on the other hand, can continue to
> request copyfrom args.
>
And, while glasser and I are still mulling about how to solve the 2
larger bugs here, I've committed this change in r27297.
svn_client_checkout() now asks the server to only send fulltexts
(ignoring copy history), while svn_client_update() asks the server to
send copyfrom-args on add_file() if it can.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 20 22:36:54 2007