1 / 121

SALT and Version Control

SALT and Version Control. How to handle projects using version controlled SALT V1.09. 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.

mareo
Télécharger la présentation

SALT and Version Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related