[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: Mon, 11 Apr 2011 11:01:45 -0400

On 04/11/2011 05:53 AM, Philip Martin wrote:
> "C. Michael Pilato" <cmpilato_at_collab.net> writes:
>> But we obviously have precedent for supporting committed copies
>> of deeply switched things, so perhaps this isn't the best use of our time
>> right now.
> "Support" is generous, we only really support copied switches with no
> modifications:
> svnadmin create repo
> svn import -mm repo/format file://`pwd`/repo/A/B/f
> svn import -mm repo/format file://`pwd`/repo/A/B/C/g
> svn co file://`pwd`/repo wc
> svn sw ^/A/B/C wc/A/B
> svn cp wc/A wc/X
> Using 1.6 the copy of the switch does not show up in status. Using 1.6
> the switch does not count as a local modification and gets ignored by
> the the commit harvester. After the commit 1.6 shows wc/X/B as
> switched.
> If I make a text modification within the switched subdir before commit:
> echo xx >> wc/X/B/g
> then the commit fails because it attempts to modify /X/B/g in the
> repoository and that file does not exist. The fact that 1.6 attempts to
> commit modifications to the wrong file is a definite bug, if the path
> existed and the checksums matched the commit would go through.
> 1.7 treats the copy of the switch as a local modification that gets
> committed as a replace; after the commit there is no switch. The test
> is new in 1.7 and it's not clear to me that the new behaviour is
> correct.

Man, my gut says to just not allow folks to copy trees with switched
children until we have a more-fully-formed vision regarding how to deal with
the overlap of the copy and switch concepts. (Of course, that sanity check
would need to *not* block copies of trees with file externals ... our
now-routine "when is switched not *really* switched" exception.) Yes, I
realize that this might be considered the cop-out position to take. I'm
okay with that.

Philip, you say that it's not clear to you that the new behavior is correct.
 What are you currently leaning towards?

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2011-04-11 17:02:17 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.