I discussed this with Jason earlier this week. The simplest solution is to use the InterSystems Package Manager (IPM) with a local development environment model - if you have multiple local repos all loaded via zpm with the "-dev" flag, git-source-control will know the right place for everything to go and you can edit multiple projects under a single isfs folder in VSCode (or via Studio). Note, you may need to be more explicit than previously needed with the Directory attribute on resources in module.xml to get things perfectly right.

If there are needs that this won't quite meet, it may be possible to improve git-source-control to provide further configuration options.

I'm not a Mac user myself, but my first thought would just be to move the "workspace" folder somewhere else (e.g., under the database install root) that would inherently have the correct permissions, and chown appropriately.

You can double check which user IRIS is running as with something like:

ps aux | grep irisdb | grep SuperServer | tail -n 1 | cut -d' ' -f1

@Gautam Rishi some things that would be helpful / might be worth looking into:

  • Does the user IRIS runs as (most likely irisusr) have access to /Users/abc/workspace? If not I'd imagine all sorts of things could go wrong. (And git-source-control could be more helpful by making the root cause more obvious.)
  • Where specifically is the error coming from?
    • The error #5001 / message there doesn't seem to be in the git-source-control codebase, at least that I can find.
    • If you set ^%oddENV("callererrorinfo")=2 it'll typically put the full stack trace in the error message. Just be sure to kill ^%oddENV("callererrorinfo") later so you don't keep getting it because it's noisy/annoying if you don't need it.
  • What IRIS version are you running? (write $zv)

In general, feel free to file a GitHub issue at https://github.com/intersystems/git-source-control/issues

If you're looking to implement your own registry you'll also need client code to handle retrieving packages from, and publishing to, your own registry. (FWIW, built-in Artifactory support is under consideration.)

This would involve extending https://github.com/intersystems/ipm/blob/master/src/%25ZPM/PackageManage... and writing classes to implement the following interfaces:
https://github.com/intersystems/ipm/blob/master/src/%25ZPM/PackageManage...
https://github.com/intersystems/ipm/blob/master/src/%25ZPM/PackageManage...

(Ignore the "Application" related methods - only "Module" is needed.)

As an example, see:
https://github.com/intersystems/ipm/blob/master/src/%25ZPM/PackageManage...
https://github.com/intersystems/ipm/blob/master/src/%25ZPM/PackageManage...
https://github.com/intersystems/ipm/blob/master/src/%25ZPM/PackageManage...

I'll add to this, we use the same "embedded" source control behavior across Studio and VSCode for my team within InterSystems, and haven't had issues.

@Richard Filoramo , one question re: TrackWare - do you know offhand which "Actions" and "Other Studio actions" it uses in the UserAction method from %Studio.Extension.Base (see class reference)? There are some limitations/differences between VSCode and Studio but they're on things we see as either less common or undesirable to support from VSCode. One such case we've previously deemed "undesirable" is Action = 3, "Run an EXE on the client. The Target is the name of an executable file on the client machine. It is the responsibility of the customer to ensure this EXE is installed in a suitable location." Your statement that your source control system is written in ObjectScript and Delphi makes me think this might matter to you.

More generally, @Brett Saviano , there may be other aspects of complete support for the interface defined in %Studio.Extension.Base to consider.

@Evgeny Shvarov I have a detailed writeup here (although Dmitry already hit the important point re: IPM): https://community.intersystems.com/post/unit-tests-and-test-coverage-obj...

A few other notes:

Unit test class instances have a property (..Manager) that refers to the %UnitTest.Manager instance, and may be helpful for referencing the folder from which unit tests were loaded (e.g., to load additional supporting data or do file comparisons without assuming an absolute path) or "user parameters" / "user fields" that were passed in the call to run tests (e.g., to support running a subset of tests defined in unit test code). Sure, you could do the same thing with PPGs or % variables, but using OO features is much better.

I'll also often write unit tests that do setup in OnBeforeAllTests and cleanup in %OnClose, so that even if something goes very horribly wrong it'll have the best chance of actually running. Properties of the unit test are useful to store state relevant to this setup - the initial $TLevel (although that should always be 0), device settings, global configuration flags, etc.