8. Controlling the Configuration Files

Status: built 2026-09-28 as the private repository capital-publisher-config (config/ with the 71 managed files, tools/PublisherConfig.ps1 with status, diff, apply and capture). The CIS check below is status -Target <CIS share> rather than a separate command. What the build proved and what it did not is in that repository's README and on 7. Where Publisher Reads Its Configuration. The design below follows from the survey on 6. The Publisher Configuration Files.

The goal

One place that answers four questions at any moment:

1. What configuration is Publisher using right now, and where does it come from?
2. How does it differ from Siemens' stock files?
3. Who changed what, and when?
4. Does the CIS machine have the same configuration as the clients?

Recommended approach: one versioned central folder

1. Keep the configuration in a git repository, holding only the ~1 MB of editable files: the top-level *.xml / *.xsl, pdf\, print\, changeExplorer\, SmartFlow\, S1000D\, i18n\, Custom Runtime\. Leave out runtime\, VINServer\ and jt2bod\ (installed software, not configuration) and server-config\ and VIN\vinServerConfig.xml (credentials). The first commit is the stock files from configurations.zip, so every later commit is a readable diff against Siemens' defaults.

2. Point Publisher at it. Check the repository out to a shared folder and set Paths > Publisher Config to that folder, so every client and the CIS machine read the same files; background tasks can name it directly in publisher_config_files. A config-only folder is enough: tested on page 7. Or keep each install's own folder and apply to each.

3. A small script with four commands, run from any machine:

Command	Does
status	Reports which folder is in use (from publisher-config-file-path.txt) and lists every file that differs from the repository and from the stock zip, as three columns: stock, repository, live
diff <file>	Shows the change to one file against stock or against the repository
apply	Copies the repository over the configured folder, backing up what it replaces first, and never deletes files it does not manage
check-cis	Runs status against the CIS machine's folder, so the background-run gap from page 5 is visible before a package goes out wrong

4. Guard the change, not the mechanism. After apply, generate a small reference package and check one change you made actually appears in it (an attribute name, a navigation order). A copied file proves nothing about what Publisher read.

Lighter options if that is too much

• Drift report only: just the status command, comparing live files to configurations.zip. It costs almost nothing and answers "what have we changed from stock?" on its own.
• Profiles: keep several named configuration sets (for example OEM service, internal engineering, S1000D customer) and have the script switch the central folder between them. This is useful if different customers need different packages from the same designs.

Not recommended

• Editing files in place in the install folder: no history, and updates can overwrite them.
• Committing the whole publisher folder: 485 MB of runtime, plus reversible passwords.