The TROLLBACK command doesn't automatically release LOCKs that were acquired within the transaction. The TROLLBACK documentation is a bit confusing in this regard. At one point it says this:

Then later on the same page this text seems to say that both TROLLBACK and TCOMMIT do release locks.

Jordi, in your example:

TSTART

Do ##class(MyTable).%OpenId(<TableID>, 4) (This internally is creating a Lock +^User.MyTable(<TableID>)

TROLLBACK (This action removes the previous lock)

I don't think it's the TROLLBACK that's releasing the lock, but rather the destruction of the oref that the %OpenId method created. Indeed, if tested exactly as you wrote it that oref doesn't even get stored in a local variable, so ceases to exist as soon as the method call completes.

The old Google group isn't owned or managed by InterSystems, and previous attempts to get whoever does manage it to do anything to tackle the potential confusion etc have been unsuccessful. There are several other  posts here on DC about this. For example:

https://community.intersystems.com/post/automatic-crossposting-developer-community-google-group-user-intersystemsdc

For others, search DC for the term "Google".

That's the doc for the %SYS.Task package. One row above it in the Documatic explorer panel you'll find the link to the %SYS.Task class. Here's a link to the online copy for 2017.1

http://docs.intersystems.com/cache20171/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25SYS.Task

I'm seeing ExportTasks and ImportTasks methods, both inherited from %SYS.TaskSuper

I disagree with your assertion that you can't call at a tag in a way that you can call from the top:

USER>zp
YJM      w !,"Runs in ",$namespace,! q
         ;
SUB      ; A subroutine tag
         w !,"SUB^YJM runs in ",$namespace,!
         q
 
 
USER>zn "samples"
 
SAMPLES>d SUB^|"USER"|YJM
 
SUB^YJM runs in SAMPLES
 
SAMPLES>

I find it confusing that you talk about calling a routine in a namespace. As I see it you're fetching it from another namespace (i.e. the one the routine lives it), but you're running it in your current namespace.

You also need to be aware of what happens if the code you fetch from the other namespace makes its own calls to other code. Here's an illustration:

USER>zp
YJM      w !,"Runs in ",$namespace,! q
         ;
SUB      ; A subroutine tag
         w !,"SUB^YJM runs in ",$namespace,!
         q
         ;
Test1    ;
         w !,"About to call local line label YJM",!
         d YJM
         q
         ;
Test2    ;
         w !,"About to call a line label in a specific routine",!
         d SUB^YJM
         q
 
USER>d Test1^YJM
 
About to call local line label YJM
 
Runs in USER
 
USER>d Test2^YJM
 
About to call a line label in a specific routine
 
SUB^YJM runs in USER
 
USER>zn "SAMPLES"
 
SAMPLES>d Test1^|"USER"|YJM
 
About to call local line label YJM
 
Runs in SAMPLES
 
SAMPLES>d Test2^|"USER"|YJM
 
About to call a line label in a specific routine
 
 d SUB^YJM
 ^
<NOROUTINE>Test2+2^YJM *YJM
SAMPLES 2d0>
 
SAMPLES 2d0>q
 
SAMPLES>

Kenneth, I don't think you are correct here. Apart from invalid syntax you gave, even with the correct syntax the routine is fetched from the specified namespace and executed in the current namespace. See the following example using a simple test routine (YJM) that I created in my USER namespace and then executed from my SAMPLES namespace:

USER>zl YJM zp
YJM      w !,"Runs in ",$namespace,! q
 

USER>d ^YJM

Runs in USER

USER>zn "SAMPLES"

SAMPLES>d ^YJM

D ^YJM
^
<NOROUTINE>^YJM *YJM
SAMPLES>d ^|"USER"|YJM

Runs in SAMPLES

SAMPLES>w $zv
Cache for Windows (x86-64) 2017.2.1 (Build 801U) Wed Dec 6 2017 09:07:51 EST
SAMPLES>d ["USER"]YJM^YJM

D ["USER"]YJM^YJM
^
<SYNTAX>^YJM
SAMPLES>

Bob, your question doesn't belong in the "Developer Community Feedback" group, since that's for -- well -- feedback about Developer Community. Nor is the "Developer Community" tag appropriate for it, since that also is intended for posts about DC. Please edit your post, moving it to another group, perhaps "Ensemble", and removing the "Developer Community" tag.

UPDATE - it looks like someone (one of my fellow mods?) has moved it to the Ensemble group already. You can still remove the tag, and maybe remember not to post to "Developer Community Feedback" in future unless that's the nature of your post. Thanks!

Sounds like you already have server-side source control (CCR) similar to the Deltanji product from my employer George James Software. In that case, your simplest option is to get your Atelier users to connect to the server instances in the same way as they currently do with Studio.  There's no need to change your code management paradigm (and thus your source control system) as well as your editor.

I recommend you go through that Global Summit session Ben Spead referenced in his earlier comment.