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.

@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

Hi @Michael Davidovich - it's been a while! Here's a quick sample for how I'd do this:

Class Mike.Demo.REST Extends %CSP.REST
{

/// This method gets called prior to dispatch of the request. Put any common code here
/// that you want to be executed for EVERY request. If pContinue is set to 0, the
/// request will NOT be dispatched according to the UrlMap. In this case it's the
/// responsibility of the user to return a response.
ClassMethod OnPreDispatch(pUrl As %String, pMethod As %String, ByRef pContinue As %Boolean) As %Status
{
    #dim %request As %CSP.Request
    Set pContinue = 0
    Set version = %request.GetCgiEnv("HTTP_X_API_VERSION","unspecified; use X-API-VERSION header")
    Set class = $Case(+version,
        1:"Mike.Demo.v1",
        2:"Mike.Demo.v2",
        :"")
    If (class = "") {
        Set error = $$$ERROR($$$GeneralError,$$$FormatText("Invalid API version: %1",version))
        // Shoud be HTTP 400, but you probably want to report this differently/better.
        Do ..ReportHttpStatusCode(..#HTTP400BADREQUEST,error)
        Quit $$$OK
    }
    
    Quit $classmethod(class,"DispatchRequest",pUrl,pMethod,1)
}

}

Class Mike.Demo.v1 Extends %CSP.REST
{

Parameter VERSION = 1;

XData UrlMap [ XMLNamespace = "http://www.intersystems.com/urlmap" ]
{
<Routes>
<Route Url="/version" Method="GET" Call="GetVersion" />
</Routes>
}

ClassMethod GetVersion() As %Status
{
    Write {"version":(..#VERSION)}.%ToJSON()
    Quit $$$OK
}

}

Class Mike.Demo.v2 Extends Mike.Demo.v1
{

Parameter VERSION = 2;

XData UrlMap [ XMLNamespace = "http://www.intersystems.com/urlmap" ]
{
<Routes>
<Route Url="/version" Method="GET" Call="GetVersion" />
</Routes>
}

}

The standard approach for this in ObjectScript is the $$$FormatText macro - for example:

Class Demo.Text
{

ClassMethod Sample()
{
    Write $$$FormatText("Watch out %1, it's a %2!","Superman","large pizza made of Kryptonite")
}

}

Results in:

d ##class(Demo.Text).Sample()
Watch out Superman, it's a large pizza made of Kryptonite!

Set source = "NAMESPACE1"
Set target = "NAMESPACE2"
Kill ^|target|oddDEF(classname)
Merge ^|target|oddDEF(classname) = ^|source|oddDEF(classname)
New $Namespace
Set $Namespace = target
$$$ThrowOnError($System.OBJ.Compile(classname,"ck"))

EDIT: Don't do this. Everybody should ignore me and do what @Chad Severtson said instead.

You can use parameters on the return type. For example:

Class DC.Demo.SqlProcCollation
{

ClassMethod Test() As %String [ SqlProc ]
{
    return "Abe Lincoln"
}

ClassMethod Test2() As %String(COLLATION="SQLUPPER") [ SqlProc ]
{
    return "Abe Lincoln"
}

}

Given that:

select DC_Demo.SqlProcCollation_Test(),DC_Demo.SqlProcCollation_Test2()
where DC_Demo.SqlProcCollation_Test() = 'ABE LINCOLN'

Returns no results

select DC_Demo.SqlProcCollation_Test(),DC_Demo.SqlProcCollation_Test2()
where DC_Demo.SqlProcCollation_Test2() = 'ABE LINCOLN'

Returns 1 row

The general pattern that I would recommend is:

• Use isc.rest (https://github.com/intersystems/isc-rest) to create APIs to existing (or new) data and business logic
• Use isc.ipm.js (https://github.com/intersystems/isc-ipm-js) to generate client code - once it's set up, getting an updated OpenAPI spec file and - on top of that - updated Angular services and TypeScript model classes (for example) is as easy as running zpm "package-name generate"

https://github.com/intersystems/isc-perf-ui is a simple example of how this all fits together - see especially https://github.com/intersystems/isc-perf-ui/blob/main/module.xml.

I just used this toolset to build a small but meaningful IRIS-based application in about a week. I didn't hand-code a single REST endpoint in ObjectScript, and I got my OpenAPI spec and all my Angular services and TypeScript interfaces for free*.

Of course, if you already have a significant hand-coded REST API, this doesn't help much. For one application my team manages we've added a Forward in our main REST dispatch class to one using isc.rest and gradually migrated endpoints over to use the standardized approach.

* ok, not totally free - there's the small price of writing better ObjectScript and e.g. having methods that return a registered JSON-enabled type rather than e.g. %DynamicArray and %DynamicObject.