> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: maandag 11 april 2011 18:15
> To: C. Michael Pilato
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1089856 -
> /subversion/trunk/subversion/tests/cmdline/switch_tests.py
>
> "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.
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).
Update and switch (and checkout) only update the BASE and actual trees. Any
case that would affect the WORKING tree raises some kind of tree conflict
(some of which are automatically resolved for historical reasons).
When we want update/switch to affect the working tree we immediately have
the problem that we can only update a node once in Editor v1. We need the
BASE change for detecting tree conflicts, so we can't just use the update to
also update the switched location.
So affecting the working layers would require some smart thinkering with the
update editor: Maybe two editor runs, or maybe a virtual tree that isn't
directly mapped on local paths, ....
Note that we don't need this for handling file moves post 1.7: We already
record the changes on the BASE tree, so all we have to do is replay the
changes to that BASE location to the moved_to location.
> > 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.
This current behavior follows from the three trees model. Once a node is
overlaid/shadowed we stop looking at its lower layers.
Just deleting the root is what I would expect.
Bert
Received on 2011-04-11 19:09:47 CEST