�ݺ�ߣ

http://www.imt.com.vn 23 Sep, 2010 [email_address] Version Control with Subversion

Key Achievements 1. Subversion 2. Some definitions 3. How Working Copies Track the Repository 4. Commands in Subversion 5. How to resolve “c�ǲԴڱ��” 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 current Locally changed, and current Unchanged, 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 nothing Update – do nothing Commit –publish your change Update – do nothing Out of date (new version at repository) Commit –do nothing Update – get the latest changes Commit – “out of date” error Update – 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 “c�ǲԴڱ��”

How to resolve “c�ǲԴڱ��” (cont) 1. The Lock-Modify-Unlock Solution: In this model, the repository allows only one person to change a file at a time.

How to resolve “c�ǲԴڱ��” (cont) 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.

How to resolve “c�ǲԴڱ��” (cont)

How to resolve “c�ǲԴڱ��” (cont) * 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.

How to resolve “c�ǲԴڱ��” (cont) * 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)

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.

�ݺ�ߣ

Subversion on .Unix

More Related Content

Subversion on .Unix