New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recursive directory diff support #21
Comments
Original comment by |
Original comment by |
Original comment by Attachments: |
Original comment by |
Original comment by
|
Original comment by
|
Original comment by |
Original comment by Attachments: |
Original comment by Attachments: |
Original comment by Attachments: |
Original comment by Attachments:
|
Original comment by |
Original comment by |
Original comment by |
Original comment by |
Original comment by |
Original comment by |
Original comment by |
Original comment by |
If there's a way to have some of the code from https://github.com/endlessm/xdelta3-dir-patcher integrated into this tool, you might have an easy win. |
The way I do it with tools which are currently available is as follows:
If the directory structure in the tar changes much, there might be more sophisticated methods. |
If this feature is worked on, i'd like the option of sorting the underlying tar (or whatever container format ends up existing to de-multiplex multiple files into just one patch) by filesize not name for the case where the source and destination have differently named files have several (but often not all) bytes in common. This happens often in multiple formats of the same thing, and i expect byte size is better indicator of relative order than name in at least some of these cases (option because often the name is better if it's not truly random even in sources and destinations with different number of files, so name should be default). I actually don't know if this is relevant for xdelta compression, but i'd expect so considering all the other approaches tendency to hook into equal filenames as the supreme indicator of which bytes should be patched. |
Original issue reported on code.google.com by
josh.mac...@gmail.com
on 5 Feb 2007 at 11:47The text was updated successfully, but these errors were encountered: