Hi Bert, Bert Huijben wrote: >> + * r891672 >> + Fix issue #3552 - File external from URL cannot overwrite the existing >> + versioned item >> + Justification: >> + This defect affects 'subversive' client users in 1.6.x. >> + Notes: >> + The backport branch exists in order to make the patch compatible with >> + 1.6.x tests. r876917 introduces 'switched' to wc status which is not >> + available in 1.6.x. >> + Branch: >> + ^/subversion/branches/1.6.x-r891672 >> + Votes: >> + +1: stylesen > > Hi, > > If I read the implementation of this fix correctly it fixes the 'cannot > overwrite' by not trying to overwrite?
No this is not what the fix does. > Is this really the way we intend to fix this? Or should we delete it > correctly (replacing it with the external), so you get a real copy of > everything in this directory? This fix is intended to not commit a file external like a normal working copy file. When there is a file externals in the working copy, harvest_committables function does not distinguish that and thinks it is a normal file in the working copy. Hence, during a copy of tags from a working copy to the URL, everything in the working copy is copied to the new tag URL. This is a problem because in the server there is no mechanism in place to distinguish a file external (unlike the working copy) apart from the svn:externals property. So when the user checks out the tag, we get the file external pulled to the working copy and then again due to the svn:externals property the file is again sent by the server which fails. > Another point I noted in another mail is that adding special behavior on file > externals makes things hard for future Subversion versions, as there is no > hard distinction between a switched file and a file external. (For directory > externals a directory is only external if you look at it from a parent > working copy). Yes I agree with this. > Another point it that the ignore-externals flag passed to svn_client_copyX() > is ignored/flawed in more code paths then just this one. > > E.g. on 'svn cp URL URL', we don't even look at the externals property. > > I think this function and file externals in general need a better design for > our future versions. +1 Thank You. -- Senthil Kumaran S http://www.stylesen.org/
