Revision Control Systems: Subversion ENGI 5895: Software Design

Andrew Vardy

Faculty of Engineering & Applied Science Memorial University of Newfoundland March 7, 2011

Revision Control Systems

A revision control system provides the following useful features: Provides a backup mechanism

Revision Control Systems

A revision control system provides the following useful features: Provides a backup mechanism Maintains a history of changes to your source code:

Revision Control Systems

A revision control system provides the following useful features: Provides a backup mechanism Maintains a history of changes to your source code:

Who made what changes, and why?

Revision Control Systems

A revision control system provides the following useful features: Provides a backup mechanism Maintains a history of changes to your source code:

Who made what changes, and why? Provides an organized strategy for working cooperatively

Available Revision Control Systems

1982: Revision Control System (RCS)

Available Revision Control Systems

1982: Revision Control System (RCS)

Focus on individual les

Available Revision Control Systems

1982: Revision Control System (RCS)

Focus on individual les 1990: Concurrent Versions System (CVS)

Available Revision Control Systems

1982: Revision Control System (RCS)

Focus on individual les 1990: Concurrent Versions System (CVS)

Track changes on sets of les

Available Revision Control Systems

1982: Revision Control System (RCS)

Focus on individual les 1990: Concurrent Versions System (CVS)

Track changes on sets of les 2000: Apache Subversion (svn)

Available Revision Control Systems

1982: Revision Control System (RCS)

Focus on individual les 1990: Concurrent Versions System (CVS)

Track changes on sets of les 2000: Apache Subversion (svn)

Successor to CVS (many improvements)

Available Revision Control Systems

1982: Revision Control System (RCS)

Focus on individual les 1990: Concurrent Versions System (CVS)

Track changes on sets of les 2000: Apache Subversion (svn)

Successor to CVS (many improvements) Repository is stored on a central server: Clients checkout local working copies

Available Revision Control Systems

1982: Revision Control System (RCS)

Focus on individual les 1990: Concurrent Versions System (CVS)

Track changes on sets of les 2000: Apache Subversion (svn)

Successor to CVS (many improvements) Repository is stored on a central server: Clients checkout local working copies Distributed revision control systems: Git, GNU arch, Mercurial, ...

Available Revision Control Systems

1982: Revision Control System (RCS)

Focus on individual les 1990: Concurrent Versions System (CVS)

Track changes on sets of les 2000: Apache Subversion (svn)

Successor to CVS (many improvements) Repository is stored on a central server: Clients checkout local working copies Distributed revision control systems: Git, GNU arch, Mercurial, ...

Peer-to-peer vs. client-server architecture

The Problem Imagine two developers both working on the same repository. We want to avoid the following scenario:

(Read this diagram in left-to-right, top-down order)

Copy-Modify-Merge Revision control systems like Subversion use the copy-modify-merge model. Clients maintain

working copies which are reections of

the repository. If two users make changes to the same le, the system can merge the two versions:

Copy-Modify-Merge Revision control systems like Subversion use the copy-modify-merge model. Clients maintain

working copies which are reections of

the repository. If two users make changes to the same le, the system can merge the two versions:

Copy-Modify-Merge Revision control systems like Subversion use the copy-modify-merge model. Clients maintain

working copies which are reections of

the repository. If two users make changes to the same le, the system can merge the two versions:

Harry is responsible for overseeing the merge step.

Subversion (svn)

Traditional usage via the command-line: e.g. svn checkout REPOSITORY PROJECT

Subversion (svn)

Traditional usage via the command-line: e.g. svn checkout REPOSITORY PROJECT Graphical clients: TortoiseSVN: Integration with Windows Explorer Subclipse: Integration with Eclipse

Creating a Repository

On Memorial's LabNet system (logged onto gareld.cs.mun.ca using ssh):

svnadmin create svnDemo

Creating a Repository

On Memorial's LabNet system (logged onto gareld.cs.mun.ca using ssh):

svnadmin create svnDemo This will create a directory that is readable only by you. If you want to make it completely publicand this is a big ifyou can change the permissions to allow everyone to read and write to this directory:

chmod -R o+rwx svnDemo

