An Idea Exchange for SAS software and services

Comments
by Regular Contributor
on ‎11-23-2016 02:16 PM

Paul,

 

I think if EG was built with this in mind it would be great.  I reluctantly vote for this because it seems as if I'm asking too much of the developers.  Being curious, I created a gitHub repository, and a EG project. 

 

https://github.com/PhilipColtharp-dc/SAS-EG---GitHub-Experiment-1

 

I began editing and saving an EG file, committing my changes to the repository.  To do this I copied the .EGP file, changed the resulting file's extention to .ZIP and then, consistently, extracted the zip to the file structure between the saves and commits.  I did this so that gitHub software would see files in the EGP file as they are.  If you want to take a look.  There is some infomration gleaned on changes made from commit to commit, but there is alot of other junk too.  Looking at this long enough I guess I would figure out how to write EP Tasks and reports using XML.  (I dare not stare too long) 

 

by Regular Contributor
on ‎11-28-2016 09:53 AM

@PhilC, thank you for your comment. I feel this is a reasonable request of the developers, as a good IDE has support for version control - of code, not binary files exclusively.

 

Thanks for sharing your repository. Sure, one could write XML from scratch, but is there any guarantee that the layout would be consistent across versions of EG? What if I want to import the code to DI Studio, for example? Using pure SAS code ensures usability across systems and SAS software, but .egp files are exclusive to EG.

 

It's great that we can commit .egp files, but I think it's important to consider good software engineering practice.

by SAS Super FREQ
on ‎11-28-2016 05:18 PM

I'm a little confused by this request...

 

EG *does* allow you to work with remote Git repositories.  The way one typically works with remote Git repositories is by cloning the repository to their local machine, work out of the local repository, and then push/merge changes back to the remote repository.  For example, if you have a GitHub project (or any other remote Git repository) with .sas programs, you can clone it to your local machine, then use EG to open those programs from your local repo, commit changes to them, view history on them, diff them, etc.   However, as with cloning, you have to go to an external tool (ex. Git Extensions, GitHub for Windows, SourceTree, etc.) or commandline for pushing/merging your local repo back up to the remote/origin.  EG directly integrates basic Git operations (commit, history, blame, diff), but more advanced operations (ex. clone, pull, push, merge, branch, squash, rebase) were intentionally left for other dedicated tools.

 

Since EG does support working with remote Git repositories, I assume this request is more accurately for "Git integration to work with .sas files accessed through a SAS server"?  You want to store .sas files in a Git repo on your SAS server and have your end-users be able to access the .sas files from your workspace server's Files location (ex. SASApp->Files)?  Then, be able to commit changes to the .sas files, view their history, etc. through the SAS server?  The SAS server does not currently provide any APIs for such source control operations.  EG has to have some way to perform operations on the Git repo, but the SAS server doesn't currently provide a way.  Even if the SAS server provided APIs, the Git repos on the server would have to be unique to each user -- you wouldn't want multiple people sharing the same working repo.

 

Please help me understand the request.  A specific example/scenario might help.

 

Thanks!

Casey

 

Note: EG's source control integration is for SAS programs exclusively (not EG project files (.egp), which are binary formats), hence the name "Program History".

by Regular Contributor
‎11-28-2016 05:20 PM - edited ‎11-28-2016 05:34 PM

Indeed. ( @paulkaefer )

 

