subversion on .unix

All Rights reserved - © IMT Solutions

http://www.imt.com.vn

23 Sep, [email protected]

Version Control with Subversion

All Rights reserved - © IMT Solutions 2

Key Achievements

1. Subversion

2. Some definitions

3. How Working Copies Track the Repository

4. Commands in Subversion

5. How to resolve “conflict”

6. Reference

7. Question & Answer


Subversion

- Subversion is a version control system.

- A version control system allows users to manage files, directories, and the changes made to them.

- Subversion can manage any sort of file collection (not only source code).


Subversion (cont)

- “Version Control” is meant to solve the following problems:+ Users editing the same file concurrently overwriting each other+ Keeping users sharing the same source code that is in constant

change in sync+ Keeping a running history of changes (and who did them)+ Is WONDERFUL for group work (and is an industry standard!)+ Also called “Source Control"+ Subversion aims to be a simple to use, secure, and safe way to do

Version Control


Some definitions

1. Repository – the place (can be server or location on hard drive) that the “master” files are stored. Managed by Subversion

- The repository is a centralized store for data:+ Stores data in form of a filesystem tree+ Provides read/write access to the stored data+ Remembers any modification made to it


2. Working copy

- Working Copy – a “checked out” code you make your changes in- Users edit their working copy locally.- Changes are then committed to the repository.- After a commit, all other users can access the changes by updating their working copies to the latest revision.

3. Revision numbers are global across the whole repository

Some definitions(cont)


Some definitions(cont)

4. Commit – applying a change to the code on the repository

5. Update – downloading and merging all changes from repository into your working copy

6. Changeset – refers to a “commit,” is a list of files touched during that commit. Every changeset is ordered starting from 1 to however many commits there have been

7. Conflict – When a user edits and commits a file while another user is editing the same lines. The second user can’t commit until he manually merges the conflicting lines.


How Working Copies Track the Repository

- The working copy is made up of two parts:

+ A local copy of the directory tree of a project

+ An administrative directory named .svn in each directory, storing version control information

- .svn is a hidden directory

- Information stored in .svn directories:+ For each file, Subversion stores:

* The working revision of the file* A timestamp of the last update of the file* Given this information, by talking to the repository, Subversion can

tell which of the following four states a working file is in:Unchanged and currentLocally changed, and currentUnchanged, and out of date


How Working Copies Track the Repository (cont)

- Unchanged, and out of date

+ The file has not been changed in the working directory, but it has been changed in the repository. The file should eventually be updated in order to make it current with the latest public revision.

* An svn commit of the file will do nothing,

* and an svn update of the file will fold the latest changes into your working copy.

- Locally changed, and out of date

+ The file has been changed both in the working directory and in the repository.

* An svn commit of the file will fail with an “out-of-date” error. The file should be updated first;

* an svn update command will attempt to merge the public changes with the local changes. If Subversion can't complete the merge in a plausible way automatically, it leaves it to the user to resolve the conflict.


How Working Copies Track the Repository (cont)

Locally unchanged

Locally changed

Current Commit –do nothingUpdate – do nothing

Commit –publish your changeUpdate – do nothing

Out of date(new version at repository)

Commit –do nothingUpdate – get the latest changes

Commit – “out of date” errorUpdate – attempt to merge(need to resolve the conflicts)


Commands in Subversion

1. svn checkout:

Ex:

- svn checkout http://node-name/repos/svn/trunk/parentPath/path

Checkout every file from the path and subdirectories specified below.

2. svn update:

Ex:

- svn update filename (Migrate all updates from Subversion repository to your local copy)

- svn update -r458 filename (a specified revision given by -r)

- svn update --ignore-externals ./ (Use --ignore-externals to avoid the slow processing of externals to a potentially slow distant internet server.)


Commands in Subversion(cont)

Second column: Modification of properties

* ' ' no modifications. Working copy is up to date.

* 'C' Conflicted

* 'M' Modified

* '*' Local file different than repository. A newer revision exists on the server. Update will result in merge or possible conflict.

Third column: Locks

o ' ' not locked

o 'L' locked

o 'S' switched to a branch

