Split out data and code?

[Fairlight]

I have a particular need for a business, and need to know if filePro
supports a particular topography natively.

This is for filePro 5.0.14 on Linux, and it -won't- be upgraded,
guaranteed, even if the feature is available only in later versions.
Please constrain answers to relevancy for that version.

By default, filePro co-mingles its code and data in the same directory for
each file.  Maps, key and data segments, indexes, screens, output
definitions, selection sets, processing tables and tokenised versions of
them, etc., all live in the same place.

What I need to achieve is the ability to have:

* One directory (preferably the same current location of $PFDIR) retaining
the data (key/data, indexes, lockfiles).

* A -separate- directory taking up the role of housing the code (prc/tok,
browses, maps, selection sets, outputs, screens, etc.).

The goal is to split these off so that gigabytes and gigabytes of
customer data can remain where they are, but the application itself can
be containerised with docker.  This is to facilitate distribution and
implementation of an application on a version-specific level (v1, v2 ..
v47, etc.), and secondarily for resource protection.  Drop in a whole new
version of an application spanning hundreds of filePro files, and run your
Apache-driven product.  If there's a problem, switch containers back to the
last version.  Instant rollback.  There are huge benefits in multiple
areas, from ease of distribution and deployment, to rollback ability.

So far, my attempts to make this happen have hit a brick wall in that the
container version of the directory is subject to occlusion by the bind
mount with the data files.  You only see the data files.  If you exclude
the bind mount, you can see the code, but you have no data.  This is a
problem.

I've considered symlinks from the data directory into the location where we
might move code to in the container structure, but that whole thing doesn't
play nicely with git, which really doesn't like symlinks as much as you'd
hope.  It is not an exaggeration to say that I would need to generate
hundreds of thousands of symlinks to start, across all filePro files, and
then implement and maintain the practise of adding new ones any time
something new is instantiated.  That seems unwieldly, and I don't want to
impose that upon the developers if I don't have to.

Copying the data into the container is going to be too slow at startup,
given that it can be a few hundred gigs of data...per customer.  That's not
going to happen.  So it's either split this apart and get both sets of
files under the same directory -somehow-, or find a way to use two separate
directories.

I'm open to viable suggestions.

Thanks!

mark->
-- 
Audio panton, cogito singularis.