Local Access to the Repository

There are a number of ways of accessing your repository. All of them specify the repository via a URL: URL le://

Repository on local disk (i.e. client and server are one)

http://

Web access to a Subversion-aware web server

https://

Same as http:// but with encryption

svn://

Customized protocol over ssh (secure shell)

svn+ssh://

Same as svn:// but with encryption

Local Access to the Repository

There are a number of ways of accessing your repository. All of them specify the repository via a URL: URL le://

Repository on local disk (i.e. client and server are one)

http://

Web access to a Subversion-aware web server

https://

Same as http:// but with encryption

svn://

Customized protocol over ssh (secure shell)

svn+ssh://

Same as svn:// but with encryption

Warning: Getting any but the rst of these to work for multiple users will require root access to the server.

Import

Arrange the folders in your project into the following hierarchy: project

trunk directory1 directory2 ...

Import

Arrange the folders in your project into the following hierarchy: project

trunk directory1 directory2 ...

You place your code in a trunk directory so that down the road you can create branchesseparate versions of the project that deviate signicantly from the trunk.

On the client machine, go to the directory that contains your project directory (called demoProject here):

svn import demoProject REPOSITORY/demoProject -m Initial import

On the client machine, go to the directory that contains your project directory (called demoProject here):

svn import demoProject REPOSITORY/demoProject -m Initial import Where REPOSITORY is your repository's URL. For me it is:

svn+ssh://[email protected]/users/cs/faculty/av/svnDemo

On the client machine, go to the directory that contains your project directory (called demoProject here):

svn import demoProject REPOSITORY/demoProject -m Initial import Where REPOSITORY is your repository's URL. For me it is:

svn+ssh://[email protected]/users/cs/faculty/av/svnDemo

Important:

you should not continue to work on the current project

directory. It should now be backed up somewhere. You must checkout a working copy from the repository in order to continue.

Checkout

On your client, you can checkout a working copy of your repository as follows:

svn checkout REPOSITORY/demoProject

Checkout

On your client, you can checkout a working copy of your repository as follows:

svn checkout REPOSITORY/demoProject This copies the most recent version of the project (the HEAD version) to the local directory. It also creates hidden .svn directories to store information about the project.

Changing the Working Copy

You can make two kinds of changes to your working copy:

Changing the Working Copy

You can make two kinds of changes to your working copy: 1

File changes: Edits to existing les

2

Tree changes: Adding/deleting les and/or directories

Changing the Working Copy

You can make two kinds of changes to your working copy: 1

File changes: Edits to existing les

2

Tree changes: Adding/deleting les and/or directories

Make le changes by simply editing your les. However to make tree changes you should make these changes through subversion commands:

Changing the Working Copy

You can make two kinds of changes to your working copy: 1

File changes: Edits to existing les

2

Tree changes: Adding/deleting les and/or directories

Make le changes by simply editing your les. However to make tree changes you should make these changes through subversion commands: svn add FILE_OR_DIRECTORY svn delete FILE_OR_DIRECTORY svn copy FILE_OR_DIRECTORY svn rename FILE_OR_DIRECTORY svn mkdir NEW_DIRECTORY

Examing Your Changes

Run

svn status to show all of the le and tree changes you've

made since the last commit or checkout. It will report a single letter status code for each change:

Examing Your Changes

Run

svn status to show all of the le and tree changes you've

made since the last commit or checkout. It will report a single letter status code for each change:

? A C D M

scratch.c # file is not under version control stuff/loot/bloo.h # file is scheduled for addition stuff/loot/lump.c # file has conflicts stuff/fish.c # file is scheduled for deletion bar.c # the content in bar.c has local modifications

Examing Your Changes

Run

svn status to show all of the le and tree changes you've

made since the last commit or checkout. It will report a single letter status code for each change:

? A C D M

scratch.c # file is not under version control stuff/loot/bloo.h # file is scheduled for addition stuff/loot/lump.c # file has conflicts stuff/fish.c # file is scheduled for deletion bar.c # the content in bar.c has local modifications

Run

svn status -v for more verbose output, showing the status of

all items.

