"C. Michael Pilato" <cmpilato_at_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
Received on 2011-04-08 10:49:24 CEST