> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: dinsdag 12 april 2011 12:32
> To: Bert Huijben
> Cc: 'C. Michael Pilato'; dev_at_subversion.apache.org
> Subject: Re: svn commit: r1089856 -
> /subversion/trunk/subversion/tests/cmdline/switch_tests.py
>
> "Bert Huijben" <bert_at_qqmail.nl> writes:
>
> > 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).
>
> It's still not clear to me that it is correct for switch to become a
> replace when copied.
>
> Consider a working tree (not copied) with depth changes and switches.
> Neither depth changes or switches count as local modifications that can
> be committed, they just affect the "view" of the repository.
>
> If we wc-to-wc copy such a tree the depth changes and switches are going
> to be "present" in the copy, that seems reasonable--it's a working copy
> only operation so only the items in the wc can get copied. It's how
> that copy gets committed that is the issue. In 1.7 the switch in the
> copy has become a local modification that gets committed as a replace.
> That's a change from 1.6 and it's also inconsistent with how switch
> behaves outside the copy, it's inconsistent with wc-to-URL copy, and
> it's inconsistent with the way the depth changes behave in the copy.
Ok, if I read this right you are assuming that that the switched path
doesn't have local modifications.
If that switched path does have local modifications then it must match the
base version of the copy source (or the commit cannot be processed).
We can't commit a copy from a different source then where it was copied from
(in this case from the switched location), without introducing all kinds of
assumptions like this 'it was not modified'
Yes, it would be nice to have the copy from the unswitched path.... Nice use
case, and certainly nice for better merge behavior later on.
But that requires unswitching it, by merging the differences.
We can't just make the commit processing provide a different copyfrom_url,
without handling the consequences.
In the old entries world, things were simple: We had only one url, so we had
to use that.... and we ignored the consequences (which would be cought by a
failing commit), which happened to work in some of the cases.
Once we start changing copy origins in arbitrary ways, how are we going to
guarantee that the commit processor knows how to apply them?
For the current model/implementation, designed by Erik and Greg, this
behavior is very well defined: better than ever before.
For a new translate switches in copies behavior it isn't.
And that we see a replacement, is probably because something was added as
op_depth 0 under the copy.
Our 'R'eplaced is currently ill-defined as there is an existing node in
BASE, and a normal node in working, while it should really look at op-roots,
etc.
(If you replace a subdir via a single copy, then you see the 'R' status
there, while it is not an op_root)
Bert
Received on 2011-04-12 14:00:36 CEST