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 2012/06/25 16:34:40 UTC

svn commit: r1353577 - /subversion/branches/1.7.x/STATUS

Author: stsp
Date: Mon Jun 25 14:34:39 2012
New Revision: 1353577

URL: http://svn.apache.org/viewvc?rev=1353577&view=rev
Log:
* STATUS: Nominate r1353572.

Modified:
    subversion/branches/1.7.x/STATUS

Modified: subversion/branches/1.7.x/STATUS
URL: http://svn.apache.org/viewvc/subversion/branches/1.7.x/STATUS?rev=1353577&r1=1353576&r2=1353577&view=diff
==============================================================================
--- subversion/branches/1.7.x/STATUS (original)
+++ subversion/branches/1.7.x/STATUS Mon Jun 25 14:34:39 2012
@@ -153,6 +153,14 @@ Candidate changes:
    Votes:
      +1: julianfoad
 
+ * r1353572
+   Fix a bug in propset which could prevent updating cached values related
+   to EOL expansion in wc.db.
+   Justification:
+     Incorrect behaviour, subtle working copy corruption.
+   Votes:
+     +1: stsp
+
 Veto-blocked changes:
 =====================
 



Re: svn commit: r1353577 - /subversion/branches/1.7.x/STATUS

Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:

> On Mon, Jun 25, 2012 at 05:21:53PM +0200, Bert Huijben wrote:
>> (I don't see how it can corrupt your working copy. It can make a local change unnoticed, but I wouldn't call that corrupted)
>> 
>> 	Bert
>
> I just meant to say that the db state is inconsistent with the
> expected state if this bug triggers. If that is not corruption,
> then we can label it "inconsistency" or whatever.

I'm trying to identify what exactly goes wrong.  The main way to trigger
the bug is "svn propdel svn:eol-style" when svn:keywords is not set.
The result is that translated_size remains set when it should be -1.
I think this could only be a problem when svn:eol-style changes the size
of the file, i.e. svn:eol-style=native on Windows, but I'm still not sure
what effect the bug will have.

A pristine file with content "fooLF" and svn:eol-style=native will have
a working file "fooCRLF" and translated_size=5 on Windows.  If we delete
the svn:eol-style what goes wrong?  I suppose the working file should get
converted to "fooLF" on commit.  Does this fail to occur?

-- 
Cerified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: svn commit: r1353577 - /subversion/branches/1.7.x/STATUS

Posted by Stefan Sperling <st...@elego.de>.
On Mon, Jun 25, 2012 at 05:21:53PM +0200, Bert Huijben wrote:
> (I don't see how it can corrupt your working copy. It can make a local change unnoticed, but I wouldn't call that corrupted)
> 
> 	Bert

I just meant to say that the db state is inconsistent with the
expected state if this bug triggers. If that is not corruption,
then we can label it "inconsistency" or whatever.

RE: svn commit: r1353577 - /subversion/branches/1.7.x/STATUS

Posted by Bert Huijben <be...@qqmail.nl>.

> -----Original Message-----
> From: stsp@apache.org [mailto:stsp@apache.org]
> Sent: maandag 25 juni 2012 16:35
> To: commits@subversion.apache.org
> Subject: svn commit: r1353577 - /subversion/branches/1.7.x/STATUS
> 
> Author: stsp
> Date: Mon Jun 25 14:34:39 2012
> New Revision: 1353577
> 
> URL: http://svn.apache.org/viewvc?rev=1353577&view=rev
> Log:
> * STATUS: Nominate r1353572.
> 
> Modified:
>     subversion/branches/1.7.x/STATUS
> 
> Modified: subversion/branches/1.7.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.7.x/STATUS?rev=1353
> 577&r1=1353576&r2=1353577&view=diff
> ==========================================================
> ====================
> --- subversion/branches/1.7.x/STATUS (original)
> +++ subversion/branches/1.7.x/STATUS Mon Jun 25 14:34:39 2012
> @@ -153,6 +153,14 @@ Candidate changes:
>     Votes:
>       +1: julianfoad
> 
> + * r1353572
> +   Fix a bug in propset which could prevent updating cached values related
> +   to EOL expansion in wc.db.
> +   Justification:
> +     Incorrect behaviour, subtle working copy corruption.
> +   Votes:
> +     +1: stsp

+1 on the patch for backport.
(I don't see how it can corrupt your working copy. It can make a local change unnoticed, but I wouldn't call that corrupted)

	Bert