use new name for new format export dbs

Delete the old export dbs on upgrade.

Testing this an exporting to a directory with both exporttree=yes and
importtree=yes, it refused to let an interrupted export proceed after
upgrade, with "unsafe to overwrite file". An import resolved the
problem.

Annex/Locations.hs

@@ -48,6 +48,7 @@ module Annex.Locations (
 	gitAnnexFsckResultsLog,
 	gitAnnexSmudgeLog,
 	gitAnnexSmudgeLock,
+	gitAnnexExportDir,
 	gitAnnexExportDbDir,
 	gitAnnexExportLock,
 	gitAnnexExportUpdateLock,
@@ -329,7 +330,11 @@ gitAnnexFsckState u r = gitAnnexFsckDir u r </> "state"
 
 {- Directory containing database used to record fsck info. -}
 gitAnnexFsckDbDir :: UUID -> Git.Repo -> FilePath
-gitAnnexFsckDbDir u r = gitAnnexFsckDir u r </> "db"
+gitAnnexFsckDbDir u r = gitAnnexFsckDir u r </> "fsckdb"
+
+{- Directory containing old database used to record fsck info. -}
+gitAnnexFsckDbDirOld :: UUID -> Git.Repo -> FilePath
+gitAnnexFsckDbDirOld u r = gitAnnexFsckDir u r </> "db"
 
 {- Lock file for the fsck database. -}
 gitAnnexFsckDbLock :: UUID -> Git.Repo -> FilePath
@@ -347,14 +352,14 @@ gitAnnexSmudgeLog r = gitAnnexDir r </> "smudge.log"
 gitAnnexSmudgeLock :: Git.Repo -> FilePath
 gitAnnexSmudgeLock r = gitAnnexDir r </> "smudge.lck"
 
-{- .git/annex/export/uuid/ is used to store information about
+{- .git/annex/export/ is used to store information about
  - exports to special remotes. -}
-gitAnnexExportDir :: UUID -> Git.Repo -> FilePath
-gitAnnexExportDir u r = gitAnnexDir r </> "export" </> fromUUID u
+gitAnnexExportDir :: Git.Repo -> FilePath
+gitAnnexExportDir r = gitAnnexDir r </> "export"
 
 {- Directory containing database used to record export info. -}
 gitAnnexExportDbDir :: UUID -> Git.Repo -> FilePath
-gitAnnexExportDbDir u r = gitAnnexExportDir u r </> "db"
+gitAnnexExportDbDir u r = gitAnnexExportDir r </> fromUUID u </> "exportdb"
 
 {- Lock file for export state for a special remote. -}
 gitAnnexExportLock :: UUID -> Git.Repo -> FilePath

Upgrade/V7.hs

@@ -13,7 +13,6 @@ import Annex.Common
 import Annex.CatFile
 import qualified Database.Keys
 import qualified Database.Keys.SQL
-import qualified Database.ContentIdentifier
 import qualified Git.LsFiles as LsFiles
 import qualified Git
 import Git.FilePath
@@ -22,8 +21,6 @@ upgrade :: Bool -> Annex Bool
 upgrade automatic = do
 	unless automatic $
 		showAction "v7 to v8"
-	
-	populateKeysDb
 
 	-- The fsck databases are not transitioned here; any running
 	-- incremental fsck can continue to write to the old database.
@@ -36,6 +33,12 @@ upgrade automatic = do
 	removeOldDb gitAnnexContentIdentifierDbDirOld
 	liftIO . nukeFile =<< fromRepo gitAnnexContentIdentifierLockOld
 
+	-- The export databases are deleted here. The new databases
+	-- will be populated by the next thing that needs them, the same
+	-- way as they would be in a fresh clone.
+	removeOldDb gitAnnexExportDir
+
+	populateKeysDb
 	removeOldDb gitAnnexKeysDbOld
 	liftIO . nukeFile =<< fromRepo gitAnnexKeysDbIndexCacheOld
 	liftIO . nukeFile =<< fromRepo gitAnnexKeysDbLockOld

doc/todo/sqlite_database_improvements.mdwn

@@ -115,8 +115,12 @@ remaining todo:
 >   clone being used to update the export. The clone can only learn
 >   export state from the log. It's supposed to recover from such
 >   situations, the next time an export is run, so should be ok.
->   But it might result in already exported files being re-uploaded,
->   or other unncessary work.
+>
+>   Testing this an exporting to a directory with both exporttree=yes and
+>   importtree=yes, it refused to let an interrupted export proceed after
+>   upgrade, with "unsafe to overwrite file". An import resolved the
+>   problem. Guess the problem is that the content idenfifier did not
+>   get recorded in the git-annex branch and the db value was lost on upgrade.
 > 
 > * Keys (IKey, SFilePath, SInodeCache)
 >   Use scanUnlockedFiles to repopulate the Associated table.

doc/upgrades.mdwn

@@ -56,10 +56,6 @@ v7 repositories are automatically upgraded to v8.
 Some sqlite databases that git-annex uses were changed in v8 and have to be
 re-populated.
 
-Any exports that were started in v7 and then interruped won't resume where
-they left off after the v8 upgrade. Some unncessary file uploads can
-happen in this situation.
-
 Any incremental fscks that were started in v7 won't resume where they left
 off in v8, but will instead begin again from the first file.