Mike,

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?

Best,

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.

Eduard - I completely agree!

The nice (or annoying, depending on your perspective) thing about moving to the discipline of unit testing is that it forces you to write your code in a more modular (and therefore more testable) manner, and refactoring to meet these goals is a great byproduct of a testing focus :)

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):

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

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

https://community.intersystems.com/post/studio-tip-running-cos-commands-...

Hope that helps :)

Ben

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

}

Daniel,

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:

https://learning.intersystems.com/course/view.php?id=713

HTH,

Ben

Please contact InterSystems Support for assistance on this:

https://www.intersystems.com/support-learning/support/immediate-help/

Thank you,

Ben

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 :)

If you call LOG^%ETN it will dump all of the stack into the Application Error Log which you can access via the management portal or the terminal.

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=ATRYCATCHFAQ has some discussion on LOG^%ETN which may be helpful.

Ben

In the Management Portal go to:

 System > Configuration > Memory and Startup

Change the System Mode and it will put a custom banner in the header indicating Dev / Test / Live

Kumar,

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.

Kumar,

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 :)

Geoffroy,

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!

Ben

See this thread which discusses several options for server-side Studio hooks for Git:

https://community.intersystems.com/post/are-there-server-side-git-studio...

NOTE - in my use-case I was looking for server-side hooks in order to allow concurrent server-based development, and I discovered that Git is very poorly suited for that purpose.  I ended up abandoning Git and using Perforce instead for my demo (Perforce is very well suited for server-side hooks with concurrent server-based development).  If you are you already operating in a single-developer / single instance setup and if you can move to one of the very latest versions of the product (2017.2.0+ or 2017.1.2+) then you should take a look at Atelier with client-side source control hooks.

For a thorough review of the different development models (private instance vs shared instance) and the different source control hook approaches (client-side vs server-side), I highly recommend that you watch the following session from last year' Global Summit:

https://learning.intersystems.com/course/view.php?id=713

Stephen,

An advantage to this is that the WRC will have a history of snapshots of your config and some basic operating data so that if you need to contact them about a performance issue, behavior change, etc, they could look back and see changes which have taken place in your system that might impact current behavior.  

Several large customers take advantage of this to make it easier to see trends in their instances.

HTH,

Ben

Check out the full tutorial which includes REST API set-up:

https://community.intersystems.com/post/lets-write-angular-1x-app-cach%C...

I completely agree - this would make the results much more helpful!