Show status of file changes in current directory and recursively in directories below.

First column:

* A: File to be added

* C: Conflicting changes

* D: File to be deleted

*G: File to be merged with updates from server.

* M: File has been modified

* R: File to be replaced

*X: Resource is external to repository (svn:externals)

* ?: File/directory not under version control

* !: File/directory missing

*~: Versioned item obstructed by some item of a different kind.

3. svn status:


Commands in Subversion(cont)

svn add filename

4. svn add:

Ex:

- svn add filename/directory

Add a file or directory to Subversion control.

5. svn delete:

Ex:

- svn delete filename/directory

6. svn lock filename -m "comment as to why its locked or by whom"

7. svn switch http://server/new-branch

8. svn commit filename: check-in (commit) local "working" file


Where RevisionNumber is:

HEAD: The latest revision in the repository.

BASE: The "pristine" revision of an item in a working copy. Matches checked out version before any modifications.

COMMITTED: The last revision in which an item changed before (or at) BASE.

PREV: The revision just before the last revision in which an item changed. (Technically, COMMITTED - 1.)


How to resolve “conflict”


How to resolve “conflict” (cont)

1. The Lock-Modify-Unlock Solution:

In this model, the repository allows only one person to change a file at a time.



2. The Copy-Modify-Merge Solution:

In this model, each user's client contacts the project repository and creates a personal working copy—a local reflection of the repository's files and directories.



* When Locking Is Necessary

While the lock-modify-unlock model is considered generally harmful to collaboration, sometimes locking is appropriate.

The copy-modify-merge model is based on the assumption that files are contextually mergeable—that is, that the majority of the files in the repository are line-based text files (such as program source code). But for files with binary formats, such as artwork or sound, it's often impossible to merge conflicting changes. In these situations, it really is necessary for users to take strict turns when changing the file. Without serialized access, somebody ends up wasting time on changes that are ultimately discarded.



* When conflict happen:- Three fulltext files starting with `tmp' are created; these files are the original three files that could not be merged together. It allows users to directly examine all three files, and even use 3rd-party merge tools (as an alternative to conflict markers.)- Subversion will not allow you to "accidentally" commit conflict markers. Subversion remembers that a file remains in conflict, and requires definite action from the user to undo this state before it will allow the item to be committed again.

* Solutions to resolve- Hand-merge the conflicted text- Copy one of the tmpfiles on top of your working file- Run svn revert to toss all of your changes

* Once resolved, you need to tell SVN that the conflict has been resolve- Run svn resolve- This deletes the tmp files


Reference

http://svnbook.red-bean.com/en/1.5/svn.basic.repository.html

1. http://svnbook.red-bean.com/en/1.5/svn.basic.repository.html


SVN Client

For those who are looking for a Free SVN client (GUI) that have nice interface in mac os x, you can try SvnX. SvnX is a free svn client with nice GUI interface. The GUI for this free svn client is quite user friendly


- Currently this free svn client support:

+ Repository Inspector :

+ Browse logs, revisions and directories in a single window.

+ svn checkout, svn export, svn import, svn switch, svn copy, svn mkdir and svn delete support.

+ Drag & drop between the repository browser and the Finder ! (both ways!).

+ FileMerge integration.

+ Disk cache for impressive speed.

- Working Copy Inspector :

+ Flat view / hierarchical view.

+ Items sorting/filtering/searching.

+ Operate svn actions on selected items.

+ svn move/copy via drag&drop in hierarchical view.

+ svn rename.

+ Save your favorite working copies in a panel.

SVN Client (cont)


SVN Client (cont)


Merge tool

- Diff

Graphically shows the changes between two files. Includes intra-line highlighting and full support for editing.

- Merge

Graphically shows the changes between 3 files. Allows automatic merging (when safe to do so) and full control over editing the resulting file.

- Folder Diff

Performs a side-by-side comparison of 2 folders, showing which files are only present in one file or the other, as well as file pairs which are identical or different.


Merge tool (cont)


Question & Answer

subversion on .unix

Documents

working file

subversion repository

subversion subversion

repository svn

working copy

file willdo

status of file changes

working revision