I understand ... so you want to only export specific things which it has found to have differences in the code. That makes sense since you are trying to use it at the end of a piece of code already in place. I am afraid I don't know how to do that, but if you contact Support they may be able to suggest a trick or two.
Is there a reason that the use of a Virtual Namespace is a requirement? If not, you can use ##class(%Studio.SourceControl.ISC).BaselineExport() to export the entire contents of the Namespace to disk for file-based diffing (this is how I normally do it)
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.
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.
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 :)
I absolutely concur that if a shared dev instance is going to be used along with client-side hooks then locking is a *must*! However, some may find that exclusive ownership on a single Shared dev instance is too restrictive, but find themselves still needing a Shared dev instance in the mix for certain reasons.
An alternative would be a Mixed mode of working with a Shared Dev and one or more Private Dev environment. We have found that this mode works really well for us in the case for large teams on active projects - locking across the board we've found to be too restrictive in how it blocks work. We have found this on a couple of our most active applications where we need shared development instance for a number of reasons. In order to make this work, you will need to move to using Server-Side Source Control hooks on the Shared dev instance, and then developers that don't require work on the shared dev instance can have a private instance which uses either Server-Side or Client-Side source control hooks (in our case we use server-side in Private dev instances to make it easier to support). This will work because the Server-Side Hooks on Shared should manage concurrency of any developers connected to that instance (they can't check out a file someone is already working on), while not locking the file in source control which would prevent other developers from touching it on their Private Dev instances.
Just throwing this out there as another option for those who find that they are tripping over exclusive locking, and are not comfortable running with unlocked files on the Shared Dev instance.
Also, a big thumbs up for including the suggestions of Jenkins - we have started using it this year to automate build/unit/code coverage testing on every check-in and are seeing some great results!
Mack- the %occLibrary calls are not documented for use by applications.
As your very interesting questions has proven the ease with which this is solved by:
$$CSVtoList^%occLibrary(csv)
I suggest you contact the WRC to request an enhancement to have this wrapped in a supported (and documented!) API that may be more future-proof than this internal and undocumented call.
I understand ... so you want to only export specific things which it has found to have differences in the code. That makes sense since you are trying to use it at the end of a piece of code already in place. I am afraid I don't know how to do that, but if you contact Support they may be able to suggest a trick or two.
Is there a reason that the use of a Virtual Namespace is a requirement? If not, you can use ##class(%Studio.SourceControl.ISC).BaselineExport() to export the entire contents of the Namespace to disk for file-based diffing (this is how I normally do it)
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 :)
Excellent article Michelle! Very well done :)
I absolutely concur that if a shared dev instance is going to be used along with client-side hooks then locking is a *must*! However, some may find that exclusive ownership on a single Shared dev instance is too restrictive, but find themselves still needing a Shared dev instance in the mix for certain reasons.
An alternative would be a Mixed mode of working with a Shared Dev and one or more Private Dev environment. We have found that this mode works really well for us in the case for large teams on active projects - locking across the board we've found to be too restrictive in how it blocks work. We have found this on a couple of our most active applications where we need shared development instance for a number of reasons. In order to make this work, you will need to move to using Server-Side Source Control hooks on the Shared dev instance, and then developers that don't require work on the shared dev instance can have a private instance which uses either Server-Side or Client-Side source control hooks (in our case we use server-side in Private dev instances to make it easier to support). This will work because the Server-Side Hooks on Shared should manage concurrency of any developers connected to that instance (they can't check out a file someone is already working on), while not locking the file in source control which would prevent other developers from touching it on their Private Dev instances.
Just throwing this out there as another option for those who find that they are tripping over exclusive locking, and are not comfortable running with unlocked files on the Shared Dev instance.
Also, a big thumbs up for including the suggestions of Jenkins - we have started using it this year to automate build/unit/code coverage testing on every check-in and are seeing some great results!
It's deprecated but still available. Swapping it out for $zf(-100) for %Studio.SourceControl.ISC is on the TODO list...
check out the ##class(%Studio.SourceControl.ISC).RunCmd() method for an easy way to capture the OS output
Mack- the %occLibrary calls are not documented for use by applications.
As your very interesting questions has proven the ease with which this is solved by:
$$CSVtoList^%occLibrary(csv)I suggest you contact the WRC to request an enhancement to have this wrapped in a supported (and documented!) API that may be more future-proof than this internal and undocumented call.
Nice work Gerd!