On 04/12/2011 06:32 AM, Philip Martin wrote: > "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.
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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
