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...
--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 Sun Oct 21 03:54:39 2007