Look at this page, it may help you in understanding how to configure it.

If you need to store classes and mac routines separately, you can use

{
  "objectscript.export": {
    "addCategory": true
  }
}

In the case of different behavior for different types, and place only mac routines to the specific folder, use this.

{ 
  "obejctscript.export": {
    "addCategory": false,
    "folder": {
      "mac": "mac"
    }
  }
}

Yeah, It's a bit tricky. All the code in Caché really stored directly in the database. But with VSCode, code can be stored locally as files, for easy access and the ability to use source control such as git. After any save of the file related to Caché, e.g. Classes or routines, it will be sent to the server and compiled there.

Having a separate development server, and a production server are for sure is best practice, for sure. With no permission to edit code directly on production. And with having DevOps, will be possible to build a production version and easily deploy it, by some actions or events.

Hi Marcel, yes, something was implemented, which may help you with it. There is a new item map in objectscript.export. For instance this

   "objectscript.export": {
    "folder": "",
    "addCategory": false,
    "map": {
      "%(.*)\\.([^.]*)": "src/$2/_$1.$2",
      "(Test\\.PM\\.Integration\\..*)": "tests/integration_tests/$1",
      "(Test\\.PM\\.Unit\\..*)": "tests/unit_tests/$1",
    },
  }

I have on the same level src and tests folders, so, I set folder to an empty string, to operate on a root level. My Unit Test classes, just placed in the desired folder without adding the folder by type (e.g. cls, inc). But, any other sources have to be stored by type in a separate folder, and my classes are a percent classes, and I have to replace % to _.

On the left side, I have the regular expression to match any main classes %(.*)\\.([^.]*) it should match the filename completely, and on the right side replacement. Same you can see for two different types of UnitTests.

 Very interesting question, could you please raise the issue in GitHub repository for the project.

We would need a bit more details about it, what you have in your SourceControl Class, and what do you expect.

But, be aware, that this feature was not completely implemented at the moment. It may not implement all the features available in Studio, due to some differences in architecture.

Permission denied issues come from a non-root environment configured for the latest few versions of IRIS. And, so, you don't have access to folders, out of access of user irisowner, which runs IRIS inside. This user has access to his home folder - /home/irisowner, and /usr/irissys, where IRIS installed. But you should know that anything created on a filesystem inside the container will disappear after its recreation. And it's how it supposed to work. If you need access from outside the container to created folder, or keep it save even when the container re-created, you have to bind some folder on your local filesystem inside the container, with --volume|-v option (do not forget to give permission to do it in docker settings).

I suppose, there is no way how to run Community Edition directly if you have so many cores, at least, yet. And at the moment, you can use Docker or virtualization, and Docker I would say preferable way.