Question
Why the ISX format was chosen to be kept in GIT and not a non-binary format (DSX, XML, pjb/bin)?
As there is a custom script running against an asset maybe the script could unzip the ISX and get XML/DSX content which could be put to Git?
Why ISX?
ISX's are compressed, and Git only stores deltas so the disk footprint is minimised
Git will attempt a merge on nonbinary files, which would likely result in the corruption of the asset
ISX is the only format which has support for all Information Server asset types (not just those in DataStage) so is therefore more useful,
and futureproof.
4. There are multiple ISX format variations:
a. Vanilla Useable as a flexible, singlejobversion by all tools b. Information Server Managerspecific ISX format.
c. ISTool releases (multiple job versions)
We use the 'vanilla' ISX format (1) which contains a single version of the job which can be exported/imported without tooling restrictions.
Although DSX and the ISXwrapped XML are ASCII readable text, they are not easily 'human readable', and there is not, in our view, any value in inspecting a job's source code outside of the DataStage designer. DataStage jobs cannot be loaded into an external diff tool to identify the changes between them, and DataStage job exports contain stages in a nondeterministic order, meaning that two successive exports of an unaltered job may mistakenly identify significant change when compared using a traditional diff tool. The only way to read and understand a job or compare differences between two jobs is to let DataStage load them into memory and present a logical representation which is human readable. This process remains the same regardless of whether the export is encoded using binary or ASCII.