You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Patrick Quirk <P....@smt.com> on 2011/10/12 20:55:46 UTC
Assertion Failed: workqueue.c
I upgraded to 1.7 yesterday when the new version of Tortoise came out, and used it with no issues last evening and today until I encountered this assertion:
In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\workqueue.c'
line 672: assertion failed (checksum != NULL)
Now any time I attempt anything (cleanup, update, commit, etc) in that WC I always get this assertion (using Tortoise or the command line). I got it first while running an update on my working copy after resolving a conflict (resolved using 'theirs'). This issues seems similar to this thread:
http://svn.haxx.se/dev/archive-2011-09/0079.shtml
...but there didn't seem to be a resolution there. Here's the action log from Tortoise; hopefully that can provide some more details. The first update was done on C:\Dev\GEM\Dom\Domains\Football and it finished after resolving the conflict. The second update was done on C:\Dev, and it asserted, as you can see.
--------------------------------------------
10/12/2011 - 2:25:49 PM
Command : Commit
Modified : C:\Dev\GEM\Dom\Domains\Football\GEMDomainFootball.csproj
Error : Commit failed (details follow):
Error : File or directory 'GEMDomainFootball.csproj' is out of date; try updating
Error : resource out of date; try updating
Completed! :
10/12/2011 - 2:26:02 PM
Command : Update
Updating : C:\Dev\GEM\Dom\Domains\Football
Conflicted : C:\Dev\GEM\Dom\Domains\Football\GEMDomainFootball.csproj
Updated : C:\Dev\GEM\Dom\Domains\Football\Top\Classes\FootballUtil.cs
Updated : C:\Dev\GEM\Dom\Domains\Football\Top\Classes\FootballPktProc.cs
Updated : C:\Dev\GEM\Dom\Domains\Football\Models\GSIS\Boxes\gbGSISFootballFeedHandler.cs
Updated : C:\Dev\GEM\Dom\Domains\Football\Models\GSIS\Controls\ctlNFLView.cs
Updated : C:\Dev\GEM\Dom\Domains\Football\Models\GSIS\Classes\GSISPktProc.cs
Updated : C:\Dev\GEM\Dom\Domains\Football\Models\STATS\Boxes\gbSTATSFootballFeedHandler.cs
Updated : C:\Dev\GEM\Dom\Domains\Football\Models\STATS\Boxes\gbSTATSFootballHandler.cs
Updated : C:\Dev\GEM\Dom\Domains\Football\Models\STATS\Classes\STATSPktProc.cs
Completed : At revision: 18993
Warning! : One or more files are in a conflicted state.
10/12/2011 - 2:28:49 PM
Command : Update
Updating : C:\Dev
Updated : C:\Dev\GEM\Dom\Domains\Hockey\Models\HockeyData\Boxes\gbHockeyUtopiaFeedHandler.cs
Updated : C:\Dev\GEM\Dom\Domains\Hockey\Models\HockeyData\Classes\HockeyTeam.cs
Updated : C:\Dev\GEM\Dom\Domains\Racing\Models\RacingUser\Boxes\gbPitClockPosition.cs
Updated : C:\Dev\GEM\Dom\Domains\Racing\Models\RacingUser\Classes\fdRacingPitClocksMovable.cs
Updated : C:\Dev\GEM\Blocks\GEMRenderGL\GEMRenderGL.csproj
Added : C:\Dev\GEM\Blocks\GEMRenderGL\Classes\gemGLRenderingContext.cs
Updated : C:\Dev\GEM\Blocks\GEMRender\GEMRender.csproj
Added : C:\Dev\GEM\Blocks\GEMRender\Classes\gemRenderingContext.cs
Updated : C:\Dev\GEM\Apps\GEMStudio\Controls\ctlProjectExplorer.Designer.cs
Updated : C:\Dev\GEM\Apps\GEMStudio\Controls\ctlProjectExplorer.cs
Updated : C:\Dev\GEM\Apps\GEMStudio\Classes\ProjectExplorerTool\CopyBehavior\CopyDirectoryBehavior.cs
Updated : C:\Dev\GEM\Apps\GEMStudio\Classes\ProjectExplorerTool\CopyBehavior\CopyImageSequenceBehavior.cs
Updated : C:\Dev\GEM\Apps\GEMStudio\Classes\ProjectExplorerTool\CopyBehavior\CopyBehavior.cs
Updated : C:\Dev\GEM\Apps\GEMStudio\Classes\ProjectExplorerTool\CopyBehavior\CopyFileBehavior.cs
Updated : C:\Dev\GEM\Apps\GEMStudio\Classes\ProjectExplorerTool\CopyBehavior\CopyNoneBehavior.cs
Updated : C:\Dev\GEM\Apps\GEMStudio\Classes\ProjectExplorerTool\ProjectExplorer.cs
Updated : C:\Dev\GEM\Apps\GEMStudio\Classes\ProjectExplorerTool\ProjectExplorerNode.cs
Updated : C:\Dev\GEM\Apps\GEMStudio\Classes\ProjectExplorerTool\ChildrenBehavior\LoadHotFilesBehavior.cs
Updated : C:\Dev\GEM\Apps\GEMStudio\Classes\ProjectExplorerTool\Util\CutCopyPasteHandler.cs
Updated : C:\Dev\Racing\VS.IRL\VS.IRL.csproj
Added : C:\Dev\Racing\VS.IRL\Classes\fdRacingPitClocksMovableIRL.cs
Updated : C:\Dev\Studio\SMT.DMX\Controls\ctlBoxScore.resx
Updated : C:\Dev\Studio\SMT.DMX\Controls\ctlBoxScore.Designer.cs
Updated : C:\Dev\Studio\SMT.DMX\Controls\ctlBoxScore.cs
Added : C:\Dev\Studio\VS.ALL\Classes\fdStudioGameGridVS.cs
Updated : C:\Dev\Studio\VS.ALL\Classes\iscStudioWallPilotVS.cs
Added : C:\Dev\X\MONSTER.FMX
Added : C:\Dev\X\MONSTER.FMX\MONSTER.FMX.csproj
Added : C:\Dev\X\MONSTER.FMX\Boxes
Added : C:\Dev\X\MONSTER.FMX\Boxes\gbFMXDisplay.resx
Added : C:\Dev\X\MONSTER.FMX\Boxes\gbFMXDisplay.Designer.cs
Added : C:\Dev\X\MONSTER.FMX\Boxes\gbFMXDisplay.cs
Error : In file
Error : 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\workqueue.c'
Error : line 672: assertion failed (checksum != NULL)
Completed! :
39 kBytes transferred in 0 minute(s) and 35 second(s)
10/12/2011 - 2:28:56 PM
Command : Update
Error : Previous operation has not finished; run 'cleanup' if it was interrupted
Error : Please execute the 'Cleanup' command.
Completed! :
RE: Assertion Failed: workqueue.c
Posted by Patrick Quirk <P....@smt.com>.
> Another question: Did the reporters get here by doing a copy and then
> cancelling, or did they perform an upgrade of a copied tree?
> (I missed the verification of this on the mailing list. Maybe the current
> user problem is in the upgrade/write entries code?)
I got into this state by starting with a 1.6.17 WC (not copied from anywhere) and upgraded to 1.7 final. I had done multiple operations (updates/commits/revert/etc) over the course of a day before it happened.
Re: Assertion Failed: workqueue.c
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> What I propose is that copy only produces the incomplete state for nodes
> that are copies (or copies of copies) of repository nodes. Copy would
> not produce the incomplete state for copies of added nodes. When an
> added node is copied the copy is an added note completely separate from
> the source and if an interrupted copy causes it to have fewer children
> this is not the same as the copy of a repository node having missing
> children.
It appears that wc-to-wc copy already works this way as far as setting
incomplete. That makes me more confident that r1177732 is the correct
approach:
- read_info converts working/incomplete to status=added,
- scan_addition returns status=incomplete
- callers of scan_addition are responsible for handling
status=incomplete (in lots of cases like status=copied)
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Assertion Failed: workqueue.c
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@qqmail.nl> writes:
> How can you recover from this state?
> Can you delete the incomplete node? (It's parent?) or is the only way to
> recover to revert the root of the copy operation?
> If only that last case is true I wouldn't call it a defined database state.
I don't really understand the question. At present an interrupted copy
leaves working nodes in state incomplete. There is no way to complete
the nodes, other than reverting and starting the copy again.
What I propose is that copy only produces the incomplete state for nodes
that are copies (or copies of copies) of repository nodes. Copy would
not produce the incomplete state for copies of added nodes. When an
added node is copied the copy is an added note completely separate from
the source and if an interrupted copy causes it to have fewer children
this is not the same as the copy of a repository node having missing
children.
So incomplete would mean "this repository node is incomplete" for base
nodes and "this copy of a repository node is incomplete" for working
nodes. It would not mean "some user operation was interrupted".
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
RE: Assertion Failed: workqueue.c
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: zaterdag 15 oktober 2011 3:29
> To: Patrick Quirk
> Cc: Philip Martin; dev@subversion.apache.org
> Subject: Re: Assertion Failed: workqueue.c
>
> Philip Martin <ph...@wandisco.com> writes:
>
> > I've raised issue 4035
> > http://subversion.tigris.org/issues/show_bug.cgi?id=4035
> > It looks like it's already fixed on trunk.
>
> Some thoughts about incomplete working nodes.
>
> Ideally wc-to-wc copy would be a single db transaction, then we could
> fail the whole copy on nodes that are impossible to copy--excluded by
> the authz, incomplete, etc. This would allow us to ban incomplete
> working nodes.
>
> However wc-to-wc copy is currently a transaction per node, so the copy
> can fail part way through. This means incomplete nodes are intrinsic to
> the copy operation: when a directory is copied we add incomplete nodes
> for the children. At present we add incomplete nodes for all direct
> children of any copied directory.
>
> Incomplete working nodes are a problem for the read/scan API. The
> change I made for issue 4025 changes read_info so that it reports
> incomplete working nodes as added, rather than incomplete, while
> scan_addition reports them as incomplete. This allows us to treat
> incomplete working nodes as working nodes rather than base nodes.
> However it still leaves us with the problem that we lose the
> added/copied difference.
>
> One solution would be to swich to single transaction wc-to-wc copy, but
> that is a lot of work. Probably easier is to tweak the existing copy
> code. We distinguish between the nodes that scan_addition reports as
> copied: copies of base nodes or copies of copies of base nodes, from
> nodes that scan_addition reports as added: copies of added nodes. Then
> we only ever add incomplete nodes for the copied nodes. That would mean
> that the caller of scan_addition could treat incomplete as copied,
> similar to the way an incomplete base node is treated as normal. An
> itnterrupted wc-to-wc copy would show as incomplete any partially copied
> repository node, but a partially copied added hierarchy would no longer
> show as incomplete. I believe this means the database is correct and
> valid.
How can you recover from this state?
Can you delete the incomplete node? (It's parent?) or is the only way to
recover to revert the root of the copy operation?
If only that last case is true I wouldn't call it a defined database state.
Another question: Did the reporters get here by doing a copy and then
cancelling, or did they perform an upgrade of a copied tree?
(I missed the verification of this on the mailing list. Maybe the current
user problem is in the upgrade/write entries code?)
Bert
Re: Assertion Failed: workqueue.c
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> I've raised issue 4035
> http://subversion.tigris.org/issues/show_bug.cgi?id=4035
> It looks like it's already fixed on trunk.
Some thoughts about incomplete working nodes.
Ideally wc-to-wc copy would be a single db transaction, then we could
fail the whole copy on nodes that are impossible to copy--excluded by
the authz, incomplete, etc. This would allow us to ban incomplete
working nodes.
However wc-to-wc copy is currently a transaction per node, so the copy
can fail part way through. This means incomplete nodes are intrinsic to
the copy operation: when a directory is copied we add incomplete nodes
for the children. At present we add incomplete nodes for all direct
children of any copied directory.
Incomplete working nodes are a problem for the read/scan API. The
change I made for issue 4025 changes read_info so that it reports
incomplete working nodes as added, rather than incomplete, while
scan_addition reports them as incomplete. This allows us to treat
incomplete working nodes as working nodes rather than base nodes.
However it still leaves us with the problem that we lose the
added/copied difference.
One solution would be to swich to single transaction wc-to-wc copy, but
that is a lot of work. Probably easier is to tweak the existing copy
code. We distinguish between the nodes that scan_addition reports as
copied: copies of base nodes or copies of copies of base nodes, from
nodes that scan_addition reports as added: copies of added nodes. Then
we only ever add incomplete nodes for the copied nodes. That would mean
that the caller of scan_addition could treat incomplete as copied,
similar to the way an incomplete base node is treated as normal. An
itnterrupted wc-to-wc copy would show as incomplete any partially copied
repository node, but a partially copied added hierarchy would no longer
show as incomplete. I believe this means the database is correct and
valid.
Note: I'm discussing this in 1.7 terms where moved from/to doesn't
really exist.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Assertion Failed: workqueue.c
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Philip Martin <ph...@wandisco.com> writes:
>
>> and then running update, but I haven't yet managed to reproduce the
>> assert.
>
> Think I've got it:
I've raised issue 4035
http://subversion.tigris.org/issues/show_bug.cgi?id=4035
It looks like it's already fixed on trunk.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Assertion Failed: workqueue.c
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> and then running update, but I haven't yet managed to reproduce the
> assert.
Think I've got it:
svnadmin create repo
svn mkdir -mm file://`pwd`/repo/A
svn import -mm repo/format file://`pwd`/repo/A/f
svn co file://`pwd`/repo wc -r1
# insert bogus incomplete working node
sqlite3 wc/.svn/wc.db "insert into nodes (wc_id, local_relpath, op_depth, parent_relpath, presence, kind, depth) values (1, 'A', 1, '', 'incomplete', 'dir', 'infinity')"
svn up wc
svn: E235000: In file '../src-1.7/subversion/libsvn_wc/workqueue.c' line 672: assertion failed (checksum != NULL)
Aborted
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Assertion Failed: workqueue.c
Posted by Philip Martin <ph...@wandisco.com>.
[Moving to dev]
Patrick Quirk <P....@smt.com> writes:
> The 'X' folder was not and should not have been deleted or marked for
> deletion in the working copy or in the repository. The MONSTER.FMX
> folder was added beneath it and was pulled down for the first time
> during that update.
Patrick was kind enough to send me his wc.db file:
sqlite3 .svn/wc.db "select op_depth, local_relpath, presence, revision from nodes where local_relpath like 'X%'"
1|X|incomplete|
0|X|incomplete|18993
0|X/NBC.REDBULL|normal|18972
0|X/NBC.REDBULL/NBC.REDBULL.sln|normal|18972
0|X/NBC.REDBULL/NBC.REDBULL.csproj|normal|18972
0|X/NBC.REDBULL/Boxes|normal|18972
0|X/NBC.REDBULL/Controls|normal|18972
0|X/NBC.REDBULL/Forms|normal|18972
0|X/NBC.REDBULL/Resources|normal|18972
0|X/NBC.REDBULL/Resources/button face.png|normal|18972
0|X/NBC.REDBULL/Properties|normal|18972
0|X/NBC.REDBULL/Properties/AssemblyInfo.cs|normal|18972
0|X/NBC.REDBULL/Properties/Resources.resx|normal|18972
0|X/NBC.REDBULL/Properties/Resources.Designer.cs|normal|18972
0|X/NBC.REDBULL/Classes|normal|18972
0|X/NBC.REDBULL/Views|normal|18972
0|X/NBC.REDBULL/Views/Live|normal|18972
0|X/NBC.REDBULL/Views/Stat|normal|18972
0|X/MSI.SKATE|normal|18972
0|X/MSI.SKATE/MSI.SKATE.sln|normal|18972
0|X/MSI.SKATE/MSI.SKATE.csproj|normal|18972
0|X/MSI.SKATE/Boxes|normal|18972
0|X/MSI.SKATE/Boxes/gbSkateDisplay.resx|normal|18972
0|X/MSI.SKATE/Boxes/gbSkateDisplay.Designer.cs|normal|18972
0|X/MSI.SKATE/Boxes/gbSkateDisplay.cs|normal|18972
0|X/MSI.SKATE/Controls|normal|18972
0|X/MSI.SKATE/Forms|normal|18972
0|X/MSI.SKATE/Resources|normal|18972
0|X/MSI.SKATE/Resources/button face.png|normal|18972
0|X/MSI.SKATE/Properties|normal|18972
0|X/MSI.SKATE/Properties/AssemblyInfo.cs|normal|18972
0|X/MSI.SKATE/Properties/Resources.resx|normal|18972
0|X/MSI.SKATE/Properties/Resources.Designer.cs|normal|18972
0|X/MSI.SKATE/Classes|normal|18972
0|X/MSI.SKATE/Views|normal|18972
0|X/MSI.SKATE/Views/Live|normal|18972
0|X/MSI.SKATE/Views/Stat|normal|18972
0|X/MONSTER.FMX|incomplete|18993
1|X/MONSTER.FMX|base-deleted|
0|X/MONSTER.FMX/MONSTER.FMX.csproj|normal|18993
1|X/MONSTER.FMX/MONSTER.FMX.csproj|base-deleted|
1|X/MONSTER.FMX/Boxes|base-deleted|
0|X/MONSTER.FMX/Boxes/gbFMXDisplay.resx|normal|18993
1|X/MONSTER.FMX/Boxes/gbFMXDisplay.resx|base-deleted|
0|X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs|normal|18993
1|X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs|base-deleted|
0|X/MONSTER.FMX/Boxes/gbFMXDisplay.cs|normal|18993
1|X/MONSTER.FMX/Boxes/gbFMXDisplay.cs|base-deleted|
0|X/MONSTER.FMX/Boxes|normal|18993
The only nodes in the wc with op-depth > 0 are in the above list. The
items in the workqueue:
sqlite3 .svn/wc.db "select * from work_queue"
79|(file-install X/MONSTER.FMX/MONSTER.FMX.csproj 1 0 1 1)
80|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.resx 1 0 1 1)
81|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs 1 0 1 1)
82|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.cs 1 0 1 1)
all have checksums at op-depth=0 and those checksums all have
corresponding entries in PRISTINE, but the nodes also all have
op-depth=1 rows that are base-deleted. These rows don't have checksums,
which is expected for base-deleted rows, and that is what causes the
assert.
Where did those rows come from? I don't know, but op-depth=1 indicates
that they are related to the 'X' row at op-depth=1. That row is
'incomplete', I'm not sure how or when that happened. Did it exist
before the update? Did the update change it to 'incomplete' from
something else? If 'X' was base-deleted then the whole tree should be
base-deleted as well.
I've tried to reproduce it with test repo/wc by inserting a spurious
row of various kinds:
sqlite3 wc/.svn/wc.db "insert into nodes (wc_id, local_relpath, op_depth, parent_relpath, presence, kind, depth) values (1, 'A', 1, '', 'base-deleted', 'dir', 'infinity')"
and then running update, but I haven't yet managed to reproduce the
assert.
--
Philip
RE: Assertion Failed: workqueue.c
Posted by Patrick Quirk <P....@smt.com>.
>>> So now we want to see the nodes row for each of those four paths:
>>>
>>> sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/MONSTER.FMX.csproj'"
>>> sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.resx'"
>>> sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs'"
>>> sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.cs'"
>>
>> I've attached the output since it's a little unreadable in 80 column format.
>
> Thanks! So each file has an op-depth=0, presence=normal line that has a
> checksum. Can you verify that each checksum exists in pristine:
>
> sqlite3 .svn/wc.db "select * from pristine where checksum ='$sha1$a6fb31cbea18a2f670e5d1387b2a1b118f831f09'"
> sqlite3 .svn/wc.db "select * from pristine where checksum ='$sha1$9addd651cd4260ee52b26cf5eae2d2bfe798aba5'"
> sqlite3 .svn/wc.db "select * from pristine where checksum ='$sha1$041ffe70415ce290a4f14a770d869e2eb3b420e8'"
> sqlite3 .svn/wc.db "select * from pristine where checksum ='$sha1$ea6871c7f57dd63e0a74ac0fd19435232322e5ff'"
These queries returned no results.
> What I don't yet understand is why each file also has an op-depth=1,
> presence=base-deleted row. That seems to imply that 'X' is deleted in
> the working copy, so we should see two lines here:
>
> sqlite3 .svn/wc.db "select op_depth, presence from nodes where local_relpath='X'"
This returned:
1|incomplete
0|incomplete
The 'X' folder was not and should not have been deleted or marked for
deletion in the working copy or in the repository. The MONSTER.FMX
folder was added beneath it and was pulled down for the first time
during that update.
Re: Assertion Failed: workqueue.c
Posted by Philip Martin <ph...@wandisco.com>.
Patrick Quirk <P....@smt.com> writes:
>>>> Is the sqlite3 utility readily available on Windows? If it is then run:
>>>> sqlite3 .svn/wc.db "select * from work_queue"
>>>
>>> Yep, here's the output:
>>> 79|(file-install X/MONSTER.FMX/MONSTER.FMX.csproj 1 0 1 1)
>>> 80|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.resx 1 0 1 1)
>>> 81|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs 1 0 1 1)
>>> 82|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.cs 1 0 1 1)
>>>
>>> These are files that were new from the repo and were the last to show up
>>> before the assertion appeared.
>>
>> So now we want to see the nodes row for each of those four paths:
>>
>> sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/MONSTER.FMX.csproj'"
>> sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.resx'"
>> sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs'"
>> sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.cs'"
>
> I've attached the output since it's a little unreadable in 80 column format.
Thanks! So each file has an op-depth=0, presence=normal line that has a
checksum. Can you verify that each checksum exists in pristine:
sqlite3 .svn/wc.db "select * from pristine where checksum ='$sha1$a6fb31cbea18a2f670e5d1387b2a1b118f831f09'"
sqlite3 .svn/wc.db "select * from pristine where checksum ='$sha1$9addd651cd4260ee52b26cf5eae2d2bfe798aba5'"
sqlite3 .svn/wc.db "select * from pristine where checksum ='$sha1$041ffe70415ce290a4f14a770d869e2eb3b420e8'"
sqlite3 .svn/wc.db "select * from pristine where checksum ='$sha1$ea6871c7f57dd63e0a74ac0fd19435232322e5ff'"
What I don't yet understand is why each file also has an op-depth=1,
presence=base-deleted row. That seems to imply that 'X' is deleted in
the working copy, so we should see two lines here:
sqlite3 .svn/wc.db "select op_depth, presence from nodes where local_relpath='X'"
--
Philip
RE: Assertion Failed: workqueue.c
Posted by Patrick Quirk <P....@smt.com>.
>>> Is the sqlite3 utility readily available on Windows? If it is then run:
>>> sqlite3 .svn/wc.db "select * from work_queue"
>>
>> Yep, here's the output:
>> 79|(file-install X/MONSTER.FMX/MONSTER.FMX.csproj 1 0 1 1)
>> 80|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.resx 1 0 1 1)
>> 81|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs 1 0 1 1)
>> 82|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.cs 1 0 1 1)
>>
>> These are files that were new from the repo and were the last to show up
>> before the assertion appeared.
>
> So now we want to see the nodes row for each of those four paths:
>
> sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/MONSTER.FMX.csproj'"
> sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.resx'"
> sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs'"
> sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.cs'"
I've attached the output since it's a little unreadable in 80 column format.
Re: Assertion Failed: workqueue.c
Posted by Philip Martin <ph...@wandisco.com>.
Patrick Quirk <P....@smt.com> writes:
>> Is the sqlite3 utility readily available on Windows? If it is then run:
>> sqlite3 .svn/wc.db "select * from work_queue"
>
> Yep, here's the output:
> 79|(file-install X/MONSTER.FMX/MONSTER.FMX.csproj 1 0 1 1)
> 80|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.resx 1 0 1 1)
> 81|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs 1 0 1 1)
> 82|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.cs 1 0 1 1)
>
> These are files that were new from the repo and were the last to show up
> before the assertion appeared.
So now we want to see the nodes row for each of those four paths:
sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/MONSTER.FMX.csproj'"
sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.resx'"
sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs'"
sqlite3 .svn/wc.db "select * from nodes where local_relpath='X/MONSTER.FMX/Boxes/gbFMXDisplay.cs'"
--
Philip
RE: Assertion Failed: workqueue.c
Posted by Patrick Quirk <P....@smt.com>.
> Is this a working copy that you checked-out with the old 1.6 Tortoise
> and upgraded to 1.7, or is it a working copy that you checked-out with
> 1.7?
This is a 1.6.17 working copy that was upgraded.
> A text-conflict or a tree-conflict? Do you have any local modifications
> to the working copy? Adds, deletes, copies etc.?
Text-conflict to a single file. I had local modifications but resolved the
conflict by using the repository's version of the file (the update was a
superset of my changes).
> Is the sqlite3 utility readily available on Windows? If it is then run:
> sqlite3 .svn/wc.db "select * from work_queue"
Yep, here's the output:
79|(file-install X/MONSTER.FMX/MONSTER.FMX.csproj 1 0 1 1)
80|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.resx 1 0 1 1)
81|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.Designer.cs 1 0 1 1)
82|(file-install X/MONSTER.FMX/Boxes/gbFMXDisplay.cs 1 0 1 1)
These are files that were new from the repo and were the last to show up
before the assertion appeared.
Re: Assertion Failed: workqueue.c
Posted by Philip Martin <ph...@codematters.co.uk>.
Patrick Quirk <P....@smt.com> writes:
> I upgraded to 1.7 yesterday when the new version of Tortoise came out,
> and used it with no issues last evening and today until I encountered
> this assertion:
>
> In file
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\workqueue.c'
> line 672: assertion failed (checksum != NULL)
Is this a working copy that you checked-out with the old 1.6 Tortoise
and upgraded to 1.7, or is it a working copy that you checked-out with
1.7?
> Now any time I attempt anything (cleanup, update, commit, etc) in that
> WC I always get this assertion (using Tortoise or the command line).
> I got it first while running an update on my working copy after
> resolving a conflict (resolved using 'theirs').
A text-conflict or a tree-conflict? Do you have any local modifications
to the working copy? Adds, deletes, copies etc.?
Is the sqlite3 utility readily available on Windows? If it is then run:
sqlite3 .svn/wc.db "select * from work_queue"
--
Philip