You can get a detailed view of the changes to a particular le by executing

svn di.

the le ducky.txt.

Shown below is the before and after versions of

You can get a detailed view of the changes to a particular le by executing

svn di.

Shown below is the before and after versions of

the le ducky.txt. Before

After

You can get a detailed view of the changes to a particular le by executing

svn di.

Shown below is the before and after versions of

the le ducky.txt. Before

Here is the output from svn di ducky.txt:

After

You can get a detailed view of the changes to a particular le by executing

svn di.

Shown below is the before and after versions of

the le ducky.txt. Before

Here is the output from svn di ducky.txt:

After

You can get a detailed view of the changes to a particular le by executing

svn di.

Shown below is the before and after versions of

the le ducky.txt. Before

After

Here is the output from svn di ducky.txt:

The dierences between les are shown in

unied di format.

Commit

Whether they are le changes or tree changes, none of your changes will be reected in the repository until you commit! To commit your changes to the repository:

svn commit -m Description of reason for changes

Commit

Whether they are le changes or tree changes, none of your changes will be reected in the repository until you commit! To commit your changes to the repository:

svn commit -m Description of reason for changes If you leave out the description, an editor will pop up so that a description can be applied.

Commit

Whether they are le changes or tree changes, none of your changes will be reected in the repository until you commit! To commit your changes to the repository:

svn commit -m Description of reason for changes If you leave out the description, an editor will pop up so that a description can be applied.

How often to commit:

Commit when there has been a discrete

set of changes that accomplishes some taskxing a bug or implementing a new feature.

Update Whenever you anticipate that the repository might have been updated by another developer, you should call update to download these changes into your working copy

svn update

Update Whenever you anticipate that the repository might have been updated by another developer, you should call update to download these changes into your working copy

svn update The user will be notied about any resulting changes to your repository. There are three possible results for updated les: Code U: There have been no local changes to the le. Changes from the repository are downloaded. Code G: There have been local changes, but they do not overlap with those from the repository. The changes are automatically

merged.

Conict: There are overlapping changes and the user is given several options

Example: Ernie and Bert A repository is created by Ernie, Bert, or even Oscar the System Adminstrator:

svnadmin create streetRepos

Example: Ernie and Bert A repository is created by Ernie, Bert, or even Oscar the System Adminstrator:

svnadmin create streetRepos The actual repository URL might be le:///home/oscar/streetRepos, but we will refer to it through the environment variable REPOS. Bert now imports some les he believes should be under revision control (he's like that):

Example: Ernie and Bert A repository is created by Ernie, Bert, or even Oscar the System Adminstrator:

svnadmin create streetRepos The actual repository URL might be le:///home/oscar/streetRepos, but we will refer to it through the environment variable REPOS. Bert now imports some les he believes should be under revision control (he's like that):

bert@tom:~$ svn import house $REPOS/house -m "Initial import Adding house/trunk Adding house/trunk/doc Adding house/trunk/doc/README.txt Committed revision 1.

Once the les are imported, Bert deletes his current house directory (after backing it up) and now checks out a version from the repository:

Once the les are imported, Bert deletes his current house directory (after backing it up) and now checks out a version from the repository:

bert@tom:~$ svn checkout $REPOS/house A house/trunk A house/trunk/doc A house/trunk/doc/README.txt Checked out revision 1.

Once the les are imported, Bert deletes his current house directory (after backing it up) and now checks out a version from the repository:

bert@tom:~$ svn checkout $REPOS/house A house/trunk A house/trunk/doc A house/trunk/doc/README.txt Checked out revision 1. He then moves into the house/trunk/doc directory and creates a le called pigeons.txt:

Once the les are imported, Bert deletes his current house directory (after backing it up) and now checks out a version from the repository:

bert@tom:~$ svn checkout $REPOS/house A house/trunk A house/trunk/doc A house/trunk/doc/README.txt Checked out revision 1. He then moves into the house/trunk/doc directory and creates a le called pigeons.txt:

Favourite pigeons: Mary Barry Gary

This le is not under revision control. So Bert adds it:

This le is not under revision control. So Bert adds it:

