git-source-control questions

Question

Question

#Embedded Git #Git #Source Control #InterSystems IRIS

Hi

I'm trying to assess whether git-source-control will work for our development environment. I've watched some videos and read the documentation and read some posts and I'm still unsure whether it works with multiple developers using a shared remote development environment (i.e. namespace). This [Video] Let InterSystems IRIS Do the Work: Git Source Control & Linting says that you can have multiple developers and says it's "Package Manager-aware (supporting multiple repos in one namespace)" whereas this post on the git-source-control github Remote development and multiple users · Issue #613 · intersystems/git-source-control
appears to say you can't. Which is it?

Also does it support .js and .css files? I've been trying to replicate the git-source-control demo in this video: [Video] Selecting The Right Source Control Strategy for Your Team on my local instance with my own project which contains .csp, .js, .css and .png files and they weren't exporting originally, so I added the ",*.js,*.css,*.png" code to the SoureControl.Git.Utils class

ClassMethod BaselineExport(pCommitMessage = "", pPushToRemote = "") As %Status
{
    set sc = $$$OK
    try {
        write !, "Exporting items..."
        set rs = ##class(%Library.RoutineMgr).StudioOpenDialogFunc(
            "*.mac,*.int,*.inc,*.cls,*.csp,*.js,*.css,*.png" // Spec

and they export now, but still don't import.

Product version: IRIS 2023.1

$ZV: IRIS for Windows (x86-64) 2023.1.5 (Build 697U)

Discussion (2)3

Log in or sign up to continue

score 1 · Answer 1 · 2025-03-11T08:31:42-04:00

Hi Fiona,

My team maintains Embedded Git (our preferred name for git-source-control these days). I'm happy to help set up a call with my team to discuss your needs further.

To hopefully untangle things a little bit:

Embedded Git supports multiple developers using a shared remote development environment - that's one of its main purposes. The role of an embedded source control extension in IRIS is to keep the filesystem in sync with the IRIS database, reflecting IRIS-level edits through any IDE or the management portal on the filesystem and pulling filesystem-level changes (e.g., those caused by git commands) into IRIS. Given that there is only one location on the filesystem that is tracked, there is a general, reasonable limitation that a namespace can only be tied to one branch in a single repo at a time.

IPM use in this setting is probably rare; and if you are using it, you're most likely not using a shared remote development environment. In the IPM use case, the package definition provides additional information about which repo/folder a given unit of code (say, a class) belongs to, which means we can import/export from different repos which may shift branches independently. This is a powerful tool for building a more modular codebase, but the additional complexity means that it's better suited for local development where everything is under the individual developer's control.

To support users working in different feature branches, a common approach is to give each user their own namespace on the shared, remote development environment, and we provide tooling ("basic mode") around orchestrating promotion from feature branches to a "main" branch associated namespace via merge requests in your Git remote.

Re: files in the baseline, this might just be a bug. What is your mapping setup (in Settings)? Did you map the web application your interested in?

Best,

Tim

score 0 · Answer 2 · 2025-03-11T09:55:12-04:00

Hi Tim

Thanks, we don't currently use IPM.

So essentially if we want to use this we would need to change our current namespace setup and create a development namespace for each developer, plus one for the master repository. Then for testing if we wanted multiple testers wanting to test multiple branches at the same time, presumably they'd also need a separate namespaces?

The settings I have in my outgoing namespace are:

and the settings I have in my incoming namespace (where I was trying to pull the project to) are:

I did originally have the settings for the receiving namespace very similar to the outgoing, but when I saw that the exported files had all been put underneath the csp directory I changed them to the above, but they still didn't import.

The error I am getting is "Unable to import file *** as this is not a supported type"

thanks