Brainstorming about this a of couple things would be useful

  1. Program EG to create a EG projects that saves all submitted code and logs to a set directory,
    1. with each Process Flow getting a sub directory,
    2. and maybe each node in a sub-directory
  2. Program EG to set the file names, of the above files, as the icons labels or process flow labels  (which means the labels would need to be safely convertable to file system friendly names, or the labels could only be allowed to be file system friendly names)
  3. make it so that each ordered list was output as a sas program using %include statements.

    Simple so far... but then...

  4. make EG represent process flows as text files for use in popular versioning systems, ( why -- mainly because I would demand this.  It's one of the great points and reasons of using EG)
    1. make it so that EG makes SAS programs for each process flow  ...
      • Think about how hard this could be taking in to account you would want to convey an ordering of running SAS programs ( perhaps complicated series of %include statements) placed on the nodes of the "loopless directected graphs" comprising the process flow.
      • Then think about how hard it would be to see acurately changes to the ordering of these graphs, represented by code in text, in this process flow by way of gitHub or by other "diff"-like utlities. 
    2. Represent the Process flows as make files: I've always thought process flows were simplified "makefile"s, but even simplified makefiles are difficult to interpret. 
    3. The "Dot" language:  another candidate.  Process flows might be formatted like code in this article.  Still hard to see changes.

 

...  Paul,

now that I've thought about it more, and because of this last point, I think we might be more sucessful at making a "gitHub" or "SVN"  look more like an "Enterprise Guide" than make Enterprise Guide fit inside these popular versioning systems. 

by Regular Contributor
on ‎11-28-2016 05:29 PM

@CaseySmith, my original suggestion is just to have built-in git support, as SVN support already exists. Correct, I can run git externally, whether my code is saved on my local machine or on a server. However, it would be easier for some users if one could have a visual git built-in to EG. Like other IDEs (example: Microsoft Visual Studio).

 

@PhilC: I very much appreciate your discussion. Rather than try and refactor .egp files, I just want a way to commit the raw code. I'd be happy if you can commit both the raw code and the .egp file itself (optionally). But the suggestion is just to have the same general support for git as currently exists for SVN.

by SAS Super FREQ
on ‎11-29-2016 01:51 PM

Ok, I think I understand now.  It sounds like you want more feature-rich Git integration in EG than what is currently provided.

 

EG (starting in v7.11) does have built-in Git support for *some* basic Git functions, such as commit, diff, blame, history -- things you'd typically do while writing a program.  However, EG does not currently support other non-basic Git functions, such as cloning, pulling, pushing, merging, resolving merge conflicts, branching, squashing, rebasing, etc.  We intentionally left those more advanced operations to dedicated Git tools for our initial release -- to reduce complexity and avoid re-inventing the wheel.  However, that does mean that you can't currently do everything you need to do Git-wise in EG.  To use Git in practice with EG, you'd have to use EG in combination with a Git GUI or Git command-line.  For example, here is how a SAS programmer might work today:

  1. Clone Git repo using Git GUI or command-line
  2. Create and checkout a feature branch using Git GUI or command-line
  3. Open .sas files from locally cloned repo into EG
  4. Edit .sas files in EG
  5. View Git file history in EG
  6. Diff changes in EG
  7. Commit changes to local repo from EG
  8. Checkout master branch using Git GUI or command-line
  9. Pull and merge latest into master repo using Git GUI or command-line
  10. Merge feature branch into master branch using Git GUI or command-line
  11. Resolve merge conflicts using Git GUI or command-line
  12. Push commits to origin/remote using Git GUI or command-line

 

We have been discussing some ideas on how we could add more complete Git integration in EG, such that a SAS programmer could develop their programs stored in Git without having to leave EG.

 

Let me know if I don't have that right.  And thanks for your suggestion!

 

Casey

 

Note: EG does not currently have any direct SVN integration.  You can use SVN with EG, but there is no direct integration.

by Regular Contributor
on ‎11-29-2016 02:34 PM

@CaseySmith, thanks for the detailed response. Actually, I'd be happy with just basic git integration - and I'm still on EG 7.1, so it sounds like what I am looking for is available in 7.11 and later.

 

I personally would be fine with just the basics integrated, and more advanced features like merging requiring you to use your external tool. I'm used to the workflow of committing via the command-line anyway, and commit/diff/history are the most common uses by far.

 

Thanks so much for your discussion. I look forward to using future releases!

by SAS Super FREQ
on ‎11-29-2016 10:24 PM

@paulkaefer I'm sorry, my memory failed me!... the Program History feature (basic Git integration) was added in 7.1, so you should already have access to it.  You should see "Changes", "Commit", and "History" buttons on the contextual toolbar when a program is open in the EG editor.

 

It is briefly discussed here at the beginning of this blog post by Chris Hemedinger:

http://blogs.sas.com/content/sasdummy/2014/10/12/eg-71-new-programmer-features/

 

And if you want more information on the feature, here is a paper that covers it in detail:

Check It Out! Versioning in SAS® Enterprise Guide®

 

Glad to hear that it may already meet most of your needs.  Would be happy to hear additional feedback you might have when you get a chance to play around with it.

 

Casey

 

by SAS Super FREQ
on ‎11-29-2016 11:36 PM

@PhilC, you hit the nail on the head regarding the serious challenges we faced when contemplating full versioning for EG projects and process flows.  You can't beat text versioning.  Ultimately, we decided adding source control integration for SAS programs (since text-based), was much more practical and what users really wanted.

 

Dot language is interesting...  been reading up on it for the last 30 mins.  Thanks for sharing!

by Regular Contributor
on ‎11-30-2016 10:03 AM

@CaseySmith, you're right. But I should have been more clear... that's only local git integration. If my code is stored on a server, rather than my own local machine, this doesn't work.

Idea Statuses
Top Liked Authors