I am assuming that when you are talking about 'folders' you mean the structure which individual items are exported into when you use your source control hooks, correct?  To achieve this you need to loop over all items in the namespace and call the source-control related export on each of them.

The way we do that for our internal systems is to the the BaselineExport() method in the %Studio.SourceControl.ISC class.  %Studio.SourceControl.ISC is our source control hooks class for Perforce, and I haven't tried calling BaselineExport() while another set of hooks are configured for the namespace, it may *just work*, especially if your GitLab hooks use the ^Sources global to describe the export structure.  Give is a try and let us know if it help (if not, I can get you the code for that method and you could adopt it for your purposes)

could you please give a little more of a description as to what you are hoping to accomplish?  A JS file will be executed on the client, where-as "Caché Code" (by this I assume you mean Object Script?) is executed on the server.

You can edit JS files using Studio, you can create object script class projections to automatically create JS files with JS logic in it, you can send JS from a server process to the web browser, etc - there are may ways for Caché Code to interact with, inform or manipulate JS files.  We need more details for what you want to do.

Bouncing off of @Robert.Cemper 's hints, if you are using a default SMP (system management portal) login you can just pass in the arguments for the username and password fields as follows:


I just tested this and it worked like a charm :) (use your own credentials of course)


We're using UnitTesting for application validation for internal application development within InterSystems.  If you have any specific questions, feel free to create new Questions in the D.C. and tag me, or if you would prefer a general discussion you can ask your Account Manager or Sales Engineer to set up a discussion with me.

There have also been several Global Summit presentations which have touched on the topic - not sure if you've seen these?


Ben Spead

Manager, AppServices, InterSystems

I can only comment on the original functionality in %Studio.SourceControl.ISC - if you're extending it you will need to do some debugging to see exactly why you are seeing the behavior that you are.

In the original %Studio.SourceControl.ISC class, when working in Connected mode (ie, Caché can issue p4 commands in real time to the Perforce server), the p4 command should take care of changing the file back to ReadOnly, which is what triggers GetStatus() to see it is uneditable and therefore not checked out.  It may be that your GetStatus() isn't correctly interpretting  the Reaonly state of the file, or if you are on UNIX, it may be that Caché doesn't see it properly as Readonly (this can happen if you are running your instance as Root).    Note - I think there may be a bug where after checking the %Studio.SourceControl.Change table isn't updated appropriately, but the primary indicator of checked  out/ checked in should be that Readonly bit on the file.

Hopefully this is enough to get you moving on this, and if not then I suggest you call Support to have them take a look with you and debug.  If there are any other questions I can answer in this forum I am happy to try.

Best of luck!

Adrian - are you writing your own Perforce hooks or use the sample Perforce hooks that ship with Caché? (%Studio.SourceControl.ISC.cls).

In %Studio.SourceControl.ISC.cls it checks to see if the file in the local workspace is Readonly or ReadWrite.  If Readonly it assumes it is not checked out and prompts the user to check out.  If ReadWrite it will see if it is a multi-developer or single-developer instance.  if single developer it can just edit it.  If multi-developer it will check in %Studio.SourceControl.Change to see if the current user is the one who checked it out - if so they can edit, if not they can a message of who is editing it in the Output window and the item is treated as ReadOnly to them.

Alex - I think it isn't a smart idea to call into a specific line number of a routine since the contents will change.  Instead you should call the line labels/functions called within the routine by outside of the routine and pass all appropriate variables, etc that way.

Trying to call a specific line number will certainly lead to faster than desired 'bit rot' in your unit test library.

Make sure that you review all of the shortcuts outlined in the documentation (there are a LOT of useful ones there):


Also, check out one of my favorite things to do with Studio which isn't as widely known as it should be:


Hope that helps :)


You can use $version(1) to see if it is Windows (returns '2') or UNIX (returns '3').  If you want to get really fancy you can include %occOptions.inc and then use the $$$isUNIX and $$$isWINDOWS calls (which just check to see if $version(1) is 2 or 3).

Personally, I like using ##class(%Studio.SourceControl.ISC).RunCmd() as it wraps the capture of the output for parsing.

You can tie $version together the other answers into something that is platform independent (warning, I haven't tested this, but I believe the pieces work):

If ($version(1)=2) {

   //Is Windows

   set sc=##class(%Studio.SourceControl.ISC).RunCmd("Ver",.out,0)

   set OS = out(1)

   // exercise of parsing exact desired version piece from the string is an exercise left to the reader

} elseif ($version(1)=3) {

   //Is UNIX

   set sc=##class(%Studio.SourceControl.ISC).RunCmd("uname -a",.out,0)

   set OS = out(1)

   // exercise of parsing exact desired version piece from the string is an exercise left to the reader

Hope that helps you Paul!


You are absolutely correct that using Client-Side source control hooks (ie the Eclipse Git hooks with Atelier) in a Shared development instance is a recipe for disaster and frustration.  You options are moving to Private development environments (each developer gets their own Namespace, or instance, or VM or container), or move to Server-side source control hooks.

I did an in depth session on this at Global Summit 2017 which should be of interest to you.  You can watch the recording and get the slides here:




Eduard - I think Arcady was asking from a purely data-processing perspective.  I.e. if you are already have a bunch of in-memory data and need to process/iterate on it, is it better to stick it in traditional structures and use $Order, or is it equivalent to stick it into the new structures for iterating and processing?  I think it's a good question and I would also like to hear what people think :)


It sounds like you are trying to use Atelier with client-side source control hooks against a shared development instance - is this correct?  If so, you are bound to experience frustration with this due to consistency issues.

Please review https://learning.intersystems.com/course/view.php?id=713 which discussed the 4 modes of development, which are to be avoided, and options available to you in a summary graphic from the training:

If you are going to be using Atelier with client-side hooks, I *strongly* recommend you move to giving each developer their own private instance to test against.


If you are using CCR then there are very specific  requirements in terms of development workflow which will provide assurances of no source loss, etc.  Please open a ticket with Support to discuss these specific concerns and considerations.

In summary, there can only be a single Disconnected BASE environments for each System, because the CCR Client Tools manage source concurrency within the Namespace, and if you have multiple BASE namespaces you have lost concurrency and therefore can lose source.  Atelier will work the same as Studio - you need a single Shared Dev Namespace using the CCR Client Tools (aka server-side source hooks) and at that point you can use either Atelier or Studio to edit the source in BASE.

IMPORTANT NOTE:  Server-side hooks will only work properly with Atelier if you are running a database version that includes CDS2924.  This is included in 2016.2.3+, 2017.1.2+ and 2017.2.0+ only.  If you are not sure if you have CDS2924 or not, please contact Support (if you use Atelier against a Shared Dev instance that doesn't have CDS2924 you don't have concurrency and therefore can lose source).

Hope that helps to get you started in the right direction :)


Welcome to Caché!  

Moving a database is really straightforward:

  1. Find the database definition in your 2007.1 instance in the System Management Portal
  2. Note the physical Directory where the cache.dat is located
  3. Shut down Caché and make a copy of the cache.dat file located in that Directory
  4. On your 2017.1 instance create a new database definition in the System Management Portal an point the Directory to the location of the copy of the cache.dat that you copied from your 2007.1 instance

Hope that helps!