05-05-2015 05:29 PM
We are trying to use TortoiseSVN version control on our SAS programs, the problem is our programs are usually saved on Linux server directly from SAS Enterprise Guide, and looks like SAS EG doesn’t support SVN. So we are thinking to copy programs from the server to windows environment, then add to repository using SVN, but doing this we’ll always need to copy the programs from the server, is there any better way to use SVN on SAS EG programs?
05-05-2015 06:07 PM
What version of EG are you using? Integrated versioning was only added in EG 7.1. If you are wanting to version non-embedded EG SAS programs (code stored as external files not in EG projects) outside of EG, as this is the only option for earlier EG versions, then any Version Control Software will work with SAS programs as they are simply text files. Where I work we use MS Visual Studio and TFS and it works very well. We are on EG 6.1 but how we use TFS works with any version of EG.
05-06-2015 10:48 AM
We have EG 5.1, and our company already have TortoiseSVN. The problem is our programs are all sitting in the server, and users use EG to create/edit them. We don’t have windows EG. So looks like we have to copy our programs from server to local drive in windows, in order to use TortoiseSVN. Was hoping can have SVN installed in EG, which TFS can? Right?
05-06-2015 11:45 AM
The only source control system that EG (as of version 7.1) currently has direct integration with is Git. However, as noted, you can use any other source control system external to EG, since EG just references those .sas files that are saved on disk. In this scenario, you work on the .sas files from within EG, save them to disk, then use your external source control tools to commit/check-in them.
The problem you noted is that your .sas programs are not accessed in EG through the local file system. Rather, you access them through the SAS server. With most source control systems, you work off of local copies of the files, then you commit or check them in to your central repository. So, to use source control with EG, we recommend not saving the files through the SAS server, since source control systems do not work through the SAS server -- they require file system access. Rather, your working copies should be accessible from your local file system (and opened from there in EG), then commited/checked-in to your central repository.
(Note: It is possible to continue saving the files to the SAS server, then commit them from the host machine of the SAS server using your source control tools, but we definitely do not recommend this approach for a number of reasons... if multiple users are working on the same working copies of the files it will be difficult to see who actually made which changes (whoever commits the changes will "have made" the changes), users won't typically have access to the server machine to commit/check-in, etc.)
05-06-2015 01:03 PM
One solution would be to let TortoiseSVN "see" the /home directory on the SAS server. Then you could check the .sas files out to your server directories and also commit from there. If the "working" copies of .sas files sit in the individual home dirs of the users, you cannot have a collision there, as only the owner of the directory can work in it.
05-06-2015 02:43 PM
I'd be interested in hearing if Kurt's suggestion is workable for TortoiseSVN, making your Linux directory visible to TortoiseSVN via Samba.
This note suggests it can work, may need to play with Samba permissions.