"C. Michael Pilato" <cmpilato_at_collab.net> writes:
> 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.
I tend to agree.
> Philip, you say that it's not clear to you that the new behavior is
> correct. What are you currently leaning towards?
I like the 1.6 behaviour where switch is not a modification that gets
committed. That's how switch behaves outside copies, and it means that
"switch-copy-commit" produces the same result as "copy-commit-switch",
which seems like a plausible definition of what copy of a switch should
mean.
If we adopted that behaviour we would have to fix the behaviour for
commits of modifications within the switch. The 1.6 behaviour is
obviously wrong, the commit will usually fail, and when it succeeds the
wrong node is modified in the repository. Fixing it would mean
committing the modifications to the source of the switched URLs, just
like any other switch. The commit logic is mostly URL driven so I
imagine it could be adjusted to do this. Doing this would probably
allow modifications to switches inside a copy to be committed without
committing the copy itself.
I've just thought of a related problem: deletes that contain a
switch. Given:
svnadmin create repo
svn mkdir -mm --parents file://`pwd`/repo/A/B/C/D
svn cp -mm file://`pwd`/repo/A file://`pwd`/repo/X
svn co file://`pwd`/repo/A wc
svn sw ^/X/B/C wc/B/C
svn rm wc/B
svn st wc
D 2 1 pm wc/B
D S 2 2 pm wc/B/C
D 2 2 pm wc/B/C/D
(1.7 doesn't show the S flag after the delete, but it comes back if the
delete is reverted so it's just a display issue)
If I commit the above should ^/X/B/C or ^/X/B/C/D be deleted? 1.6 and
1.7 both just delete ^/A/B.
--
Philip
Received on 2011-04-11 18:15:52 CEST