On Wed, Mar 14, 2012 at 06:28:40PM +0000, Philip Martin wrote:
> "C. Michael Pilato" <cmpilato_at_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.
Received on 2012-03-14 21:02:37 CET