You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by st...@apache.org on 2009/12/18 10:17:51 UTC
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=892190&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
+
Veto-blocked changes:
* r877552, r877617, r877618, r877619, r877621
Re: svn commit: r892190 - /subversion/branches/1.6.x/STATUS
Posted by Senthil Kumaran S <se...@collab.net>.
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/
RE: svn commit: r892190 - /subversion/branches/1.6.x/STATUS
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: stylesen@apache.org [mailto:stylesen@apache.org]
> Sent: vrijdag 18 december 2009 10:18
> To: commits@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
RE: svn commit: r892190 - /subversion/branches/1.6.x/STATUS
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: stylesen@apache.org [mailto:stylesen@apache.org]
> Sent: vrijdag 18 december 2009 10:18
> To: commits@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