Re: svn commit: r892190 - /subversion/branches/1.6.x/STATUS

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/