@Perla Escarcega  - taking a closer look at this, I think we had an issue with a historical file clean-up routine which was a little too overeager to reclaim space.  All of your source is safe and available but you may need to create a fresh ItemSet to push this source.  Note - you should always be making fresh ItemSets anyway because the head revision may be newer than what is in your historical ItemSet, and you don't want to get an older revision of something which breaks when interacting with a newer revision of other items.  So simply create a new ItemSet for BASE and deploy it and you should be all set.

P.S.  This does raise the question of why you are initializing a new Secondary BASE environment from old ItemSets as opposed to just grabbing the head revision of the BASE source and running Refresh to pull it all into the Namespace?  I am afraid your approach may be significantly more risky than the recommended approach.  

@sjbttt sjbttt  - it sounds like you want to set up source control which controls this Readonly property on the server, is that correct?  If that is the case, then you will need to use server-side source control hooks.  https://cedocs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=GSTD_Hooks  would be a good place to start understanding how to manage this in general.

For your specific question, the way we force classes to be read-only with our source control hooks is via the GetStatus() method which should be extended from the %Studio.SourceControl.Base subclass of your hooks (see https://cedocs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?APP=1&CLASSNAME=%25Studio.SourceControl.Base
).  This method returns an "Editable" property which your hooks control and which can be used to force the IDE (Studio, Atelier or VSCode) to treat the file as Readonly, thereby preventing users from changing it.  In our development workflow, we will force the class to be Readonly in the following situations:

•  The user does not have it checked out
• A different user has it checked out
• The entire namespace has source locked (e.g. for non-development environments)
•  It is mapped from another namespace (we manage our source branches based on Namespace so we treat a read-only those things which are not in the current Namespace

Hope this is helpful.  

That may be the cleanest you can get it, unless you know that the methods are always Classmethods of the class you are calling in which case you don't need to send $classname() every time.  But sending it does allow for the generalized use-case of calling to different classes.

I was playing around to programmatically figure out how many argument a method accepts using %Library.ClassDefinition, however I just realized that if $classmethod() can't accept variable argument quantities than this doesn't help at all and you'd still end up with the approach that you have above.  

It may be worth a note to the WRC to ask for an enhancement to $classmethod() (unless someone chimes in here to say that there is a way to pass a variable number of arguments to it)

Not sure what you mean by occurring before and after.  However, you could pass the name of the method and then execute it using $ClassMethod within MethodA()

Something like:

Do ..MethodA("Method1","var","Method2",0)

MethodA {method1, arg1, method2, arg2) {

Do $classmethod($classname(),method1,arg1)

Do $classmethod($classname(),method2,arg2)

}

But again, I am not entirely sure what you want to accomplish here....

I suggest you contact Support if no one provides insights on this thread.  

Kevin,

If you are interested in a full kit install rather than a container, you can get yourself a full kit of InterSystems IRIS For Health Community Edition from:

https://download.InterSystems.com

(If you are interested in a container, see the other answers people have already given you)

HTH - welcome to the community and feel free to ask any questions here as you are learning / gaining your experience!

Ben

David,

I suggest you look into using the DeployToFile() and InstallFromFile() methods of the %Studio.Project class.  A discussion of the topic can be found here in the docs:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ADEPLOY

Another option is calling  the following on individual classes:

 $system.OBJ.MakeClassDeployed()

But since you are looking at just pushing partial updates, most likely the DeployToFile() with the parameter to strip out the source will be your best bet.

You can grab a Windows version of Caché 2018.1 from the WRC Distribution site and just install Studio out of there, or InterSystems IRIS Studio can also connect to earlier Caché versions, so you can grab a windows InterSystems IRIS Community kit from download.InterSystems.com  and install Studio out of there.

Vikram ... for now, I suggest that you use the opportunity to try InterSystems IRIS for free hosted in a cloud container:

https://www.intersystems.com/try-intersystems-iris-for-free/

Keep your eyes open for an announcement during Global Summit about another way  that you can get your hands on InterSystems IRIS for evaluation purposes.

Thanks!

Ben

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.

If your machine is virtualized, just clone the VM (that is what we do for all of our test upgrades).  NOTE - make sure to stand it up on an isolated network segment so that it doesn't try to do any inbound file processing or other communication that it should not (especially if you clone LIVE).

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:

https://mytest.myserver.com/csp/sys/UtilHome.csp?CacheUserName=tech&CachePassword=demo

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

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

}