> -----Original Message-----
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: vrijdag 18 mei 2012 8:07
> To: Bert Huijben
> Cc: Hyrum K Wright; dev@subversion.apache.org
> Subject: Re: svn commit: r1339892 -
>
> On Fri, May 18, 2012 at 1:57 AM, Greg Stein <gst...@gmail.com> wrote:
> > On Fri, May 18, 2012 at 1:34 AM, Bert Huijben <b...@vmoo.com> wrote:
> >>
> >> Editor v1 only requires the revision for base node replacements and I
> >> don't see why we need to change that for v2.
> >>
> >> If we copied a subtree from a revision we know that that revision
> >> didn't change. How could it be out of date?
> >
> > The FS does not remember where changes came from, without some deep
> > inspection. If we see "/some/path", then we don't know how it got
> > there. Whether it started there, or whether it was copied there.
> >
> > Now... that said, I just realized that passing the parent revision
> > will not work, because the path will not be found in that target
> > revision.
> >
> > So, yeah: we need to somehow enable passing SVN_INVALID_REVNUM for the
> > children of copies. That is equivalent to the Ev1 behavior: "I'm
> > replacing an uncommitted item". It looks like we can use
> > svn_fs_closest_copy() to determine if a txn node (or an ancestor) has
> > been copied to that target location.
>
> Some more thinking...
>
> But we do need some sort of check in here. We should not allow add_*()
> to overwrite a copied-child. But a copy() can do so IFF it is part of
> a mixed-rev copy. But what about a secondary copy operation over a
> child?
+1 I agree that we should still check for overwriting existing nodes (and
anything else we can think of that doesn't really hurt performance)
> At some point, we just assume the client is working properly. Maybe we
> just omit all OOD checks under copies. But that doesn't really manager
> improper overwrites...
>
> Hrm...
Bert
