subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "C. Michael Pilato" <>
Subject Re: svn commit: r1089856 - /subversion/trunk/subversion/tests/cmdline/
Date Tue, 12 Apr 2011 13:29:41 GMT
On 04/12/2011 06:32 AM, Philip Martin wrote:
> "Bert Huijben" <> writes:
>> I like to think of it this way (and the current WC-NG tree model agrees):
>> A wc-wc copy is created from what is currently in your working copy and
>> copies are not affected by BASE operations; just like a non svn copy would
>> do.
>> So following this reasoning a copy should register exactly what it copied,
>> recording the original locations on switches etc. 
>> (I really hope it currently does; if that is not the case our copy operation
>> doesn't introduce the new op-roots where it should).
> It's still not clear to me that it is correct for switch to become a
> replace when copied.
> Consider a working tree (not copied) with depth changes and switches.
> Neither depth changes or switches count as local modifications that can
> be committed, they just affect the "view" of the repository.
> If we wc-to-wc copy such a tree the depth changes and switches are going
> to be "present" in the copy, that seems reasonable--it's a working copy
> only operation so only the items in the wc can get copied.  It's how
> that copy gets committed that is the issue.  In 1.7 the switch in the
> copy has become a local modification that gets committed as a replace.
> That's a change from 1.6 and it's also inconsistent with how switch
> behaves outside the copy, it's inconsistent with wc-to-URL copy, and
> it's inconsistent with the way the depth changes behave in the copy.
> I don't know what the answer is, perhaps switched nodes should be
> op-depth=0 within the copy, perhaps the code should recognise some
> copied nodes at op-depth>0 as switched.
> My worry is that we have arrived at the current 1.7 behaviour by
> accident, rather than as a conscious decision, and that supporting this
> behaviour in future will prevent us making switch in a copy behave more
> like switch outside a copy.

I also get the sense that what we have today is just unexpected fallout from
the work we've done for everything else in WC-NG.  If I may wax quaintly
poetic for a second...

   The storage layer's design should not your features define.

C. Michael Pilato <>
CollabNet   <>   <>   Distributed Development On Demand

View raw message