Community
Participate
Working Groups
I request that an intermediate abstraction between Repository and DfsRepository be created that simply makes the file IO pluggable, but doesn't add the other restrictions DfsRepository imposes. Quoting Shawn Pearce (from http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg01189.html): I think the major difference between this "DFS" storage code, and the native local one, is we abstract the entire file IO so it can be pluggable (e.g. REST-ish HTTP like S3), we don't support loose objects, and we have to tolerate lower-level limitations like a writable file cannot seek back and overwrite prior regions (this has implications for completing a thin pack received over the network). From my experience extending DfsRepository to my use case, I'll add that it also assumes a repository is bare. For my use case, I need to avoid loose files a replace the file IO, but I do have a working directory and my ref and object databases will still be backed by a local filesystem. However, I used (abused?) DfsRepository anyway because that allowed me to get the advantages of object packing without needing to learn how to correctly use PackParser and PackWriter. More than simply being nice to have, adding a file I/O abstraction will allow jgit's excellent object packing and directory indexing to be used for use cases other than source code management. https://github.com/apenwarr/bup is an example of such a use case.