bert@tom:~/house/trunk/doc$ svn add pigeons.txt A pigeons.txt

This le is not under revision control. So Bert adds it:

bert@tom:~/house/trunk/doc$ svn add pigeons.txt A pigeons.txt Bert now tells Ernie about his new system and gives him a quick Subversion tutorial. Ernie goes ahead and checks out his own working copy.

This le is not under revision control. So Bert adds it:

bert@tom:~/house/trunk/doc$ svn add pigeons.txt A pigeons.txt Bert now tells Ernie about his new system and gives him a quick Subversion tutorial. Ernie goes ahead and checks out his own working copy.

ernie@tom:~$ svn checkout $REPOS/house A house/trunk A house/trunk/doc A house/trunk/doc/README.txt Checked out revision 1.

Ernie asks Bert about this list of favourite pigeons. Bert realizes that he's forgotten to do a commit.

Ernie asks Bert about this list of favourite pigeons. Bert realizes that he's forgotten to do a commit.

bert@tom:~/house/trunk/doc$ svn commit Adding doc/pigeons.txt Transmitting file data . Committed revision 2.

Ernie asks Bert about this list of favourite pigeons. Bert realizes that he's forgotten to do a commit.

bert@tom:~/house/trunk/doc$ svn commit Adding doc/pigeons.txt Transmitting file data . Committed revision 2. Bert tells ernie to do an update:

Ernie asks Bert about this list of favourite pigeons. Bert realizes that he's forgotten to do a commit.

bert@tom:~/house/trunk/doc$ svn commit Adding doc/pigeons.txt Transmitting file data . Committed revision 2. Bert tells ernie to do an update:

ernie@tom:~$ svn update house/ A house/trunk/doc/pigeons.txt Updated to revision 2.

Ernie moves into house/trunk/doc and creates his own le called ducky.txt.

Ernie moves into house/trunk/doc and creates his own le called ducky.txt.

I've lost Rubber Ducky! Possible locations: Bathroom Bedroom

Ernie moves into house/trunk/doc and creates his own le called ducky.txt.

I've lost Rubber Ducky! Possible locations: Bathroom Bedroom Ernie does an

svn add ducky.txt and svn commit.

does an update:

Now Bert

Ernie moves into house/trunk/doc and creates his own le called ducky.txt.

I've lost Rubber Ducky! Possible locations: Bathroom Bedroom Ernie does an

svn add ducky.txt and svn commit.

does an update:

bert@tom:~/house/trunk/doc$ svn update A ducky.txt Updated to revision 3.

Now Bert

Bert now decides to help Ernie by looking for Rubber Ducky. He searches the bathroom but doesn't nd it. Returning to his computer, he modies ducky.txt:

Bert now decides to help Ernie by looking for Rubber Ducky. He searches the bathroom but doesn't nd it. Returning to his computer, he modies ducky.txt:

I've lost Rubber Ducky! Possible locations: Bedroom Locations already searched: Bathroom Meanwhile, Ernie searched the bedroom and didn't nd it. He crosses Bedroom o the list but adds Outside as a possibility:

I've lost Rubber Ducky! Possible locations: Bathroom Outside

They both go to commit simultaneously. SVN enforces atomic commitsone will happen fully before the other starts. Bert gets in rst:

They both go to commit simultaneously. SVN enforces atomic commitsone will happen fully before the other starts. Bert gets in rst:

bert@tom:~/house/trunk/doc$ svn commit Sending doc/ducky.txt Transmitting file data . Committed revision 4. Now Ernie:

ernie@tom:~/house/trunk/doc$ svn commit Sending doc/ducky.txt svn: Commit failed (details follow): svn: File '/house/trunk/doc/ducky.txt' is out of date

So Ernie does an update:

So Ernie does an update:

ernie@tom:~/house/trunk/doc$ svn update Conflict discovered in 'ducky.txt'. Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options:

So Ernie does an update:

ernie@tom:~/house/trunk/doc$ svn update Conflict discovered in 'ducky.txt'. Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: He chooses (e) edit and then (r) for resolved:

I've lost Rubber Ducky! Possible locations: Outside Locations already searched: Bedroom Bathroom