[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
