|
|
| (45 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| ==Introduction== | | <p style="font-size: 14pt">eval() [Computer Programming]</p> |
| Version Control Systems are typically used in a software facility(s), and employed for the primary purposes of collaborative work. While working on a project with common resources (files, folders, information etc.), it becomes essential to put a definite order on the sanctity of the data if the resources are editable.
| | =Introduction= |
| | The eval facility is one of the most powerful features of Ruby (as well as other dynamic languages). |
| | Kernel.eval method will parse and execute an arbitrary string of legal Ruby source code. |
| | To put it plainly, if your Ruby program can generate a string of valid Ruby code, |
| | the Kernel.eval method can evaluate that code. The eval facility gives developers the ability to |
| | modify the runtime behavior of program. Illustrate the practical advantages of Ruby's eval(...) |
| | and compare it with similar mechanisms in other languages. |
|
| |
|
| For example, if there are 10 people working on a project, and 3 people are working on the same file. It becomes important on how they can add/modify data such that all are neither locked out waiting for a lock put by anyone, nor there is any inconsistency in the data. Also, at any point in the life-cycle of the software, the developers might feel the need to go back to an earlier state of the file. Version Control Systems allow to go back to any previous version of a file, as each version is stored in the central repository and is given a label.
| | =Origin= |
| | [http://en.wikipedia.org/wiki/Lisp_%28programming_language%29 LISP] The first actual implementation of |
| | LISP was by Steve Russell. He realized that the Lisp ''eval'' function could be implemented in machine code.[3] The result was a working Lisp interpreter which could be used to run Lisp programs, or more properly, 'evaluate Lisp expressions.' |
|
| |
|
| Version control systems typically let us create versions of the resources, where each developer can work on a different version, therefore providing the flexibility. There are a whole bunch of features provided by the new Version Control Systems. We shall look at the evolution and history of the same in the subsequent sections.
| | [[File:http://en.wikipedia.org/wiki/File:LISP_machine.jpg|<span title="Original LISP machine"></span>] |
|
| |
|
| ==Taxonomy of Version Control== | | =Security risks= |
| | It may seem natural to perform <tt>eval()</tt> on user-supplied data, exposing the entire power of the underlying |
| | programming language with a single statement. For example, on a web site, the programmer might allow the user to |
| | enter an expression, and with trivial effort on the part of the programmer, the result of the expression is computed. |
| | However, a moment's thought reveals the grave security risk posed by such an approach. The user could intentionally |
| | or unintentionally delete files, corrupt files, transmit sensitive information, etc. |
|
| |
|
| <b>Branch</b> : When the development team needs to work on two distinct copies of a project, a branch is created. <sup>[4]</sup> The branch is a replica of the existing code at the time of its creation. On creation of the branch, changes made to a branch are confined to it and are not visible in any other branch.
| | =Context= |
|
| |
| <b>Repository</b>: Repository is the data store where all the versions of all the files in the project are stored. A repository may be centralized or distributed.
| |
|
| |
| <b>Check-Out</b>: Creating a working copy of the files in the repository on a local machine is called Check-out. Every user who checks out a file has a working copy of the file on his computer. Changes made to the working copy are not visible to the team members
| |
|
| |
| <b>Check-In</b>: Putting back the edited files to the repository for use by everybody is called Check-In
| |
|
| |
|
| <b>Merge</b>: Merging is the process of combining different working copies of the file into the repository.[3] Each developer is allowed to work on their independent working copies, and everyone’s changes to a single file are combined by merging
| | =Implementation= |
|
| | ==Dynamic Programming Languages== |
| <b>Label</b>: A label is an identifier given to a branch when created. Also known as Tag
| | ===Lisp=== |
|
| |
| <b>Trunk</b>: The highest location of the repository is called Trunk.
| |
|
| |
|
| | [http://en.wikipedia.org/wiki/File:LISP_machine.jpg Lisp] is the second-oldest high-level programming language in common use |
| | today (after FORTRAN). Invented in 1958 by John McCarthy at Massachusetts Institute of Technology, LISP was first actually implemented |
| | in machine language by Steve Russell, who realized that by implementing the LISP <tt>eval()</tt> function in assembly language, |
| | he could create a working LISP interpreter. |
|
| |
|
| ==History of Open Source Version Control Systems== | | ===Perl=== |
|
| |
|
| ===<b>Source Code Control System (SCCS)</b>=== | | ===Ruby=== |
| | |
|
| |
|
| The exact time in history when and how the version systems came about into existence is unclear. However, we can estimate roughly that the version control system can be rooted to the <b>Source Code Control System (SCCS)</b> <sup>[3],[6]</sup>. It was developed by the Bell Labs in 1972. It is no longer prevalent, but the file format is still internally used today by other softwares like <i>BitKeeper</i> and <i>Sablime</i><sup>[6]</sup>
| | trane = %q{"John Coltrane".length} |
|
| |
|
| ===<b>Revision Control System(RCS)</b>===
| | eval trane → 13 |
|
| |
|
| The next generation of Version control system was the RCS. It was first released in 1982, and developed by Walter F. Tichy of Purdue University. It was considered to be a better version of SCCS. Also, the version syntax was very complicated. Usually the developers employed locking mechanism, and worked on a single branch(head).
| | ===JavaScript=== |
|
| |
|
| One situation where RCS could prove to be useful is while a single user needs to work on a project. As RCS does not demand a central repository to be set up, and the administration and maintenance of files is easy, hence, it is easy.
| | ===PHP=== |
|
| |
|
| The limitations of RCS were that RCS could only work on a single file. There was no way that multiple files in a project could be versioned.<sup>[7]</sup>
| | ===Python=== |
|
| |
|
| | ===ColdFusion=== |
|
| |
|
| ===<b>Concurrent Versions System(CVS)</b>=== | | ==Static Programming Languages== |
| | ===Java=== |
| | GroovyShell |
|
| |
|
| CVS was one step ahead in the evolution of the Version control Systems. CVS is distributed under the public GNU license. One major advantage where the CVS edges over RCS is its [http://en.wikipedia.org/wiki/Client%E2%80%93server_model Client-Server Architecture]. RCS did not support a client-server architecture, which made it difficult for distributed development.
| | ==Command Line interpreters== |
|
| |
|
| CVS based systems provided for the first, the ability to <i>check out</i> a version of the main copy in the repository. The developers could work on their individual copies, and later, push it back into their branches. Once all the development on the files was done, the developers could merge their code with the live copy. There is however a restriction posed by the CVS systems, that is it only allows modification of code on the latest version. This calls for the developers to regularly sync their code with main copy in the repository, so that the modifications done by other people are also covered.
| | ===Unix=== |
|
| |
|
| CVS uses [http://en.wikipedia.org/wiki/Delta_compression delta compression] technique to save space on the multiple copies of the same files. In short, the CVS systems keep only one copy per se. Wherever another set of copy is needed, it just stores the differences from the original copy. If there is no difference between the two, then the 2 files are in sync, else out of sync.
| | = References = |
| | [http://en.wikipedia.org/wiki/Eval] Eval, Retrieved October, 2010. |
|
| |
|
| One of the biggest advantages of the CVS system was the ability for distributed development. However, there were quite a few areas where it lacked and called for better methods. To name a few, CVS could only work reliably with ASCII characters. It did not work well with other character sets for example UTF.Also, there was no atomicity of operations i.e. there was no way to ensure commit or rollback in case of an error. A detailed list of criticisms is mentioned at http://en.wikipedia.org/wiki/Concurrent_Versions_System#Criticism.
| | [http://en.wikipedia.org/wiki/Eval] Eval, Retrieved October, 2010. |
|
| |
|
| ===<b>Subversion(SVN)</b>===
| | [http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055/ref=sr_1_2?s=books&ie=UTF8&qid=1286121051&sr=1-2] Programming Ruby: The Pragmatic Programmer's Guide |
| | |
| Working on most of the criticisms of CVS mentioned before, in 2000, an attempt to improve the structure of the CVS led to the development of SVN. The developers did not want to change the philosophy or change the structure of CVS in a totally new way, they just wanted to revamp whatever was done before. Partly because CVS was then the <i>de facto</i> standard for version control. <sup>[9]</sup>
| |
| | |
| SVN matched CVS's features, and preserve the same development model, but not duplicate CVS's most obvious flaws. SVN was aimed to be similar enough that any CVS user could make the switch with little effort.
| |
| | |
| SVN provided the following additions/changes to CVS features<sup>[11]</sup>:
| |
| | |
| <b>Directory versioning:</b> CVS only tracks the history of individual files, but Subversion implements a “virtual” versioned filesystem that tracks changes to whole directory trees over time. Files and directories are versioned in SVN.
| |
| | |
| <b>True version history:</b> Since CVS is limited to file versioning, operations such as copies and renames—which might happen to files, but which are really changes to the contents of some containing directory—aren't supported in CVS. Additionally, in CVS you cannot replace a versioned file with some new thing of the same name without the new item inheriting the history of the old—perhaps completely unrelated—file. With Subversion, you can add, delete, copy, and rename both files and directories. And every newly added file begins with a fresh, clean history all its own.
| |
| | |
| <b>Atomic commits:</b> A collection of modifications either goes into the repository completely, or not at all. This allows developers to construct and commit changes as logical chunks, and prevents problems that can occur when only a portion of a set of changes is successfully sent to the repository.
| |
| | |
| <b>Versioned metadata:</b> Each file and directory has a set of properties (key-value pairs) associated with it. You can create and store any arbitrary key/value pairs you wish. Properties are versioned over time, just like file contents.
| |
| | |
| <b>Choice of network layers: </b> Subversion has an abstracted notion of repository access, making it easy for people to implement new network mechanisms. Subversion can plug into the Apache HTTP Server as an extension module. This gives Subversion a big advantage in stability and interoperability, and instant access to existing features provided by that server—authentication, authorization, wire compression, and so on. A more lightweight, standalone Subversion server process is also available. This server speaks a custom protocol which can be easily tunneled over SSH.
| |
| | |
| <b>Consistent data handling:</b> Subversion expresses file differences using a binary differencing algorithm, which works identically on both text (human-readable) and binary (human-unreadable) files. Both types of files are stored equally compressed in the repository, and differences are transmitted in both directions across the network.
| |
| | |
| <b>Efficient branching and tagging:</b> The cost of branching and tagging need not be proportional to the project size. Subversion creates branches and tags by simply copying the project, using a mechanism similar to a hard-link. Thus these operations take only a very small, constant amount of time.
| |
| | |
| <b>Hackability:</b> Subversion has no historical baggage; it is implemented as a collection of shared C libraries with well-defined APIs. This makes Subversion extremely maintainable and usable by other applications and languages.
| |
| | |
| ===<b>Git</b>===
| |
| | |
| In 2002, BitMover released a community licensed version of [http://en.wikipedia.org/wiki/BitKeeper BitKeeper], its proprietary VCS that allowed developers to use it free provided they did not participate in the development of a competing tool<sup>[10]</sup>. One of major drawbacks of the community versions of BitKeeper was that users were not allowed to see metadata and compare past versions. In April 2005, BitMover withdrew the community version of BitKeeper and the [http://en.wikipedia.org/wiki/Git_(software) Git] Project was launched. Git was aimed at becoming the Linux kernel's source configuration management software, and was eventually adopted by Linux developers.
| |
| | |
| The main characteristics of Git can be found [http://en.wikipedia.org/wiki/Git_(software)#Characteristics here]
| |
| | |
| ==<b>History of Commercial Version Control Systems</b>== | |
| | |
| ===<b>Polytron Version Control System (PVCS)</b>===
| |
| | |
| [http://en.wikipedia.org/wiki/PVCS PVCS] was originally published by [http://en.wikipedia.org/wiki/Polytron_%28software%29 Polytron] in 1985 and is currently sold by [http://en.wikipedia.org/wiki/Serena_Software Serena Software]. PVCS uses the locking mechanism for concurrency control by creating a parallel branch for the second commiter so that modifications to the same project can exist in
| |
| parallel.<sup>[10]</sup> This is unlike CVS and Subversion where the second commiter needs to first merge the changes via the update command and then resolve conflicts (when they exist) before actually committing.<sup>[13]</sup>
| |
| | |
| ===<b>ClearCase</b>===
| |
| | |
| [http://en.wikipedia.org/wiki/IBM_Rational_ClearCase ClearCase] was originally developed by Atria Software in 1992 on Unix and was written in C++. It was partly derived from [http://en.wikipedia.org/wiki/Hewlett-Packard HP] software. Atria Software merged with [http://en.wikipedia.org/wiki/Rational_Software Rational Software] which was acquired by [http://en.wikipedia.org/wiki/IBM IBM] in 2003
| |
| | |
| Clearcase mainly works on the concept of <i>Views</i>. A view is a version of the software that is specific to each developer. Each developer 'sees' the version of the project that is related to the view. Views can be defined by means of a Config spec. A config spec is set of rules that govern what version of each file has to be loaded into the view.
| |
| | |
| ClearCase repositories are called VOBs (Versioned Object Base). It has a proprietary network file system called [http://en.wikipedia.org/wiki/MultiVersion_File_System MVFS] (MultiVersion File System)<sup>[12]</sup> MVFS can be used to mount VOBs as a virtual file system through a dynamic view. Every developer in team has a dynamic view which resides on the network server. the local copy of the views that are created on developer machines are called sand-box views. Developers make changes to their sandbox views and merge the changes into the dynamic view.
| |
| | |
| ===<b>Visual SourceSafe</b>===
| |
| | |
| SourceSafe was developer by One Tree Software which was bought by [http://en.wikipedia.org/wiki/Microsoft Microsoft] in 1994.<sup>[14]</sup> Soon after acquiring One Tree, Microsoft discontinued all versions of SourceSafe except the Windows version. Microsft also made some architectural changes in the software which were not very well received by the users and Visual SourceSafe was gained the reputation of Visual SourceUnsafe.<sup>[14]</sup>
| |
| | |
| ===<b>MKS Integrity</b>===
| |
| | |
| MKS was released in 2001 by [http://en.wikipedia.org/wiki/MKS_Inc. MKS Inc.] MKS in based on a client server architecture and is available in both desktop and web client interfaces. MKS Integrity enables project teams to track all aspects of their work, such as work items, source control, reporting, and build management, in a single product.<sup>[15]</sup> MKS Integrity has plug-ins available for [http://en.wikipedia.org/wiki/Eclipse_%28software%29 Eclipse] and [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio]
| |
| | |
| == References ==
| |
| *[1]: [http://en.wikipedia.org/wiki/Revision_control Revision Control Wikipedia]
| |
| *[2]: [http://en.wikipedia.org/wiki/Concurrent_Versions_System Concurrent Version Systems(CVS)]
| |
| *[3]: http://www.ibm.com/developerworks/java/library/j-subversion/index.html#N1007B
| |
| *[4]: http://www.ericsink.com/scm/scm_branches.html
| |
| *[5]: http://www.tigris.org/nonav/scdocs/ddCVS_cvsglossary.html
| |
| *[6]: http://en.wikipedia.org/wiki/Source_Code_Control_System
| |
| *[7]: http://en.wikipedia.org/wiki/Revision_Control_System
| |
| *[8]: http://en.wikipedia.org/wiki/Concurrent_Versions_System
| |
| *[9]: http://svnbook.red-bean.com/en/1.1/ch01s02.html
| |
| *[10]: Ruparelia, Nayan B., <i>The History of Version Control</i>, Hewlett Packard Enterprise Services, ACM SIGSOFT Software Engineering Notes, January 2010 Volume 35 Number 1
| |
| *[11]: http://svnbook.red-bean.com/en/1.4/svn.intro.whatis.html
| |
| *[12]: http://en.wikipedia.org/wiki/IBM_Rational_ClearCase
| |
| *[13]: http://en.wikipedia.org/wiki/PVCS
| |
| *[14]: http://en.wikipedia.org/wiki/Microsoft_Visual_SourceSafe
| |
| *[15]: http://en.wikipedia.org/wiki/MKS_Integrity#Overview
| |
eval() [Computer Programming]
Introduction
The eval facility is one of the most powerful features of Ruby (as well as other dynamic languages).
Kernel.eval method will parse and execute an arbitrary string of legal Ruby source code.
To put it plainly, if your Ruby program can generate a string of valid Ruby code,
the Kernel.eval method can evaluate that code. The eval facility gives developers the ability to
modify the runtime behavior of program. Illustrate the practical advantages of Ruby's eval(...)
and compare it with similar mechanisms in other languages.
Origin
LISP The first actual implementation of
LISP was by Steve Russell. He realized that the Lisp eval function could be implemented in machine code.[3] The result was a working Lisp interpreter which could be used to run Lisp programs, or more properly, 'evaluate Lisp expressions.'
[[File:http://en.wikipedia.org/wiki/File:LISP_machine.jpg%7C]
Security risks
It may seem natural to perform eval() on user-supplied data, exposing the entire power of the underlying
programming language with a single statement. For example, on a web site, the programmer might allow the user to
enter an expression, and with trivial effort on the part of the programmer, the result of the expression is computed.
However, a moment's thought reveals the grave security risk posed by such an approach. The user could intentionally
or unintentionally delete files, corrupt files, transmit sensitive information, etc.
Context
Implementation
Dynamic Programming Languages
Lisp
Lisp is the second-oldest high-level programming language in common use
today (after FORTRAN). Invented in 1958 by John McCarthy at Massachusetts Institute of Technology, LISP was first actually implemented
in machine language by Steve Russell, who realized that by implementing the LISP eval() function in assembly language,
he could create a working LISP interpreter.
Perl
Ruby
trane = %q{"John Coltrane".length}
eval trane → 13
JavaScript
PHP
Python
ColdFusion
Static Programming Languages
Java
GroovyShell
Command Line interpreters
Unix
References
[1] Eval, Retrieved October, 2010.
[2] Eval, Retrieved October, 2010.
[3] Programming Ruby: The Pragmatic Programmer's Guide
