No, I don't think you have to switch over to the new paradigm until you're completely ready to (e.g. no-one using Studio anymore). Instead, follow Dmitry's steps, creating an Atelier project containing any of the classes that you want to edit. Don't hook the Atelier project up to an Eclipse source control provider; your namespace and the existing server-side source control class should continue to function the way it always has done.

This is how we anticipate existing users of our Deltanji (formerly VC/m) source control product will deal with the introduction of Atelier.  And perhaps not just existing users, seeing as Deltanji is available as a free Solo edition.

Dmitry's answer should be what you need. I'd add that the paradigm shift between Studio and Atelier can take a little getting used to. With Studio we're accustomed to thinking of the code in a namespace as the "source of truth". We pull the code from there, change it, and push it back in order to store our changes (and to run the amended code). With Atelier we're more likely to be pulling code into our local filesystem using a source control provider, then editing it, saving it to our local filesystem, and eventually pushing it from there back to the source control repository. Using this mode of working, we only push it into a Caché namespace in order to run/debug it.

Indeed. Presumably the "load and delete" defaults were a design decision based on the model of running unit tests elsewhere. That seems relevant for a build server, but not so friendly for the developer who you're trying to persuade to code the tests in the first place. Yes, Studio the source control hook facility can be your friend here provided you're prepared to spend enough time getting intimate with it.

Re your Atelier issue, does the "Configure server" link lead you to somewhere you can test the connection? Make sure that your Atelier connection is pointing to the port that your Cache Portal also goes to, and not to the port that your Cache Studio uses. That was an early gotcha for me in Atelier.

The Cache username that you connect with might not have enough privileges. One way to determine if this is you problem is to grant the user the %All role temporarily.

A few more caveats:

  • It's not that you can't use the READ command, but that the command completes immediately with emptystring, i.e. "". So beware of running certain command-line utilities. For example, if you connect Studio to %SYS and D ^LOCKTAB in the Output pane you're trapped in an endless loop and have to terminate your Studio.
  • If anything you run releases all locks with an argumentless LOCK command, any Studio locks will also be gone. I've sometimes wished COS allowed us to protect the locks of our process in the same way as we can NEW our local variables.
  • Issuing the H or HALT command is a surefire way of ending your Studion session.

If you're planning to develop on a later version than you deploy onto, beware the occasional gotcha. For example http://docs.intersystems.com/ens20151/csp/docbook/DocBook.UI.Page.cls?KEY=EGRN_compatibility#EGRN_compatibility_hl7schemas identifies an issue with trying to import a 2014.1+ schema into a pre-2014.1 environment. I have seen at least one Ensemble site mangle their production by exporting a schema from 2014.1 or later and then importing it into an earlier version.

Has any information about system methods reached the documentation yet? On my 2016.2 FT (build 585) Documatic shows the methods of %Library.Object in a new section headed "SystemMethods" and summarized in a table titled "System Methods". The methods start with keywords systemmethod and systemclassmethod but a DocBook search on either of those terms doesn't get me any extra information.

Also, in Stefan's article the section about system methods says that the "live in a separate namespace" (my emphasis). I don't think he means namespace in the sense of %SYS, SAMPLES, USER etc, but rather that your own method called "new" can coexist with the systemmethod called "new".