On Wed, Mar 14, 2012 at 06:28:40PM +0000, Philip Martin wrote: > "C. Michael Pilato" <cmpil...@collab.net> writes: > > > On 03/14/2012 01:58 PM, Philip Martin wrote: > >> $ svn mv wc/A/g wc/g # using trunk > >> A wc/g > >> D wc/A/f > >> $ svn st wc # using trunk > >> D wc/A/f > >> > moved to wc/g > >> A + wc/g > >> > moved from wc/A/f > >> > >> If we now use the branch on that working copy: > >> > >> $ svn st wc > >> D wc/A/f > >> A + wc/g > >> > >> The moved-to/from is lost, a bit like 1.7 which simply doesn't consider > >> moved-to/from > > > > What happens in the opposite case -- that is, when you have a > > branch-based working copy and you move something, then use a stable > > 1.7 client to access it? > > The stable 1.7 client will ignore the moved-to/here completely and treat > the move as copy+delete. > > Current trunk will ignore most of moved-to/here create by the branch and > will usually treat the move as copy+delete, but it's not ignoring it > like 1.7 so I suppose some operations may fail. Similarly while the > branch will ignore most moved-to/here created by current trunk I can't > be certain it will ignore it in all cases.
This only affects working copies which contain moves recorded by a trunk svn client. Once the branch is reintegrated, those moves will stop working as expected. Given that the current target audience of trunk clients is reading this list, I don't think a format bump is required. Anyone who has working copies with local changes involving moves will have to either commit or revert those changes before using a trunk client that contains the changes currently still sitting on the multi-layer-moves branch. I don't think this is a big problem. Whether we'll bump the format for 1.8 release is a separate issue.
