[Moving to dev] Patrick Quirk <p.qu...@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
