Re: [platform-compare-dev] Patching for eclipse updates

[Dorian Birsan <birsan@xxxxxxxxxx>]

Thanks Andre.
Binary patches are very important, as
zips and jars are really the two main type of files that make bulky updates.
If you are you planning any work around
defining/implementing zip/jar patching please post it on this list so we
can be notified.
In the meanwhile, I'll try following
up on the leads you suggested.

-Dorian

Andre Weinand <weinand@xxxxxxx>
Sent by: platform-compare-dev-admin@xxxxxxxxxxx

11/24/2003 01:42 PM

Please respond to
platform-compare-dev

To	platform-compare-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-compare-dev] Patching for eclipse updates

Hi Dorian,
please see my comments and answers below.
--andre


>We're looking at ways to reduce the number of bytes being downloaded
>by the Update Manager for feature updates/patches, so we'd like to
>see if the current eclipse compare/merge/patch technology can be 
>used for this.

Makes sense.

However, the current Create Patch/Apply Patch infrastructure uses the 
unified diff format 
(http://www.gnu.org/manual/diffutils-2.8.1/html_node/) which works 
well only for text files.

Since CVS does not understand the internal structure of zip and jar 
files, it would have to treat them as binary files
but binary patches are not guaranteed to work in all cases.

In addition, Apply Patch tries to apply a patch even if the target 
file has changed since the patch has been generated.
This would not work with sealed jar files because any kind of 
checksum scheme would break.


>Here is a scenario that we'd like to support:
>We need to update a plugin that has changed in the following ways:
>- file removed

no problem

>- file added

no problem as long if it's non-binary

>- file has one line change

no problem if the files has lines

>- jar file has one contained .class file change
>
>- zip file has one contained file changed.

not supported, see my explanation from above

>- we should run a "create patch" tool that creates a patch
for the above.

today we use CVS for creating a patch file. This means that a patch 
can only be created against a CVS repository.
But it wouldn't be too difficult to create arbitrary patch files by 
using the hierarchical and the textual differencers of the Compare 
plugin alone. In this case even jar and zip files could be dealt with 
correctly.
However, we would need an extended external format that handles the 
additional requirements of binary and jar/zip files.


>- the update manager should be able to read a patch and apply it.

Sure, the class 'Patcher' does some of that already (not for binary, 
jar/zip files).

>To minimize the download size for the above patch, we would like to,
>for example, not download the entire jar or zip, but only the 
>actually contained files that have changed inside them.
>
>
>Also, one of the constraints is that we cannot pre-req any of the 
>eclipse UI plugins.
>Ideally, we could re-use some of the classes that are already there,
>without having to implement IRangeComparator or other related 
>interfaces.

Yes, I understand.

>I noticed that our CVS support does not work well with patching 
>jars/zips, so I wonder if this is because our compare/merge 
>technology does not support it or because of CVS limitations.

It is the latter: CVS does not understand zip or jar files, and the 
unified patch format doesn't support binary files.
So there was no need for Compare/Merge to support binary files.

Alternative approaches:

Have you looked into rsync (http://samba.anu.edu.au/rsync/)?
It is not a static file format describing changes, but it is a 
dynamic protocol to minimize the number of updates and the amount of 
information that is required to bring remote directories into synch.

If you you cannot use a protocol like rsync, and really looking for a 
file format, another approach would be to use the IChange 
infrastructure of refactoring. They have change objects for file 
deletions, additions and text file changes, and it would be simple to 
extend them for binary files and for updating archive files. They 
don't have a streaming format for these change objects yet, but it 
would not be hard to invent one (probably based on XML).


>Thanks,
>-Dorian



_______________________________________________
platform-compare-dev mailing list
platform-compare-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-compare-dev