You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2013/05/25 11:22:35 UTC
Re: svn commit: r1486044 -
Bert Huijben <be...@qqmail.nl> writes:
> The diff command should never change the wc(no wclock, and no
> db/pristine changes), so I really hope the problem that corrupts is
> part of the merge on update, or we should check for another problem.
>
> Bert From: stsp@apache.org
> Sent: =E2=80=8E24/=E2=80=8E05/=E2=80=8E2013 15:15
> To: commits@subversion.apache.org
> Subject: svn commit: r1486044
> - /subversion/trunk/subversion/libsvn_subr/subst.c
> Author: stsp
> Date: Fri May 24 13:15:34 2013
> New Revision: 1486044
>
> URL: http://svn.apache.org/r1486044
> Log:
> Revert r1485848 because it caused segfaults in 'svn diff' on a working
> copy of Subversion's own trunk. The working copy is corrupted after
> the crash, some working files contain binary garbage.
In my case it was merge that corrupted the working file that was being
altered, the diff problem was just a SEGV.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: svn commit: r1486044 -
Posted by Stefan Sperling <st...@apache.org>.
On Sat, May 25, 2013 at 10:22:35AM +0100, Philip Martin wrote:
> Bert Huijben <be...@qqmail.nl> writes:
> > The diff command should never change the wc(no wclock, and no
> > db/pristine changes), so I really hope the problem that corrupts is
> > part of the merge on update, or we should check for another problem.
>
> In my case it was merge that corrupted the working file that was being
> altered, the diff problem was just a SEGV.
I believe I also ran 'svn update' using the broken client.
It might not have been 'svn diff' that corrupted the files.
Re: svn commit: r1486044 -
Posted by Stefan Sperling <st...@apache.org>.
On Sat, May 25, 2013 at 10:22:35AM +0100, Philip Martin wrote:
> Bert Huijben <be...@qqmail.nl> writes:
> > The diff command should never change the wc(no wclock, and no
> > db/pristine changes), so I really hope the problem that corrupts is
> > part of the merge on update, or we should check for another problem.
>
> In my case it was merge that corrupted the working file that was being
> altered, the diff problem was just a SEGV.
I believe I also ran 'svn update' using the broken client.
It might not have been 'svn diff' that corrupted the files.