Installation and configuration

[EnricoParisi]

In its default ZPM package git-source-control is installed locally in a single namespace, if multiple namespace need source control I assume that you need to install it in each and every namespace.
When there a many namespace (or even few IMO) this is.....not ideal....
I know systems with more than 15 namespaces (up to 30+ in some case), having a separate installation in each namespace is a nightmare!
I know there are options to avoid this using package mapping but this should be at least documented if not directly implemented in ZPM install.
Maybe implementing in ZPM can be a challenge due to the many options available, but at least the documentation can suggest something like creating a dedicated database/namespace BEFORE installing git-source-control, then add package mapping for the namespaces where git-source-control is used/needed.
I've not yet tested mapping SourceControl.Git package, has this been tested?
There may be other implication on using mapping, for example regarding settings where I think there should be common/system settings (git config, user mapping etc.) and local namespace settings (items/packages etc.).

In its current form, out of the box, git-source-control it's challenging to use it in real world complex environments (multiple namespaces) that are common in IRIS installations and these are EXACTLY where share server development/maintenance is the only options (think of interoperability systems with tens or hundreds in/out interfaces) and therefore server side source control is the only way to handle source control.

[isc-tleavitt]

@EnricoParisi I agree. This is on the longer-term roadmap.

In the case of git-source-control, you're right that it's not quite as simple as mappings / using %ALL, even if there was support for automatic %ALL/equivalent mappings in IPM itself. There are user experience considerations and some additional technical concerns about how settings are shared (or not) across namespaces, as you already observed. There's some coverage of the topic in the following issues:
#214
#215

The other main topic not covered in these other issues is what to do when you have a "git pull" that spans namespaces. This gets especially tricky (I'd hesitate to say impossible) if there are classes in your codebase which are themselves mapped, which might contain changes interdependent with the other changes being pulled/loaded.

I'd imagine a standard repository layout where the namespace name is used in the path prior to the mappings. Any other thoughts you have on repo layout are most welcome. :)

[EnricoParisi]

Hi Tim,

what I envision is a separate db/namespace where git-source-control should be installed and EVERYTHING (code & data) should be stored in this db/namespace.

I really don't like "messing" the working db/namespace with source control code and global (i.e. ^SYS).
In some case the environment database(s) are copied to a separated system for testing, training or whatever reason and this brings along the source control configuration. Not ideal.
Source control should be defined and configured at system level, not in the application db/namespace, that's why I think a separate db/namespace should be used.

Then, from within the source control namespace the settings can be configured for common/system settings (git config, repository root dir, user mapping etc.) and enabling it in selected namespace (possibly adding required mappings).
I totally agree with your idea of adding namespace name in the root repository path prior to the mappings.

Then, from within each namespace items can be added to source control, BUT not in local ^SYS (btw, why use ^SYS global name?!) instead use a global (possibly mapped, say ^GitSC) in the git-source-control db.
Of course the global should use the namespace in the (first? second?) subscript for NS specific settings/config/items.

This way you leave a clean application database, everything is centralized and system specific and, maybe, "a git pull that spans namespaces" can be implemented.

Of course this is not a "fix", it's almost a re-implementation due to the many changes required and may make difficult to upgrade/migration to this new architecture.
How about a new package git-source-control2! 😂

[EnricoParisi]

"I totally agree with your idea of adding namespace name in the root repository path prior to the mappings."
Actually....I changed my mind! :)

I think that the DATABASE name should be added in the root repository path prior to the mappings.
The reason is simple, a class/routine can be mapped, so using the namespace is not appropriate, the DB should be used.
In this way a mapped class/item even if used in different namespaces and included in git, it still ends up in the same place in the filesystem.

[isc-tleavitt]

@EnricoParisi those are good points all around!

FWIW: in terms of mappings / namespace structure, my team's standard operating procedure is to have three databases per namespace: transactional data (namespace-default for globals), code (namespace-default for routines), and "configuration" - where "configuration" includes source control configuration AND any other data we wouldn't want to stomp on in a development/testing/training environment when we bring in an updated set of transactional data there from some other place. The relevant globals are then mapped to the configuration DB. Given that, our process for "refreshing" the data in a development/testing environment is just to drop in a new DB from a (typically) a production backup.

This "config" includes a global that indicates whether the environment is dev/test/production (see #124), various application-specific debugging flags, settings around sending emails, etc; although a lot of things at the application level are keyed off "which environment is this?" For web service / REST clients we tend to roll our own rather than using IRIS interoperability features for applications that are otherwise light on interoperability needs; this is sort of the equivalent of interoperability "system default settings" but outside of the interop context.