If I understand right, this is because SwiftFile::getPath() implicitly copies the file to the local filesystem?
I honestly find that pretty worrying; getPath() is not expected to have open-ended side effects like that, and this may indicate that the File & LocalFile APIs aren't actually very suitable for accessing remote files... should it be refactored to include explicit concepts of checking out a temporary local file and removing it when done? It looks like the file path will be implicitly deleted when the SwiftLocalFile object is destroyed, which should keep from leaking on batch operations, but that might still mean a lot of unexpected copies being made and deleted.
I also see a fully duplicated getHistory method which has had a couple bits swapped out. (It kinda looks like all it needs to do is set $this->oldFileFromRowFactory on the SwiftRepo -- which appears to already be done -- and then just inherit the entire LocalFile::getHistory method?)
Yes, it implicitly gets you a read-only copy of the file. I've audited all the (checked-in) code which calls File::getPath() and I see no problem with adding this semantic to it. There are *many* places where one piece of code or another expect the file to have local filesystem semantics. Fortunately, they all gateway through File::getPath(), so I think we can "refactor" by changing the API. We just say that people shouldn't expect File::getPath() to be lightweight on the first call. The copy is cached, so subsequent calls are lightweight.
There's a LOT of duplicated code in SwiftFile which will be deleted on the checkin I'm about to do. Just reviewing the diff for sanity before I commit.