[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1089856 - /subversion/trunk/subversion/tests/cmdline/switch_tests.py

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 12 Apr 2011 09:29:41 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.