SALT and Version Control

1. SALT and Version Control How to handle projects using version controlled SALT V1.09

2. Reasons for external storage Ever since large IT projects have been going on there has been a need to keep code out of the workspace and manage it. Whether the code is small or big. Sep 2009

3. Reasons for external storage Programs evolve and distributed copies should be kept separately, even if small Sep 2009

4. Reasons for external storage • More room needed in the workspace • Backup copies (security) • Modularize code • Code control • Trace history • Find culprits • Etc. Sep 2009

5. Managing applications • Larger applications have to be maintained whether they are written in APL or not • You have to keep track of changes to know who's done what and when • You must be able to undo changes • Generally cope with (large) system related problems Sep 2009

6. workspace Code DB Managing applications Apps have been maintained using a combination of workspace and external storage Sep 2009

7. How In APL: • APL files (most common way) • Other workspaces ([]CY) • External DBs (e.g. Oracle) • Etc. In other (e.g. compiled) languages • Text files (distributed, e.g. file system) Sep 2009

8. APL stands out The rest of the world APL Sep 2009

9. Managing applications in APL This makes porting code or even sharing snippets of it difficult. • You cannot transport it • Hard to compare changes • You need the (proper) interpreter just to VIEW the code Sep 2009

10. Managing applications in APL • You need to maintain the code management system (CMS) itself • Employees need time to learn it • They go away with “useless” skills when they leave • The IT dptm sees APL as a problem, an outcast Sep 2009

11. Managing applications in APL There is another way: Unicodetext files • You can transport them • You don’t need any interpreter to VIEW them • They integrate with any text file based control system Sep 2009

12. Managing applications in APL With existing text based CMS • You don’t need to write your own CMS • Employees may already know about it • They go away with useful skills • The IT department doesn’t see APL as a non team player Sep 2009

13. APL doesn’t have to stand out The rest of the world APL Sep 2009

14. Unicode With the wider acceptance of Unicode it has become easier to share code in text files. • They can be reorganized e.g. Disk Explorer • APL code can now be cut & pasted and viewed in Notepad or other Unicode compliant editor/program • They can be exchanged easily Sep 2009

15. Dyalog V11 • This version introduced the scripted form of classes/namespaces • Their definitions, including functions in them, can be edited. Sep 2009

16. Dyalog V11 • The definition of objects like classes can be retrieved and manipulated like the definition of functions • And, like the ⎕CR of a function, it can be stored outside the workspace, e.g. in a text (Unicode) file Sep 2009

17. Requirements All that is needed to store and retrieve text to any Operating System is a pair of functions to • Store code to a text file • Read a text file into the workspace Easy enough to do. Sep 2009

18. Requirements Of course, once you’ve done that you may want to: • Save multiple versions • Retrieve any of them • List them • Compare them • Etc. * Basically manage them * Sep 2009

19. Enter... SALT Sep 2009

20. OK, so, what is SALT? Sep 2009

21. SALT SALT is exactly that: • A pair of functions to store/retrieve • + other functions to list/compare/etc. • + utility functions (e.g. ease migration of namespaces to text format) Sep 2009

22. SALT SALT stands for Simple APL Library Toolkit Itis a source code management system for functions, Classes and script-based Namespaces in Dyalog APL. Sep 2009

23. SALT basics • SALT is tucked away in ⎕SE - you can )LOAD and run any workspace anytime • To save a namespace use Save:⎕SE.SALT.Save 'myns \path\myfile' • To bring in a namespace use Load:⎕SE.SALT.Load '\path\myfile' Sep 2009

24. Features • The editor can be rigged to react on edition of SALTed objects • The user commands include all the SALT functions, e.g. ]save myns \path\myfile Sep 2009

25. Features SALT can save back a script on file right after it has been modified. Modify <test> After modification you are prompted to confirm saving over the present script file: Sep 2009

26. Storing a script with a stack This can happen if you modify a function of a class on the stack. Stack shows up Edit the function After modification you are prompted to confirm saving over the present script file. Once saved both the script and the class are modified and you can resume execution. Error happens Sep 2009

27. Storing multiple version of a script • You can store and KEEP several versions of a script. • By using the –version modifier you tell SALT to start using version numbering: Sep 2009

28. Storing multiple version of a script Every time you modify a script SALT stores the definition in a new file: V0 V1 Sep 2009

29. =? Showing differences between versions SALT can show the difference between 2 versions of a script, either • natively, using APL, or • using a 3rd party Unicode comparison program Sep 2009

30. → is used to denote inserted lines ← is used to denote deleted lines =? lines inserted lines modified Showing differences between versions If ‘APL’ is the method chosen to compare, the output will appear in the session like this: Sep 2009

31. SALT features SALT has many more features It is UNIX ready It comes with tools of its own It can be extended easily by adding your own utilities Sep 2009

32. SALT limitations For small applications it may be sufficient to keep all code on file managed by SALT For larger apps this is clearly inadequate, you need Version Control on a grander scale Sep 2009

33. What is Version Control (VC)? VC is a good way to ensure team members of a project don't step over each others' toes. On a large project it is imperative to use VC. Otherwise, time (and money) will be lost trying to recover from coordination problems.

34. original files repository import Version Control overview You usually start by importing an existing system (a set of files) into a version control repository: Sep 2009

35. Version Control overview The original files can then be forgotten: original files repository Sep 2009

36. original files repository checkout subset Version Control overview You then checkout a subset to work with: Sep 2009

37. Version Control overview You then work on the subset for a while: repository subset Sep 2009

38. Version Control overview If you are using SALT you maintain the files from APL: Dyalog APL subset Sep 2009

39. Version Control overview Every once in a while you update the repository: repository Checkin subset Sep 2009

40. repository new release export Version Control overview When the repository is in a stable state you may produce a new release: Sep 2009

41. VC systems There are several VC systems out there. To mention a few: PerForce, ClearCase, Visual SourceSafe, CVS and SubVersion. There are pros & cons for each. Sep 2009

42. VC systems In the following slides we'll use subversion as an example. subversion is a popular open source program. It is well documented, has a large user base and it's free. Sep 2009

43. Enter... subversion Sep 2009

44. subversion subversion is a version control system for Unix and Windows. It is independent of any file system or file types to manage It is easy to install Sep 2009

45. subversion subversion comes in command line (shell) mode. Most commands involve a single program: svn. For ex: svn import ... svn checkout ... svn checkin ... svn export ... Sep 2009

46. subversion There are many more commands in subversion. They handle updates, conflicts, allow to see differences between versions. The complete list is extensive but well documented. Sep 2009

47. subversion There is also a GUI front-end for subversion. This front-end is completely separate but closely integrated to the GUI. It's name isTortoiseSVN. subversion is integrated. Sep 2009

48. subversion Different people prefer different things: Windows users may choose the GUI front-end for subversion. Unix users may prefer the shell environment APL users might prefer to stay in APL Either way the results will be the same: better coordination! Sep 2009

49. subversion: an example Assuming we have the following workspace named ROBOTS written in Dyalog: It has 2 top level namespaces in which there are 5 (nested) namespaces: • namespace Master: 2 namespaces • namespace Troopers: 3 namespaces Sep 2009

50. workspace Master Data game Troopers Pound SDuck Robot1 subversion: an example There are 7 namespaces, 5 of which are nested Sep 2009