Some critical questions

[ICS]

Hello,

I have some questions that are very important to me. I would appreciate having them answered.

1. Must I close running software that needs to be patched? Or will visual patch do this for me?

2. Consider the following criteria: If I do whole-file patching and I deliver a full-history patch everytime. Does this mean that the upperbound of the size of the patch will always be the largest file in my patch? For example, if I have a 10 meg file in every version, and that 10 meg file change in a subsequent version, then the patch will only be roughly 10 meg, if not other files have changed? Moreover, this patch would patch any older version to the recent one since it is whole-file patching it just replaces the old one with the newest 10 meg file. Hence a full-history patch will be roughly 10 megs still.

3. Binary patching, is it worth it if we are patching binary files?

[Brett]

Hello,

I have some questions that are very important to me. I would appreciate having them answered.

1. Must I close running software that needs to be patched? Or will visual patch do this for me?

Visual Patch can handle that for you in any way that you want to. The project wizrad will generate the code for you if you choose that option.

2. Consider the following criteria: If I do whole-file patching and I deliver a full-history patch everytime. Does this mean that the upperbound of the size of the patch will always be the largest file in my patch? For example, if I have a 10 meg file in every version, and that 10 meg file change in a subsequent version, then the patch will only be roughly 10 meg, if not other files have changed? Moreover, this patch would patch any older version to the recent one since it is whole-file patching it just replaces the old one with the newest 10 meg file. Hence a full-history patch will be roughly 10 megs still.

Visual Patch does not just do whole file patching. It also does binary diff patching. SO if the differences between your two 10 MB files is only 200 KB then only 200KB of data will be includes in the patch. VP always takes the lesser of the sums of sizes of the diffs vs the compressed size of the entire file along in the patch. It will always choose the smallest possible amount of data to bring along.

3. Binary patching, is it worth it if we are patching binary files?

Usually, yes. Binary patching works well on all kinds of files.

[Lorne]

1. Must I close running software that needs to be patched? Or will visual patch do this for me?

Generally yes, you must close running software before it can be patched. However Visual Patch provides actions which allow you to do this programatically.

2. Consider the following criteria: If I do whole-file patching and I deliver a full-history patch everytime. Does this mean that the upperbound of the size of the patch will always be the largest file in my patch? For example, if I have a 10 meg file in every version, and that 10 meg file change in a subsequent version, then the patch will only be roughly 10 meg, if not other files have changed? Moreover, this patch would patch any older version to the recent one since it is whole-file patching it just replaces the old one with the newest 10 meg file. Hence a full-history patch will be roughly 10 megs still.

Yes. If only one file has changed, and it is 10 megs in size, the patch should be no larger than about 10 megs. (There is some overhead for the patch executable, including its interface, etc. which could technically increase the size of the patch. However the file data is compressed, so even when doing whole-file patching the patch should be smaller -- similar to .zip archiving the file.)

3. Binary patching, is it worth it if we are patching binary files?

Definitely. You can usually achieve much better compression with binary patching than you can with whole-file patching. (It's typical for uncompressed data files to achieve 90-99% compression ratios!) The only time whole-file patching is a better choice is when you are creating a patch for many versions and the cumulative size of the binary difference data is greater than the compressed size of the target file. Note that Visual Patch automatically takes care of that for you, and will switch over to whole-file patching as soon as it would result in any space savings vs. binary differencing.

In other words, you never have to worry about binary patches across multiple versions resulting in a larger patch than the whole file, because Visual Patch automatically switches between binary differencing and whole-file patching as soon as it makes sense to.

[ICS]

an example?

Hi brett, thank you for the help but help me clarify the following:

Consider the following scenario:

Version 1.0:
binaryFile.exe (10 megs)
info.xml

Version 2.0:
binaryFile.exe (modified, but still 10 megs)

Version 3.0:
binaryFile.exe (modified, 9 megs)


Can you tell me What visual patch will do if i make a Full-History Patch for version 3.0 when i have selected whole-file patching?

1. What will the sizes of the different patchs be un the same setup? from 1.0 to 2.0, 2.0 to 3.0, 1.0 to 3.0 and also a full-history patch.

2. Is there still binary diff going on ? even though i selected whole-file patching?

[Lorne]

Consider the following scenario:

Version 1.0:
binaryFile.exe (10 megs)
info.xml

Version 2.0:
binaryFile.exe (modified, but still 10 megs)

Version 3.0:
binaryFile.exe (modified, 9 megs)


Can you tell me What visual patch will do if i make a Full-History Patch for version 3.0 when i have selected whole-file patching?

If you've selected whole-file patching, then it will compress the version 3.0 binaryFile.exe file and include that in the patch archive.

However, if you allow binary patching, it will create binary difference files for 1.0-3.0 and 2.0->3.0, compress them, and then compare the combined size of those two compressed diffs to the compressed size of binaryFile.exe. Whatever is smallest will be used.

1. What will the sizes of the different patchs be un the same setup? from 1.0 to 2.0, 2.0 to 3.0, 1.0 to 3.0 and also a full-history patch.

If you're using whole-file patching, then the size will be the compressed size of each target version, for example:

1.0->2.0 will be the compressed size of 2.0
2.0->3.0 will be the compressed size of 3.0
1.0->3.0 will be the compressed size of 3.0

If you're using binary patching (which is highly recommended) the size depends on the internal nature of those files, and the specific differences between them (at the byte level). It can't be predicted in advance. However it will usually be much smaller than the compressed size of the target file!

2. Is there still binary diff going on ? even though i selected whole-file patching?

If by "selected whole-file patching" you mean that you chose the "force install" option for all the files in the target version, then no, there will be no binary differencing going on.

Otherwise, Visual Patch always chooses the patching method that produces the best results. It automatically switches between binary patching and whole-file patching on a file-by-file basis in order to produce the smallest patch possible.

[ICS]

conclusion

So,

basically what you are telling is that do not worry about sizes, it is all taken care of for you. Just go with binary differencing and let the software decide when to switch over to whole-file.

Is this, the ability to swithc between binary and whole-file automatically, automatic through the wizard when i create a new project or must i set this capability somewhere during the project setup process?


Thank you.

[Lorne]

So, basically what you are telling is that do not worry about sizes, it is all taken care of for you. Just go with binary differencing and let the software decide when to switch over to whole-file.

Yep.

Is this, the ability to swithc between binary and whole-file automatically, automatic through the wizard when i create a new project or must i set this capability somewhere during the project setup process?

It's the normal behaviour, and is always in effect every time you build, regardless of whether you use the project wizard.

Thank you.

You're welcome! If you have any other questions, just ask.