Formal Specification of the Subversion Version Control System

Formal Specification of the Subversion Version Control System in Z Zhongbo Huang (Jerry) 41184963 Supervisor: Annabelle Mc. Iver 1

Workshop Presentation Outline 1. Introduction -- Subversion n 2. Formal Specification --Z notation n 3. Case Study -- Case scenario n 4. Outcome of Project n 5. Conclusion and Limitation n ITEC 810 Workshop Presentation 2

1. Introduction --VCS n Version Control System ( Revision Control System) ¨ ¨ n n Version Tracking Coordinating Teams Every change made to the source is tracked, along with who made the change, why they made it, and references to problems fixed, or enhancements introduced, by the change. an excellent way to combat the problem of sharing files between workers. ITEC 810 Workshop Presentation 3

1. Introduction--Subversion Control system: a centralized system for sharing information. Allow many users to share but work independently on the same document. Share Merge The repository remember every change to every file and directory tree itself. It will also merge users files to produce a single merged copy recording all their modifications. The key feature operation: Update Operation Commit Operation ITEC 810 Workshop Presentation 4

2. Formal specification – Z notation n n Formal specification is the use of mathematical principles to describe precisely the desired behavior of computer systems. Z notation ¨ Base on simple set theory, predicate logic, relation and function. ¨ Specify the requirements or behavior of systems. ¨ Analyze that behavior via proof, animation, test generation ITEC 810 Workshop Presentation 5

2. Z notation - example SVNFILE : String n f, f ’ : SVNFILE n af ? , bf ! : SVNFILE n SVNFILE: File. Name x File. No n Z notation ITEC 810 Workshop Presentation 6

2. Z notation- Schema example Schema Name f represent before operation, f’ represent after operation. Declaration By convention names in the declarations ending in ‘? ’ are input and names ending in ‘!’ are outputs. Read operation doesn’t change file Predicate ITEC 810 41184963 fna! and fno! as the output equal to the first and second pair set of f’ 7

3. Case Study – Case Scenario n Alice and her collaborator, Bob, are working together on a small project (recipe), and using Subversion repository to share their work. Repository Alic e Bob Figure. A typical Subversion system share with Alice and Bob ITEC 810 Workshop Presentation 8

repository/ conf/ dav/ recipe/ db/ A collection of database files list. txt format hooks/ Create a recipe project in repository locks/ README. txt Alice’s working copy of recipe Firgure. The repository’s file system. ITEC 810 Workshop Presentation Alice and Bob’s working copy get from repository Bob’s working copy of recipe 9

Repository R 0 R 1 Milk 1 1 R 2 Milk Egg 2 3 R 3 Milk Juice R 4 Milk Soup 9 4 5 6 8 7 Alice Bob Figure. Revision Number Change in Recipe Repository ITEC 810 Workshop Presentation 10

3. Case Scenario – Update and Commit Operation repository/ recipe/ milk list. txt Alice’s working copy of recipe Bob’s working copy of recipe list. txt Case Scenario 1 . SVN Case Scenario 2 list. txt . SVN R 0 R 0 R 1 R 1 + milk Firgure 6. Case Scenario 2 ITEC 810 Workshop Presentation 11

repository/ recipe/ milk juice soup list. txt Alice’s working copy of recipe Bob’s working copy of recipe Case Scenario 1: commit list. txt . SVN Case Scenario 2: update list. txt . SVN/ R 0 R 1 + milk R 2 Case Scenario 4：update R 2 R 1 + milk Case Scenario 3: Commit + milk R 2 + egg R 3 R 1 Case Scenario 5: commit R 1 + milk R 3 + juice + milk R 3 Case Scenario 7: update R 4 + juice R 4 R 1 R 3 Case Scenario 9: update + milk R 4 R 1 + milk R 3 + juice + soup ITEC 810 Workshop Presentation Case Scenario 8: commit R 4 + milk + juice + soup 12

4. Outcome of Project Report detailing the enough specification of the key of features of Subversion using Z language, together with a commentary on the design n The goal of this project was to understand clarify Subversion’s behavior and what user can expect when he/her uses it. n ITEC 810 Workshop Presentation 13

4. Outcome -- Update Operation af, af’ represent Alice working copy from project repository rf? as input from project repository Alice’s working copy update to project repository the output f! and arn! represent the latest of File and SVNRevision. No in the SVNFile repository. ITEC 810 Workshop Presentation 14

4. Outcome – Commit Operation rf, af represent the state before the operation. rf’, af’ represent the state after the operation. af? as input from project repository Bob’s working copy commit to project repository This line notation address the revision number in rf’ and bf’ increment after commit operation successfully. ITEC 810 Workshop Presentation 15

5. Conclusion and Limitation Conclusion n Lead to a well-though-out, well-structured program Provides an unambiguous statement of intent Act as documentation for the finished program, helping those who have to maintain and update the program in the future. Limitation n n Do not include all the details involved Some formal specification in this project may not be carefully considered or even wrong explanation because of limitation of personal capability and scheduled time. ITEC 810 Workshop Presentation 16

The End of Presentation Question ? ITEC 810 Workshop Presentation 17