Subversion

What is Version Control?

• Normally when we save things we loose previous changes.

• Lets se we have a file and has been edit many tings since its creation.

• We cannot track of the changes done.• Version control track changes and adds a

number to each changes called VERSION or REVISION.

• Here nothing is lost. Its saved and be be retrieved anytime.

What is Subversion?

• It’s a free version control software.

• In our case we user Tortoise SVN UI tool.

Terminology

• Repository

• Check out

• Working copy

• Commits or check-in

• Revert.

• Updates.

• Conflicts.

Repository

• Place where data is stored.

• The repository is a central database of every version of every file.

• Internally, they store deltas of each change which are not human editable.

Checkout

• To pull the data from repository to your local machine.

Working copy

• This is what comes out of the repository

• It’s just a normal directory on your local machine.

• All changes or edits are done here.

Commits or check-in

• Changes done in working copy remains locally until committed back to the repository or SVN.

• Check ins saves your local copies or local changes into repository for ever.

• Always add a log message while committing to track what changes were made in a particular commit.

• Each commit creates a new version in repository.

• I.e. new REVISION NUMBER.

Revert

• Removing the changes made locally and bringing back the file to the state as it was in repository.

• Lets say we did some modifications on a file. And in many cases we mess up with it.

• Now, we want to start from a fresh.

• Reverting a file and do it again.

Updates.

• Synch your local working copies with the changes done on the repository by others.

• Lets say some body modifies a file and have committed it in repository.

• Updating working copy will bring those changes to you and keep it in synch.

Conflicts

• Nobody will every want to see this!• Lets say more then one person is working on a

file.• Person A have done changes locally and

committed it back to repository.• Mean while, Person B also did similar change.• Now before committing when Person B updates

a local copy he gets conflicts.• Conflicts has to be resolved for your changes to

be committed back.

Important notes.

• Always update your working copies regularly.• If more people are working on it then update

daily or on hourly basis based on work.• Always add a log message while committing.• Update your local copy before starting working

on it and before committing.• Its better not to check in half completed things

which may break things for others.• Always see what files you are committing. Do

not commit things which are not required.