Re: moving files in a smarter way

> > Because a move is - currently - modelled as a Delete + Add, which is
> > what the new client is receiving. Because of the Add, it also needs
> > the new content.

> I don't entirely buy that explanation, because it's not just an add,
> it's a *copy*, and the WC already contains the "copyfrom" source
> (or whatever it's called). [*]
>
> I don't think it should be necessary for the holy grail of
> "true renames" to be obtained before a simple copy can
> be implemented efficiently.

I'd have thought a copy would occur and then the delete but if that
isn't the case then I can understand why the client doesn't make this
optimisation now as it would need to either move all such files to a
holding pen in case a copy is needed or it would need to look forward
in the transaction.

I don't know how far away atomic moves are but they will open up a
whole bunch more performance opportunities when they are done. I
originally thought they were being treated as compulsory for the
merge-tracking to be completed but I think I saw mention that this is
not the case... I hope the the nice people doing the work have time to
do it soon because merge-tracking and atomic moves are serious steps
forward for Subversion.

Is there a way of getting a '1.5 road-map' report from issue-tracking?
 I'm aware 1.5 is a ways off given that 1.4 has just been released but
it'd be nice to know what's on the horizon (even if those features
might change as development progresses).

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org