[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: David Glasser <glasser_at_davidglasser.net>
Date: 2007-10-24 02:32:01 CEST

On 10/20/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> On 10/20/07, David Glasser <glasser@davidglasser.net> wrote:
> > On 10/20/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> > > 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.
> >
> > OK, but we do recognize that this is merely a heuristic, right?
> > Anything that can go wrong during a checkout can also go wrong during
> > an update...
> >
>
> Sure, this doesn't solve the bugs; it's just a speedup for checkouts.
> The original point of the copy-on-update feature is to preserve
> peoples local mods better during updates; during a checkout, there's
> no point in going through all this extra work to do that. There are
> no local mods.

Ben and I sat down and fixed the particular issue that was written up
in Issue 2977. We have further plans for improving the use of loggy
in this code, described in Issue 2986; I plan to work on this
tomorrow.

--dave

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 24 02:32:13 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.