Boris Koenig said:But then, also not to have to rely on cvs-specific files which would not necessarily be available in a release version and hence won't be suitable to determine the base package version in general.
That's true. You are probably just too late this time around.
Well, to be honest - that was NOT my idea, I just also thought the idea would be pretty good and didn't mind to create the requested patch. The actual idea and patch-script come from Stewart Andreason on the users mailing list:
His current patch script requires a (to be patched) version of the FlightGear base root directory and an archive with an updated version of that directory tree. It then creates a diff of these two trees and that diff tree is then packaged into an archive - so you would normally only have to untar that said "diffed" archive into your old base package in order to obtain a recent base package.
While the script itself looks pretty good and does seem to work, there are some minor things that could be improved, like being able to either use another directory/archive as source/target. Also, it doesn't yet seem to take those files/folders properly into account which need to be removed/replaced from the old release.
> It is an interesting idea having release to release patch files, > but I am not sure what would be involved.
Yes it could indeed turn out to be quite useful in general, one of the easier ideas would be to have checksums for each file/folder and simply store these checksums within a specific file in FlightGear's data root directory.
This checksum file would then contain each folder/file (absolute position) with the appropriate checksum.
A simple syntax might already be sufficient:
file:/data/aircraft/whatever.xml chk:0f32e4f8a97c (optionally also file size)
One would then use a shell script to take care of all changes within the CVS, either that script is executed automatically after each commit - or it is run by cron job.
It would then simply create a detailed checksum list for each revision.
In order to update a release the patch script would merely have to compare the local (old) copy of the checksums file with the latest version of the base package, that way it could track down all necessary changes.
So, in order to create a patch file one would mainly need to:
- download specific files from cvs
- remove/replace specific filesBasically, one would execute a stripped down "cvs update" - but of course this could also be web-based or use the viewcgi perl script to retrieve the files from CVS.
So, all (new/changed) downloaded files would then be put into a corresponding patch archive.
Additionally that script should take two other things into consideration, 1) all files/directories that should NOT be put into the release patch (i.e. CVS stuff)
2) also those files/folders that don't reside in the data repository, but also need to be updated/packaged into new base releases (the documentation/manuals would be such a case, cause they are stored separately).
---------- Boris
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
