i am making a mmorts and am interested in how the panda patching system works but there is practically no documentation on it. It ifs some thing that works and i can use it it would be great! I would write it up in the manual about how about how it works.
In a nutshell:
p = Patchfile() p.build(Filename('version_1.mf'), Filename('version_2.mf'), Filename('v1_to_v2.patch'))
This will generate the file v1_to_v2.patch based on the differences between version_1.mf and version_2.mf.
Later, when you have version_1.mf and v1_to_v2.patch, you can produce version_2.mf with:
p = Patchfile() if not p.apply(Filename('v1_to_v2.patch'), Filename('version_1.mf')): print "Patching failed"
There are other, more esoteric options, for limiting memory usage during patching, or for patching in increments instead of all at once (so you can update a progress bar or something). But that’s the meat of it.
wow David, thats very useful and simple!
i wonder if there is some sort of a directory crawler or i just write that myself (not too hard)?
Are the files to be patched (the *.mf in your example) regular binary files or need to be in some sort of panda-zip structure? Are the patch files them selfs zipped or do i need to zip them?
Also while we are on the subject whats the best way to restart the program after patch is complete?
Directory crawler? I don’t know if you need one; I would recommend writing your application with a table of files it uses, rather than looking for whatever’s on disk. Otherwise you risk attempting to patch whatever junk might exist on the client machine. Though I suppose it might make sense to crawl through your own directories when you’re building patches, and you can use Python’s os module or Panda’s Filename class for that.
In my example the files are named .mf. This example suggests that you might be patching files in Panda’s Multifile format (.mf). The multifiles can store multiple resources like bams, textures, mp3’s, and so on, and Panda can load them from directly from the multifiles without having to unpack them first.
The Patchfile object works on any arbitrary binary files; you don’t need to limit yourself to just patching multifiles. However, the Patchfile does recognize a multifile and treats it as a special case; it can build patches for large multifiles without running out of memory, while building a patch for a large generic binary file might require so much memory it brings your system to its knees. (Applying patches doesn’t require much memory, however.)
Patchfiles are not automatically compressed. You can do that yourself. Also, I recommend patching uncompressed source files for best results. (You can build patches against compressed source files, but the resulting patchfiles will tend to be much larger than the same patchfiles built against the original uncompressed files.)
As to restarting your application, well, that depends on your application. But I recommend minimizing the need for restarts by patching only the parts of your application that you haven’t loaded yet, to the extent that you can arrange this. For instance, you can have a tiny core of your application that almost never needs to change, which is responsible for obtaining the patches for the main body of your application, applying the patches, and then starting the main body.