DOC PREVIEW
CU-Boulder CSCI 5828 - Version Control

This preview shows page 1-2-3-24-25-26-27-48-49-50 out of 50 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 50 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 50 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 50 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 50 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 50 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 50 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 50 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 50 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 50 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 50 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 50 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

© University of Colorado, 2009Version ControlKenneth M. AndersonUniversity of Colorado, BoulderCSCI 5828 — Lecture 13 — 02/24/20091GoalsReview material from Chapter 6 of Pilone & MilesVersion Control & Configuration ManagementWorking “Without a Net”Repository ManagementInit, Add, Branch, Merge2Without a Net (I)Doing software development without configuration management is “working without a net”Configuration management refers to both a process and a technologyThe process encourages developers to work in such a way that changes to code are trackedchanges become “first class objects” that can be named, tracked, discussed and manipulatedThe technology is any system that provides features to enable this process3Without a Net (II)If you don’t use configuration management thenyou are not keeping track of changesyou won’t know when features were addedyou won’t know when bugs were introduced or fixedyou won’t be able to go back to old versions of your softwareYou would be “living in the now” with the codeThere is only one version of the system: this oneYou would have no safety net4Developer 1Developer 2Demo MachineAAAWithout a Net (III)5Two developers need to modify the same file for the task they are working onDeveloper 1Developer 2Demo MachineAAAWithout a Net (IV)6They both download the file from the demo machine, creating two working copies.working copyDeveloper 1Developer 2Demo MachineAA2A1Without a Net (V)7They both edit their copies and test the new functionality.A1A2Developer 1Developer 2Demo MachineAA2A1Without a Net (VI)8Developer 1 finishes first and uploads his copy to the demo machine.A1A2Developer 1Developer 2A2A1Without a Net (VII)9Developer 2 finishes second and uploads his copy to the demo machine.Demo MachineAA1A2Without a Net (VIII)10This is known as “last check in wins”At best, developer 1’s work is simply “gone” when the demo is run; At worst, developer 1 checked in other changes, that cause developer 2’s work to crash when the demo is run.Demo MachineAA1A2Not Acceptable11This type of uncertainty and instability is simply not acceptable in production software environmentsThat’s where configuration management comes inThe book uses the term “version control”But in the literature, “version control” is “versioning” applied to a single file while “configuration management” is “versioning” applied to collections of files12123452.1First draft of code, buggyFix some bugs, release v. 1.0Begin adding spellcheck feature spellcheck feature complete,may have bugschanges merged, more bugsfixed, release v. 2.0Another bug fix,release v. 1.1Versioning13Particular versions of files are included in...... different versions of a configurationFile A File B Configuration Z123 45123 45v. 0.1v. 1.0v. 1.21 13 25 4Configuration ManagementDeveloper 1Developer 2RepositoryAAAWith a Net (I)14Two developers need to modify the same file for separate tasksDemo MachineDeveloper 1Developer 2RepositoryAAAWith a Net (II)15They check the file out into their own working copiesDemo MachineDeveloper 1Developer 2RepositoryAWith a Net (III)16They modify their copies.Demo MachineA1A1A2A2Developer 1Developer 2RepositoryAWith a Net (IV)17Developer 1 finishes first.Demo MachineA1A1A2A2Developer 1Developer 2RepositoryAWith a Net (V)18Developer 2 finishes and tries to check in, but...Demo MachineA1A1A2A2Developer 1Developer 2RepositoryAWith a Net (VI)19the change is rejected, because it conflicts with A1Demo MachineA1A1A2A2Developer 1Developer 2RepositoryAWith a Net (VI)19the change is rejected, because it conflicts with A1Demo MachineA1A1A2A2This is known as “first check-in wins”!Developer 1Developer 2RepositoryAWith a Net (VII)20What is sent back is an amalgam of A1 and A2’s changesDemo MachineA1A1A2A1/A2Developer 1Developer 2RepositoryAWith a Net (VII)20What is sent back is an amalgam of A1 and A2’s changesDemo MachineA1A1A2A1/A2The file will not be syntactically correct and will not compile!Developer 1Developer 2RepositoryAWith a Net (VII)21It is up to Developer 2 to merge the changes correctly!Demo MachineA1A1A3A3Developer 1Developer 2RepositoryAWith a Net (VII)22He tells the repository the conflict has been resolved and checks the file in againDemo MachineA1A1A3A3A3A3Developer 1Developer 2RepositoryAWith a Net (VII)23Developer 1 can now update his local copy and check the changes on his machineDemo MachineA1A1A3A3A3A3Developer 1Developer 2RepositoryAWith a Net (VII)24When they are both satisfied, the system can be deployed to the demo machine and a successful demo occurs!Demo MachineA1A1A3A3A3A3Why Multiple Copies?25Old versioning systems (RCS) did not allow multiple developers to edit a single file at a same timeOnly one dev. could “lock” the file at a timeWhat changed?The assumption that conflicts occur a lotdata showed they don’t happen very often!When two developers edit the same file at the same time, they often make changes to different parts of the file; such changes can easily be merged A1 A2+A3=Tags, Branches, and Trunks, Oh My!26Configuration management systems can handle the basics of checking out the latest version of a system, making changes, and checking the changes back inThese changes are committed to what is typically called “the trunk” or main line of developmentgit calls it the “master” branchBut configuration management systems can do much more than handle changes to the version of a system that is under active developmentand that’s where tags and branches come inScenario (I)In the book, a development team has released version 1.0 of a system and has moved on to work on version 2.0they make quite a bit of progress when their customer reports a significant bug with version 1.0None of the developers have version 1.0 available on their machines and none of them can remember what version of the repository corresponded to “release 1.0”This highlights the need for good “commit messages”when you are checking in changes be very explicit about what it is you have done; you may need that information later2728123452.1First draft of code, buggyFix some bugs, release v. 1.0Begin adding spellcheck feature spellcheck feature complete,may have bugschanges merged, more bugsfixed, release v. 2.0Another bug fix,release v. 1.1Remember this diagram? The numbers in boxes are repository versions; the text in bold represent tags29Scenario (II)To fix the bug found in version 1.0 of their system, the developerslook at


View Full Document

CU-Boulder CSCI 5828 - Version Control

Documents in this Course
Drupal

Drupal

31 pages

Deadlock

Deadlock

23 pages

Deadlock

Deadlock

23 pages

Deadlock

Deadlock

22 pages

Load more
Download Version Control
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Version Control and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Version Control 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?