Hi Shawn,
I want to fix bug 308506.
As discussed I want to fix the issue by retrying the deletion if the deletion of the file ref fails in LockFile.commit.
The problem is now the following: LockFile does not know FS, so I can’t call retryFailedLockFileCommit() to find out the running platform.
The constructor of LockFile could be extended with a boolen parameter retryDeletion.
My question is: Is the retry logic only required for DirCache.commit or should is apply in further usages of LockFile.commit?
commit() : boolean - org.eclipse.jgit.lib.LockFile
commit() : boolean - org.eclipse.jgit.dircache.DirCache
detachHead() : void - org.eclipse.jgit.pgm.debug.RebuildCommitGraph
doLink(String) : Result - org.eclipse.jgit.lib.RefDirectoryUpdate
doUpdate(Result) : Result - org.eclipse.jgit.lib.RefDirectoryUpdate
lock(String) : boolean - org.eclipse.jgit.lib.PackLock
run() : void - org.eclipse.jgit.pgm.eclipse.Iplog
save() : void - org.eclipse.jgit.lib.FileBasedConfig
syncCQs(File, URL, String, String) : void - org.eclipse.jgit.iplog.IpLogMeta
updateFETCH_HEAD(FetchResult) : void - org.eclipse.jgit.transport.FetchProcess
writeFile(String, byte[]) : void - org.eclipse.jgit.junit.TestRepository
writeFile(String, byte[]) : void - org.eclipse.jgit.lib.RefDirectory.commitPackedRefs(...).new RefWriter() {...}
writeFile(String, byte[]) : void - org.eclipse.jgit.pgm.debug.RebuildCommitGraph.recreateRefs().new RefWriter() {...}
--Jens
