| [jgit-dev] Problems with bitmaps and cloning and DFS back end |
| I've been having some problems with the new bitmap support in conjunction with a DFS back end. When the DfsGarbageCollector runs, it generates a .bitmap file. If I clone from the same process the clone works, but when I stop the process and re-start it, cloning fails with a 'pack hash not valid' error message on the client. If I delete the .bitmap file, either by ignoring it in the 'listPacks' command or by simply deleting the backing file, the clone works as expected. It looks like the DfsBlockCache is being populated when the garbage collection is run, and that subsequent operations are using the cache content instead of re-reading the pack files. From what I can tell, the repository isn't being reused (the number of repositories is equal to the number of concurrent requests) so it looks like there's some kind of caching that is done at the top layer. Either that or Windows (on which I'm testing) is doing some odd things with files that have been deleted. Having debugged through the code it looks like if the .bitmap file is found when doing a full clone then a different path is walked, resulting in a 0 byte pack output being written to the client. If the bitmap file isn't found then the pack/index files are being walked appropriately. What I'd like to do is sanity check the files by re-creating a local JGit repository and writing the pack files out locally, but I seem to remember that the pack file format for JGit differs from Git in that the leading byte counter may not be set correctly. Is there an easy way to transform a pack file into a valid Git one, by reading from the index file how many objects it contains and writing that to a JGit pack file? How do I calculate what the name of the pack file should be on the file system so that I can point JGit and Git to it? Hopefully I'll then be able to discover if the .bitmap file is correct or not, and so figure out if the problem is in the writing stage or in the reading stage. Alex PS I've tested this with the JGit 3.0.0.201306101825-r release, and it appears to be a problem specifically with the Dfs backend, as Mathias was able to demonstrate the same principles with just the JGit daemon and JGit gc without any problems. |