Version Control Systems: SVN and GIT. How do VCS support SW development teams?

Transcription

1 Version Control Systems: SVN and GIT How do VCS support SW development teams? CS 435/535 The College of William and Mary

2 Agile manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. What is needed? Chapter 3 Agile software development 2

3 Plan-driven and agile specification Plan-based development Requirements engineering Requirements specification Design and implementation Requirements change requests Agile development Requirements engineering Design and implementation Chapter 3 Agile software development 3

4 The extreme programming release cycle Select user stories for this release Break down stories to tasks Plan release Evaluate system Release software Develop/integrate/ test software Chapter 3 Agile software development 4

5 The Scrum process Outline planning and architectural design Assess Review Select Develop Project closure Sprint cycle Chapter 3 Agile software development 5

6 Scrum benefits The product is broken down into a set of manageable and understandable chunks. Unstable requirements do not hold up progress. The whole team have visibility of everything and consequently team communication is improved. Customers see on-time delivery of increments and gain feedback on how the product works. Trust between customers and developers is established and a positive culture is created in which everyone expects the project to succeed. Chapter 3 Agile software development 6

7 Software Engineering is Team Work Enabling technology for productivity must support parallelization must support communication Remember SVN from CS 301? What does it support? Documentation as preserved communication must support management of tasks & people What needs to be done? When? By whom? What has been done? By whom?

8 Version Control Systems Centralized CVS 1990 SVN Distributed Bitkeeper Git 2005 Bazaar 2005 Mercurial *More VCS at

9 Version Control Systems Version control system supports concurrent software development on shared code base keeps track of changes, integrates versions / recognizes conflicts, allows for recovery, documentation of changes Common set up: IDE as front end, VCS as back end (shared, persistent storage)

10 Subclipse: eclipse plugin for SVN

11 Subclipse: eclipse plugin for SVN

12 EGit: eclipse plugin for Git

13 EGit: eclipse plugin for Git

14 EGit: eclipse plugin for Git

15 Centralized vs Distributed Version Control Systems Centralized Architecture: Image from

16 Distributed Version Control Systems Distributed Architecture: Image from

17 Centralized vs Distributed VCS What are the pros & cons? Software engineering is much about scalability: Project size in # of developers about 10 up to 100 more than 100

18 Workflows: Centralized Small teams Typical workflow for SVN and CVS Repository is a single point of failure Image from

19 Workflows: Integration - Manager Supported by CVS and SVN using branches More easily supported by distributed version control systems Image from

20 Workflows: Director and Lieutenants Supported by CVS and SVN using branches More easily supported by distributed version control systems Generally used by huge projects (e.g., Linux kernel) Image from

21 Versions, Revisions, and Snapshots CVS: each commit generates a new version for each file modified SVN: each commit generates new state of the file system tree, called a revision GIT: same than SVN; keeps a snapshot of the system but instead of saving the deltas it saves the changed files and references to the unchanged ones

22 our project in Git, it basically takes a picture of what all your files look like at moment and stores a reference to that snapshot. To be efficient, if files have not ged, Git doesn t store the file again just a link to the previous identical file it has ady stored. Git thinks about its data more like Figure 1.5. Git follows idea of a file system with snapshots Figure 1.5: Git stores data as snapshots of the project over time. This is an important distinction between Git and nearly all other VCSs. It makes reconsider almost every aspect of version control that most other systems copied the previous generation. This makes Git more like a mini filesystem with some edibly powerful tools built on top of it, rather than simply a VCS. We ll explore

23 TER 1 GETTING STARTED n) think of the information they keep as a set of files and the changes made to each SVN et al: over time, as illustrated in Figure 1.4. re 1.4: Other systems tend to store data as changes to a base version of each file. Git doesn t think of or store its data this way. Instead, Git thinks of its data more a set of snapshots of a mini filesystem. Every time you commit, or save the state our project in Git, it basically takes a picture of what all your files look like at moment and stores a reference to that snapshot. To be efficient, if files have not

24 Versions, Revisions, and Snapshots SVN and Git use global revision numbers Image from

25 Operations and states (CVS and SVN) Workspace Repository Checkout Commit

26 Operations and states (Git) Workspace Staging area (Index) Repository Checkout Stage Commit

27 Operations and commands - Git

28 Workflows: Integration - Manager Supported by CVS and SVN using branches More easily supported by distributed version control systems Image from

29 Operations and commands Operation CVS SVN Git Init init create init Import import import commit Checkout checkout checkout clone Checkout branch checkout checkout checkout Commit/Checkin commit commit commit, push Update update update fetch, pull

30 Operations and commands - SVN+Eclipse

31 Operations and commands - SVN+Eclipse

32 Operations and commands - SVN+Eclipse

33 Operations and commands - SVN+Eclipse

34 Operations and commands - SVN+Eclipse

35 Operations and commands - SVN+Eclipse

36 Workflows and issues Workflow: 1) get code base 2) make changes 3) deliver changes Issue: Read/write access to remote repository Protected: User authentication, registration, account/pw necessary in communication, IDE stores/uses account/pw for convenience Issue: Conflicts Changes do not fit together, automatically recognized at some level of granularity (same file, same method, same line of code) Automatically recognized, manually fixed Issue: Documentation / Communication What changed, how trustworthy are the changes, what needs to be changed as an effect Finding the right historical version to undo some changes

37 Tagging Useful for marking specific points in history, in particular: Releases Two types: lightweight vs annotated annotated: full objects in Git DB, check summed, contain tagger CHAPTER 2 GIT BASICS name, , date, tagging message, can be signed & verified $ git tag -a v1.4 -m my version 1.4 $ git show v1.4 tag v1.4 Tagger: Scott Chacon <schacon@ge .com> Date: Mon Feb 9 14:45: my version 1.4 commit b64cf874c3557a0f3547bd83b3ff6 Merge: 4a447f7... a6b4c97... Author: Scott Chacon <schacon@ge .com> Date: Sun Feb 8 19:02: Merge branch experiment That shows the tagger information, the date the commit was ta tation message before showing the commit information.

38 Branching CVS: simple process for creating branches on the repository SVN: has no internal concept of a branch; branches are managed as copies of a directory. GIT: very simple process for creating local and remote branches

39 Merging Branch Branch 4 Merge

40 Branching in SVN

41 Branching in SVN

42 Branching in SVN

43 Branching in SVN

44 Branching in SVN

45 Branching in SVN

46 Branching in SVN

47 Branching in Git Branches are lightweight movable pointers to commits The default branch is the MASTER (trunk) Images from

48 Branching in Git Initial layout for three commits New branch pointer (iss53) Images from

49 Branching in Git New commit on the branch Hot fix branch on master Images from

50 Merging in Git Images from

51 Merging in Git Images from

52 Branching & Merging in Git Key concept, well supported Local workflow people create branches for any issue / task /assignment they deal with, sometimes called topic branch optional: rebase instead of merge to obtain a linear history only recommended for local repository Remote repository: merge with master For integration manager with blessed repository: pull request

53 What is missing so far? Documentation of problems, bug reports Work assignments, who does what and till when Issue tracking

54 Github Issue Tracker Filter by open and closed issues, assignees, labels, and milestones. Sort by issue age, number of comments, and update time. Milestones / labels

55 Github Workflow: Code review & Pull request Pull request starts conversation around proposed changes. Additional commits may add to branch before merging into master. Pull Request = Code + Issue + Code Comments

56 Software Engineering is Team Work Enabling technology for productivity must support parallelization must support communication Documentation as preserved communication must support management of tasks & people What needs to be done? When? By whom? What has been done? By whom?