On 04/12/2011 06:32 AM, Philip Martin wrote:
> "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.
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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-04-12 15:30:13 CEST