Re: Copy/move-handling on update in 1.5

On Nov 14, 2007 8:49 AM, Mark Phippard <markphip@gmail.com> wrote:
> On 11/14/07, Tor Ringstad <torhr@pvv.org> wrote:
> > There are a few caveats: [...] Also, if an incoming move-operation
> > deletes 'foo' before it attempts to copy it to 'bar', then the copy
> > will fail, and the client reverts to the old behavior of fetching a
> > pristine copy of the file from the repository.
> >
> > Is this what hits me? I can see (note #1) that the delete appears to
> > happen before the copy. Is this what the caveat is talking about?
>
> Yes.
>
> > In that case, is there actually any situation where the *user* will
> > notice any improvements with regard to copy/move-handling on update?
>
> Yes. When the file is copied before it is deleted. I am not sure if
> this is predictable via filename. You could do:

It is not "predictable" (specifically, in the current implementation
it is based on APR hash iterator ordering).

There are plans to make this work better in future versions (by saving
the deleted file, etc), but we really do want to get 1.5 released and
a partial feature is better than nothing.

> Moving a file from a subdir into its parent should do it.

I think so, yeah.

--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