You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by BIRD Neil <Ne...@uk.thalesgroup.com> on 2013/10/25 09:59:49 UTC

SVN 1.8.3 crash (witrhin TSVN)

  Just encountered the following while doing an update;  the TSVN output had just warned of a file conflict, then come back with thinking it had automatically resolved it:

<snip-and-edited>
Updated:  OTHER.h  text/plain
Completed: At revision: 1547  
Warning!: One or more files are in a conflicted state.  
Updated: PATH\PROJ.sln  
Completed: At revision: 1547  
Resolved: PATH\PROJ.sln  


  A subsequent update has done nothing further, and claims it's done OK.


  The error is:

---------------------------
Subversion Exception!
---------------------------
<snip>

In file
 'D:\Development\SVN\Releases\TortoiseSVN-1.8.2\ext\subversion\subversion\libsvn_wc\wc_db_update_move.c'
 line 1039: assertion failed (move_dst_revision == expected_move_dst_revision
 || status == svn_wc__db_status_not_present)
---------------------------
OK   
---------------------------


  I believe TSVN 1.8.2 is built against SVN 1.8.3.  Anyway, the error appears to be in SVN code, not TSVN.

-- 
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit


RE: SVN 1.8.3 crash (witrhin TSVN)

Posted by BIRD Neil <Ne...@uk.thalesgroup.com>.
From: Bert Huijben [mailto:bert@qqmail.nl], Sent: Friday, October 25, 2013 9:46 AM
> Can you post an 'svn status' output of your working copy?

  Not a full one;  I do have an unresolved file conflict (along with a few other normal edits), which would have been the case when I did the update:

D     C drx\Source\Workspaces\Project\gnu-projectname.mak
        > moved to drx\Source\Workspaces\Project\gnu-project.mak
      >   local file moved away, incoming file edit upon update


> Without this (or a reproduction script that shows us in what state
> your working is in) your bug report contains not enough
> information to diagnose.

  Figured as much, but I thought I'd mention it (as the popup asked me to).

  I'll keep an eye on it (e.g., in case that file gets changed remotely again).


  It's probably worth mentioning that this particular manoeuvre (the file rename) was done with SVN 1.7.x, and the WC was upgraded to 1.8 with that unchecked-in, in case the new 1.8 rename methodology is at play/fault here.

-- 
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit



RE: SVN 1.8.3 crash (witrhin TSVN)

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

> -----Original Message-----
> From: BIRD Neil [mailto:Neil.BIRD@uk.thalesgroup.com]
> Sent: vrijdag 25 oktober 2013 10:00
> To: 'dev@subversion.apache.org'
> Subject: SVN 1.8.3 crash (witrhin TSVN)
> 
>   Just encountered the following while doing an update;  the TSVN output
> had just warned of a file conflict, then come back with thinking it had
> automatically resolved it:
> 
> <snip-and-edited>
> Updated:  OTHER.h  text/plain
> Completed: At revision: 1547
> Warning!: One or more files are in a conflicted state.
> Updated: PATH\PROJ.sln
> Completed: At revision: 1547
> Resolved: PATH\PROJ.sln
> 
> 
>   A subsequent update has done nothing further, and claims it's done OK.

Can you post an 'svn status' output of your working copy?

Without this (or a reproduction script that shows us in what state your working is in) your bug report contains not enough information to diagnose.

> In file
>  'D:\Development\SVN\Releases\TortoiseSVN-
> 1.8.2\ext\subversion\subversion\libsvn_wc\wc_db_update_move.c'
>  line 1039: assertion failed (move_dst_revision ==
> expected_move_dst_revision
>  || status == svn_wc__db_status_not_present)

It is quite possible that the issue is resolved in Subversion 1.8.4, via the issue #4436 fixes, but it is hard to tell without a way to reproduce.
(I know I got this exact error when I wrote a reproduction test for issue #4436 and it was gone when it was fixed)

There are still a few related problems open on trunk, but we need some good regression tests to see how we need to fix these, and if these cases match your problem.

	Bert