"Bert Huijben" <b...@qqmail.nl> 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. -- Philip
