> -----Original Message-----
> From: style...@apache.org [mailto:style...@apache.org]
> Sent: vrijdag 18 december 2009 10:18
> To: comm...@subversion.apache.org
> Subject: svn commit: r892190 - /subversion/branches/1.6.x/STATUS
>
> Author: stylesen
> Date: Fri Dec 18 09:17:48 2009
> New Revision: 892190
>
> URL: http://svn.apache.org/viewvc?rev=892190&view=rev
> Log:
> * STATUS: Nominate and vote for r891672.
>
> Modified:
> subversion/branches/1.6.x/STATUS
>
> Modified: subversion/branches/1.6.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.6.x/STATUS?rev=8921
> 90&r1=892189&r2=892190&view=diff
> ==========================================================
> ====================
> --- subversion/branches/1.6.x/STATUS (original)
> +++ subversion/branches/1.6.x/STATUS Fri Dec 18 09:17:48 2009
> @@ -137,6 +137,20 @@
> Votes:
> +1: pburba
>
> + * 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?
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?
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).
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.
For now I would add a -0 vote. (Non blocking negative).
Bert
