[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Nasty double-replace copy-on-update bug

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2007-10-19 20:53:55 CEST

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 20:54:05 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.