[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: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 08 Apr 2011 09:48:41 +0100

"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...

Received on 2011-04-08 10:49:24 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.