"C. Michael Pilato" <cmpil...@collab.net> writes: > On 04/07/2011 08:44 AM, Philip Martin wrote: >> I'm not really sure how a copied switch should behave when committed, is >> the above correct? > > This use-case doesn't even make sense to me. Switch is a working copy > operation concept -- causing local elements to reflect an alternate line of > history. > > Forgetting the copy operation for a second, if you simply commit in a > working copy that has a switched subdir, there's no "coalescing" of the tree > on the server side -- changes made in the subdir wind up in the repos tree > to which the subdir is switched, and changes made outside the subdir wind up > in their respective original repos locations. Now we add 'copy' to this > situation -- a copy of a tree with a switched subdir. I rather think that > this should behave as if it was a BASE deep copy with the switches > re-applied after the copy. In other words, when looking at the copy result, > switch followed by copy should have the same effect as copy followed by > switch, or something like that.
Not sure I understand. Are you saying that "copy then switch then commit" should be the same as "copy then commit then switch"? > This also implies that, for user sanity, we > should disallow WC-to-REPOS copies of trees containing switched items. I suppose making switch within a copy behave like other switches, i.e. affecting the switched location in the repository, would be possible but likely confusing. We do have precedent for preventing copies: we disallow copies with absent (excluded by authz) nodes, since the server does not allow the parent of an absent node to be copied. I was going to say I'd wait for Julian's input, but I see Bert added this test in 2009... -- Philip
