"Bert Huijben" <bert_at_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
Received on 2011-04-12 12:32:43 CEST