On 11.07.2012 13:43, Johan Corveleyn wrote: > On Sun, Jun 24, 2012 at 3:51 PM, Julian Foad <julianf...@btopenworld.com> > wrote: > ... >> I just want to say: I'm not at all demanding we break backward >> compatibility. Sorry if it sounded like it. I'm just saying that we're >> proposing to change the behaviour of the plain merge command, and in doing >> that we need to work out what the details of the new behaviour will be, and >> this thread is helping us to do just that. I ended up with a bias towards >> trying to move toward a more rename-friendly approach, but I recognise we >> can't get there yet so the "follow each node's own ancestry" idea is just an >> idea for the future. We need a simpler approach for now. > I intended to join the discussion when this thread first started, but > never got around to it... > > I just wanted to add: it seems to me that for a rename-friendly merge > (rename-friendly accross the entire tree that's being merged), we at > least need to first tackle the problem of handling server-side > renames/moves for 'update' (as 'update' can be seen as a simple > merge-like case). If and when that problem is solved, and we get a > clear understanding of the desired behavior involved, and get more > experience with that, only then can we start thinking about the more > complex situation of 'merge'.
That is correct. Essentially, not only does the server have to know about and correctly record renames; the rename operations in the update (or merge) editor drive need to happen in the correct order so that they can be reflected in the working copy filesystem. -- Brane -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
