CSCB07 Software Design Version Control

CSCB07 — Software Design

Version Control

Anya Tafliovich

Problem I: Working Solo

• How do you keep track of changes to your program?

• Option 1: Don’t bother

• Hope you get it right the first time

• Hope you can remember what changes you made if you didn’t • (You probably won’t get it right)

• (Or remember)

Problem I: Working Solo

• Option 2: Periodically save “backups”

• Save snapshots of your program in another directory or under a different name

• E.g. Main.1.java, Main.2.java • Or save it in a directory by date

• Problems:

• Totally ad hoc

• Only the programmer knows how to interpret the names • Hard to pick a version to go back to

• Prone to error • No tools to help you

Problem II: Working in a Team

• How do you coordinate who has the authority to change a file?

• Option 1: Worry about it after the fact • “Hey, why is this broken?”

• “My changes got overwritten!”

• “You weren’t supposed to change that file!”

• Option 2: Exchange email, phone calls, etc.

Problem III: Moving around

• After a day of work in the lab, you want to go home and do some work at home in the evening.

• How do you know which files to copy to your home machine? • Copy everything

• potentially slow

• might overwrite something you did at home, but forgot to copy from home to school

• Try to remember what changed • highly likely to get it wrong • Work in a cloud.

Version Control

• Two flavours: centralized and distributed.

• In this course, we study the centralized flavour.

Centralized Version Control

• Keep code in a central location (“repository”)

• This is the “master copy”

• Never directly modify this directory!

• Create a local copy of the repository in your account at school, on your machine at home, on your laptop...

• When the local copy changes, “commit” the changes to the repository.

Version Control — tracking changes when working solo

• When you get something working, or you want to try

something making sure you can revert to the current version, or for whatever other reason, commit the changes

• Tools allow you to revert to a previous version

• Write good log messages so that you don’t have to remember what changed in each version

Version Control

• In this course we will use subversion, or svn

• There are other version control systems out there: CVS, Perforce, Microsoft Visual SorceSafe, etc.

• and newer, better, more complex ones, such as Mercurial and Git (which some of you will see in CSC C01)

• I bet the first company you end up working for uses a version control system.

subversion — some common commands

• svn checkout [url] Get initial copy

• Do this anywhere to get a local copy of a repository.

• svn add [filenames] Add new files

• notifies Subversion that you want it to track the new files • add will almost always be followed by a commit because add

doesn’t actually modify the repository

subversion — some common commands

• svn update [filenames] Synchronize with repository • Copies stuff from the master repository to your local copy • Any commits made by another person or commits done by you

from another local copy will be updated in your local copy. • Does not change the repository

• Watch the messages closely.

• svn commit [filenames] Commit local changes • Copy changes to the repository

• Will only be allowed if the local copy is up to date • Creates a new version

subversion — some common commands

• svn remove [filenames] Remove files from repository • Need to commit, just like for add, to make changes to the

repository

• svn diff [filenames] Show diffs between local copy&repo • Handy to see what changed between versions

• svn log [filenames] Show history of files

• Shows log message, timestamps and who made the revisions

• svn tree [filenames] Show history of files • Shows log message, timestamps and who made the revisions

version control — managing concurrency

• What if two (or more) people want to edit the same file at the same time?

• Option 1: prevent it

• Only allow one writeable copy of the file • Pessimistic concurrency

• e.g., Microsoft Visual SourceSafe

• Option 2: patch up afterward • Optimistic concurrency

• ”Easier to get forgiveness than permission” • e.g., Subversion, CVS, Perforce

version control — optimistic concurrency

Consider the following sequence of events:

• Alice and Bob share files A.txt and B.txt in the directory D using svn.

• Suppose Alice creates a file C.txt and modifies the file A.txt. She also creates a file D.txt, but she does not intend to share it.

• Also suppose Bob modifies the file B.txt.

• Provide a sequence of svn commands that will ensure that both Alice and Bob have the most recent versions of the files that are intended for sharing.

version control — optimistic concurrency

• Initially, Alice and Bob checked out the fresh copies of the repository.

• A file/ directory is tracked: svn monitors this file, examines it for changes, includes in the next commit, etc. To become tracked, a file needs to be added.

version control — optimistic concurrency

version control — optimistic concurrency

• What if Bob also modified file A.txt?

• Let us look at two different scenarios:

1. svn is able to merge without help from the user

2. conflict: (oh, no!) svn needs the user to resolve the conflict

• What if Bob also creates a file named C.txt?

version control — optimistic concurrency

version control — storage scheme

• Storing entire copy of a file on every change would require an enormous amount of disk space and would make

synchronization slow.

• Version control systems store incremental differences.

• The incremental differences allow the system to reconstruct previous versions.

so where’s my repo?

• You need to know the URL so you can do svn checkout [url]

• The repositories for this course all look like:

http://markus.utsc.utoronto.ca/svn/cscb07f15/repo-ID

• More instructions on what to check out and in when you need them!