> -----Original Message-----
> From: Bert Huijben [mailto:bert_at_qqmail.nl]
> Sent: maandag 11 april 2011 19:09
> To: 'Philip Martin'; 'C. Michael Pilato'
> Cc: dev_at_subversion.apache.org
> Subject: RE: svn commit: r1089856 -
> /subversion/trunk/subversion/tests/cmdline/switch_tests.py
>
>
>
> > -----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).
I forgot one very important point here:
Additions (adds and copies) are always seens as a copy as a new child of the
parent node.
So switches inside (or below) the copy are not followed for the commit
processing for determining where to commit. The entire working (or copied)
tree should be committed below that single point.
And this might be the reason we are talking about this: I wouldn't be
surprised if we have some failures here, where we are just looking in the
BASE tree to find the URL of where we want to commit instead of using the
proper svn_wc__db_scan_addition() call.
Bert
Received on 2011-04-11 20:57:35 CEST