New post
AllAccepted answers
John Murray · May 3, 2016

Travis, are you aware of our well-established native Caché/Ensemble/HealthShare source code management and deployment tool? Previously known as VC/m, it's now called Deltanji.

As well as dealing with code versioning Deltanji also handles deployment. It integrates with Atelier, Studio and Portal.

Some members of this Developer Community may be willing to share their experiences of using our tool.

Perhaps you have specific reasons for wanting to go with Git, but it might be worthwhile considering Deltanji as an alternative route.

John Murray
George James Software

John Murray · May 3, 2016

Maybe your code at someLabel^someRoutine in OTHERNAMESPACE calls another routine that exists only in OTHERNAMESPACE. In that case, the <NOROUTINE> error will occur when the call is made. That's because when you d someLabel^|”OTHERNAMESPACE”|someRoutine(inputVar,.resultByReference) you are fetching the routine someRoutine from the database of the OTHERNAMESPACE namespace, but you are executing that code in your current namespace.

This is not the same as swapping to OTHERNAMESPACE, running the code, and then swapping back. For example, if someRoutine accesses globals it will do that from whichever namespace is current.

To see an example of this, try the following:

SAMPLES>w $zv
Cache for Windows (x86-64) 2016.2 (Build 636U) Wed Apr 13 2016 20:58:35 EDT
SAMPLES>d main^lookup
 
Lookup: 1-jan-2016...finding birthday...no matches
Lookup:
SAMPLES>zn "user"
 
USER>d main^|"SAMPLES"|lookup
 
Lookup: 1-jan-2016
<NOROUTINE>main+27^lookup *datent
USER 4d1>
 
USER 4d1>q
 
USER>

The code in main^lookup in the SAMPLES namespace calls $$validDOB^datent. When this is attempted from the USER namespace we get a <NOROUTINE> error. Notice that the extended information in the error tells us that the routine it can't find is datent.

John Murray · Apr 21, 2016

Somewhat related to this, I think there's still a useful role for %Studio.Project projects as ad-hoc server-side collections of classes etc that can be assembled independently of your package hierarchy, which typically has to remain far more static. But it's not yet clear to me how these projects (which after all are more correctly called "Studio projects") will evolve/mutate/expire in the brave new world of Atelier.

John Murray · Apr 12, 2016

Thanks to James for a prompt and detailed reply to my breakfast table question. Here I'm going to add this link to a previous posting of mine about %ALL, in part to highlight that %ALL mappings don't apply to 100% of the namespaces you have. The DOCBOOK and SAMPLES namespaces are apparently exempt. I can rationalize the DOCBOOK extension to myself, but the SAMPLES one puzzles me, especially given that the ENSDEMO namespace of an Ensemble or HealthShare instance is not exempt even though it's effectively another "samples" namespace.

John Murray · Apr 8, 2016

On my Atelier (1.0.131 on Windows) I have a Server Explorer view on the Atelier perspective:

As well as offering + and x buttons with which to add and delete connections, it also gives me access to the properties of a connection for amendment.

If you don't have the Server Explorer tab visible, look for it as an option on Window\Show View

John Murray · Apr 7, 2016

Francis, I think the idea of the "Developer Community Feedback" community/group is to discuss the behaviour of this community.intersystems.com website software.

I think your posting belongs better in the "Caché" community/group because that is the base product from InterSystems in which COS is implemented, and upon which Ensemble, HealthShare and DeepSee (which each have a separate community/group) are built.