Version Control withSubversion              Kent Wang              Sep 27, 2011
Sometimes there’s a single right way todo things; Sometimes there are many
Agenda• Overview• Fundamental Concepts• Basic Usage• Advanced Topics• Branching and Merging• Appendix: Bubble-Up Method
Overview
What is Subversion?• Version control system (VCS)• Centralized• Free & Open Source (Apache License)
History
History• Early 2000, began in CollabNet, Inc.• May 2000, detailed design began• Aug 31, 2001 , “Self-hosting”• Early 2010,...
Architecture
command-line client app                        GUI client apps                                                            ...
Fundamental Concepts
Version Control Basics                              Repository• The Repository• The Working Copy                     Clien...
Version Control Basics• Versioning Models - The problem of file sharing - The lock-modify-unlock solution - The copy-modify...
The problem of sharing
Lock-modify-unlock
Copy-modify-merge
Copy-modify-merge
Subversion Way• Subversion Repositories• Addressing the Repository• Revisions
Revisions0
Revisions0   1        2      3
Subversion Way• Working copies - How the working copy works - Disposing of a Working Copy - Administrative directory - Mix...
Subversion Way• Working copies - How the working copy works                  at e! - Disposing of a Working Copy re sep   ...
Basic Usage
Help!• svn help• svn help subcommand
Importing • Working copy not required • Files are immediately committed to the     repository • Original local directory n...
Create a working copy • Create a working copy on local machine • Every directory in a working copy contains    an .svn sub...
Basic Work Cycle• Update your working copy• Make your changes• Review your changes• Fix your mistakes• Resolve any conflict...
Update working copy • Update to specified revision with -r • Commit new changes to out-of-date files     and directories is ...
Make your change• File changes - Make changes using what ever tools - Svn automatically detects file changes• Tree changes ...
Review Your Changes• Subcommand: status diff revert• Without Network
Review Your Changes• Subcommand: status diff revert• Without Network• Subversion keeping private caches of  pristine versi...
Review Your Changes• Overview of your changes with svn status• --show-updates(-u) --verbose(-v) --no-  ignore
Review Your Changes• Examine the detail of changes with svn diff• --diff-cmd
Fix Your Mistakes• Undoing your work with svn revert• Can undo any scheduled operation
Resolve Any Conflicts
Resolve Any Conflicts• View differences interactively• Resolving conflict differences interactively
Resolve Any Conflicts• Postponing conflict resolution• file.mine file.rOLDREV file.rNEWREV
Resolve Any Conflicts• Resolve conflicts with svn resolve• Removes three temporary files• Accepts the version of the file that...
Commit Your Changes• Commit changes with svn commit• --message(-m) --file(-F)• SVN_EDITOR
Examining History• svn log• svn diff• svn cat• svn list• svn update --revision (-r)
SVN Changing Steps• Logs intentions in a private “to-do list”• Performs those action to affect the desired  change, holdin...
Clean Up• Recover from interruption with svn cleanup• Searches working copy• Runs any leftover to-do items• Removing worki...
Localization• Notices the value of LC_MESSAGES  variable and attempts to print messages in  the specified language• Locale ...
Localization• Notices the value of LC_MESSAGES  variable and attempts to print messages in  the specified language• Locale ...
Advanced Topics
Revision Tricks• Revision Keywords - HEAD - BASE - COMMITTED - PREV• Revision Dates (-r {2011-09-30})
Peg Revisions
Complexity
Complexity1    dream.c
Complexity1             2    dream.c       dream.c
Complexity   1                2             3          dream.c       dream.c        dream.c$svn log dream.c # what do you ...
Peg and Operative• Peg revisions• Operative revisions $svn command -r OPERATIVE-REV item@PEG-REV
Peg Revisions• A path and a peg revision can identify to a  specific line of history• Peg revisions are specified using at s...
Operative Revisions• Specified by --revision (-r) option• Subversion performs the requested  operation using the operative ...
Properties• Versioned metadata on versioned files and  directories• Property names contain only ASCII  characters• Property...
Commands• svn proplist• svn propset• svn propedit• svn propget• svn propdel
Automatic Setting• Subversion tries to setting some common  file properties automatically when adding  and importing files• ...
Reserved Properties• svn:mime-type• svn:executable• svn:eol-style• svn:ignore
Sparse Directory• By default, operations on directories act in  a recursive manner• This feature allows you to easily chec...
Sparse Directory• Using --depth option - --depth empty - --depth files - --depth immediates - --depth infinity
Sparse Directory• Using --depth option - --depth empty - --depth files - --depth immediates - --depth infinity$ svn checkout...
Locking• Copy-modify-merge models lives and dies   on its data merging algorithm• Creating lock with svn lock• Lock token ...
Breaking and Stealing• Breaking Locks - svn unlock --force• Stealing Locks - svn lock --force• svn status -u
Changelists• Working at multiple changes• Best to committed as several small logical  units• Need to keep logical changes ...
Changelists• Allows you to create changelists by applying  labels to files you want to be associated  with the change list•...
Changelists• Allows you to create changelists by applying   labels to files you want to be associated   with the change lis...
Changelist
Branching and Merging
Repository Layout
Repository Layouttrunk   branches   tags
What’s a Branch• A line of development that exists  independently of another line• Shares a common history if look far eno...
Creating a Branch
Creating a Branch$ svn copy http://svn.example.com/repo/trunk        http://svn.example.com/repo/branches/my-branch       ...
Creating a Branch• Subversion has no internal concept of a  branch• Subversion’s branches exist as normal  filesystem direc...
Keeping Branch in Snyc • It’s very easy to drift too far apart. • May be near-impossible to merge back into     the trunk ...
Reintegrating a Branch • Bring branch in sync with trunk first • Make sure trunk working copy do not have     any local edi...
Mergeinfo and Previews• Use svn mergeinfo to see changesets has  absorbed and eligible to receive• Using svn merge --dry-r...
Undoing Change • Roll back a change that has already been     committed • You can use svn merge to “undo” the     change i...
Resurrect Deleted Item• Information is never lost in VCS• Delete a file just means it gone from the  HEAD revision, still e...
Resurrect Deleted Item • Define exactly which item you’re trying to     resurrect (By path and peg revision) • Two choices ...
Tags • A “snapshot” of a project in time • Nobody commits to it • svn copy comes to the rescue$ svn copy http://svn.exampl...
Branching Patterns• Release Branches• Feature Branches
Feature Branching
Feature Branching
This could be heaven
Or this could be hell
Branches and tags are cheap
Appendix:Bubble-Up Method
Modify a File          1                     2   3   ...      A       B...               code                     app     ...
Modify a File          1                     2     3    ...      A       B...               code                     app  ...
Modify a File          1                     2         3   ...      A       B...               code                     ap...
Modify a File          1                     2         3   ...      A       B...               code                     ap...
Modify a File          1                     2                3   ...      A       B...               code              co...
Modify a File          1                     2                3   ...      A       B...               code              co...
Modify a File          1                     2                    3   ...      A       B            A        B...         ...
Modify a File          1                     2                    3   ...      A       B            A        B...         ...
Modify a File          1                     2                    3   ...      A       B            A        B...         ...
Modify a File          1                     2                    3   ...      A       B            A        B...         ...
Move a File          2                     3   4   ...      A       B...               code                     app       ...
Move a File          2                     3         4   ...      A       B...               code                     app ...
Move a File          2                     3         4   ...      A       B...               code                     app ...
Move a File          2                     3                4   ...      A       B...               code              code...
Move a File          2                     3                4   ...      A       B...               code              code...
Move a File          2                     3                    4   ...      A       B            A        B...           ...
Move a File          2                     3                    4   ...      A       B            A        B...           ...
Move a File          2                     3                    4   ...      A       B            A        B...           ...
Move a File          2                     3                    4   ...      A       B            A        B...           ...
Branches and Tags          3                     4   5   ...      A       B...               code                     app ...
Branches and Tags          3                     4           5   ...      A       B                     A   B   T...      ...
Branches and Tags          3                     4           5   ...      A       B                     A   B   T...      ...
Branches and Tags          3                     4           5   ...      A       B                     A   B   T...      ...
Branches and Tags          3                     4           5      ...      A       B                     A   B   T...   ...
References• Version Control with Subversion• Feature Branch• Subversion Design Document
Thank You
Version control with subversion
Version control with subversion
Version control with subversion
Upcoming SlideShare
Loading in …5
×

Version control with subversion

1,172 views

Published on

Published in: Technology
1 Comment
6 Likes
Statistics
Notes
No Downloads
Views
Total views
1,172
On SlideShare
0
From Embeds
0
Number of Embeds
219
Actions
Shares
0
Downloads
50
Comments
1
Likes
6
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • 严格来讲不算scm\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
  • Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
  • Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
  • Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
  • Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
  • Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
  • Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
  • Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
  • Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit.\n\n
  • \nFor each file in a working directory, Subversion records (among other things) two essential pieces of information:\nWhat revision your working file is based on (this is called the file's working revision) \nA timestamp recording when the local copy was last updated by the repositor \nGiven this information, by talking to the repository, Subversion can tell which of the following four states a working file is in: Unchanged, and currentThe file is unchanged in the working directory, and no changes to that file have been committed to the repository since its working revision. An svn commit of the file will do nothing, and an svn update of the file will do nothing. Locally changed, and currentThe file has been changed in the working directory, and no changes to that file have been committed to the repository since you last updated. There are local changes that have not been committed to the repository; thus an svn commit of the file will succeed in publishing your changes, and an svn update of the file will do nothing. Unchanged, and out of dateThe 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 up- date of the file will fold the latest changes into your working copy. Locally changed, and out of dateThe 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. \n\nupdates and commits are separate\nMixed revisions are normal\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Tree changes are different, and involve changes to a directory's structure. Such changes include adding and removing files, renam- ing files or directories, and copying files or directories to new locations.\nFor tree changes, you use Subversion operations to “schedule” files and directories for removal, addition, copying, or moving. These changes may take place immediately in your working copy, but no additions or removals will happen in the repository until you commit them.\n\n
  • Subversion does this by keeping private caches of pristine, unmodified versions of each versioned file inside its working copy administrative areas. This allows Subversion to report—and revert—local modifications to those files without network access. \nThis cache (called the text-base) also allows Subversion to send the user's local modifications during a commit to the server as a compressed delta (or “difference”) against the pristine version. \nHaving this cache is a tremendous benefit—even if you have a fast Internet connection, it's generally much faster to send only a file's changes rather than the whole file to the server.\n\n
  • Subversion does this by keeping private caches of pristine, unmodified versions of each versioned file inside its working copy administrative areas. This allows Subversion to report—and revert—local modifications to those files without network access. \nThis cache (called the text-base) also allows Subversion to send the user's local modifications during a commit to the server as a compressed delta (or “difference”) against the pristine version. \nHaving this cache is a tremendous benefit—even if you have a fast Internet connection, it's generally much faster to send only a file's changes rather than the whole file to the server.\n\n
  • Subversion does this by keeping private caches of pristine, unmodified versions of each versioned file inside its working copy administrative areas. This allows Subversion to report—and revert—local modifications to those files without network access. \nThis cache (called the text-base) also allows Subversion to send the user's local modifications during a commit to the server as a compressed delta (or “difference”) against the pristine version. \nHaving this cache is a tremendous benefit—even if you have a fast Internet connection, it's generally much faster to send only a file's changes rather than the whole file to the server.\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • svn log -v\nsvn log -q\nsvn log -r 1:10\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • svn提供了足够的灵活性,能够非常方便随意的管理文件目录\n\nSubversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
  • Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
  • Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
  • Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
  • Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
  • Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
  • Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
  • Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
  • Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
  • Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
  • Subversion's file management support is quite liberating, affording almost as much flexibility for versioned files as you'd expect when manipulating your unversioned ones. But that flexibility means that across the lifetime of your repository, a given versioned object might have many paths, and a given path might represent several entirely different versioned objects. This introduces a certain level of com- plexity to your interactions with those paths and objects.\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • native\nThis causes the file to contain the EOL markers that are native to the operating system on which Subversion was run. In other words, if a user on a Windows machine checks out a working copy that contains a file with an svn:eol-style property set to native, that file will contain CRLF EOL markers. A Unix user checking out a working copy that contains the same file will see LF EOL markers in his copy of the file.\nNote that Subversion will actually store the file in the repository using normalized LF EOL markers regardless of the operating system. This is basically transparent to the user, though.\nCRLFThis causes the file to contain CRLF sequences for EOL markers, regardless of the operating system in use.\nLFThis causes the file to contain LF characters for EOL markers, regardless of the operating system in use.\nCRThis causes the file to contain CR characters for EOL markers, regardless of the operating system in use. This line-ending style is not very common.\nAnd it's worth noting again that, unlike the global-ignores option, the patterns found in the svn:ignore property apply only to the directory on which that property is set, and not to any of its subdirectories.\n\n
  • For example, svn checkout creates a working copy with every file and directory in the specified area of the repository, descending recursively through the repository tree until the entire structure is copied to your local disk.\nIntroduced in subversion 1.5\n
  • For example, svn checkout creates a working copy with every file and directory in the specified area of the repository, descending recursively through the repository tree until the entire structure is copied to your local disk.\nIntroduced in subversion 1.5\n如果只是一个参数就不值得拿出来说,特殊的地方在于,这个depth的值是会保存在working-copy中的\n1. 只checkout关心的部分\n2. subversion会记住这个depth值,后续只需直接update\n
  • For example, suppose Harry locks an image file and then begins editing it. Meanwhile, miles away, Sally wants to do the same thing. She doesn't think to run svn status -u, so she has no idea that Harry has already locked the file. She spends hours edit- ing the file, and when she tries to commit her change, she discovers that either the file is locked or that she's out of date. Regard- less, her changes aren't mergeable with Harry's. One of these two people has to throw away his or her work, and a lot of time has been wasted.\n\n
  • svn status -u\nB -- Broken\nT -- sTolen\n
  • \n
  • The --changelist option acts only as a filter for Subversion command targets, and will not add targets to an operation.\n
  • \n
  • \n
  • \n
  • This is the basic concept of a branch—namely, a line of development that exists independently of another line, yet still shares a common history if you look far enough back in time. A branch always begins life as a copy of something, and moves on from there, generating its own history\n\n
  • the only reason a copied directory is a “branch” is because humans have decided to treat it that way\n
  • \n
  • Why not diff? or manual \n
  • Notice our use of the - -reintegrate option this time around. The option is critical for reintegrating changes from a branch back into its original line of development—don't forget it! It's needed because this sort of “merge back” is a different sort of work than what you've been do- ing up until now. Previously, we had been asking svn merge to grab the “next set” of changes from one line of development (the trunk) and duplicate them to another (your branch). This is fairly straightforward, and each time Subversion knows how to pick up where it left off. \nWhen merging your branch back to the trunk, however, the underlying mathematics is quite different. Your feature branch is now a mishmash of both duplicated trunk changes and private branch changes, so there's no simple contiguous range of revisions to copy over. By specifying the --reintegrate option, you're asking Subversion to carefully replicate only those changes unique to your branch. (And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is ex- actly your branch changes!)\n\n
  • \n
  • \n
  • \n
  • \n
  • Just as with branches, the only reason a copied directory is a “tag” is because humans have decided to treat it that way\n
  • Release Branches\nMost software has a typical life cycle: code, test, release, repeat. There are two problems with this process. First, developers need to keep writing new features while quality assurance teams take time to test supposedly stable versions of the software. New work cannot halt while the software is tested. Second, the team almost always needs to support older, released versions of software; if a bug is discovered in the latest code, it most likely exists in released versions as well, and customers will want to get that bug fix without having to wait for a major new release.\n\nFeature Branches\nIt's a temporary branch created to work on a complex change without interfering with the stability of /trunk. Unlike release branches (which may need to be supported forever), feature branches are born, used for a while, merged back to the trunk, and then ultimately deleted. They have a finite span of usefulness.\nFinally, there's the issue of how to best keep a feature branch in “sync” with the trunk as work progresses. As we mentioned earlier, there's a great risk to working on a branch for weeks or months; trunk changes may continue to pour in, to the point where the two lines of development differ so greatly that it may become a nightmare trying to merge the branch back to the trunk.\nThis situation is best avoided by regularly merging trunk changes to the branch. Make up a policy: once a week, merge the last week's worth of trunk changes to the branch.\n
  • \n
  • \n
  • \n
  • 创建了太多branch会不会对svn造成性能问题及存储空间浪费?repositroy会不会急剧增长?\n\nIt doesn't matter how large the directory is—it takes a very tiny, constant amount of time and space to make a copy of it. In fact, this feature is the basis of how commits work in Subversion: each revision is a “cheap copy” of the previous revision, with a few items lazily changed within.\nSo don't be afraid to use them when needed!\n
  • \n
  • Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
  • Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
  • Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
  • Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
  • Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
  • Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
  • Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
  • Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
  • Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
  • Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
  • Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
  • Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.\nWriters don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.\nFile structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Version control with subversion

    1. 1. Version Control withSubversion Kent Wang Sep 27, 2011
    2. 2. Sometimes there’s a single right way todo things; Sometimes there are many
    3. 3. Agenda• Overview• Fundamental Concepts• Basic Usage• Advanced Topics• Branching and Merging• Appendix: Bubble-Up Method
    4. 4. Overview
    5. 5. What is Subversion?• Version control system (VCS)• Centralized• Free & Open Source (Apache License)
    6. 6. History
    7. 7. History• Early 2000, began in CollabNet, Inc.• May 2000, detailed design began• Aug 31, 2001 , “Self-hosting”• Early 2010, integrated into ASF
    8. 8. Architecture
    9. 9. command-line client app GUI client apps client interface Client Library Working Copy Management Library Repository Access DAV SVN Local Apache mode_dav svnserve mod_dav_svn repository interface Subversion Repository Berkeley DB FSFS
    10. 10. Fundamental Concepts
    11. 11. Version Control Basics Repository• The Repository• The Working Copy Client Client Client
    12. 12. Version Control Basics• Versioning Models - The problem of file sharing - The lock-modify-unlock solution - The copy-modify-merge solution
    13. 13. The problem of sharing
    14. 14. Lock-modify-unlock
    15. 15. Copy-modify-merge
    16. 16. Copy-modify-merge
    17. 17. Subversion Way• Subversion Repositories• Addressing the Repository• Revisions
    18. 18. Revisions0
    19. 19. Revisions0 1 2 3
    20. 20. Subversion Way• Working copies - How the working copy works - Disposing of a Working Copy - Administrative directory - Mixed-revision
    21. 21. Subversion Way• Working copies - How the working copy works at e! - Disposing of a Working Copy re sep ar - Administrative directory it sa m c om - Mixed-revision te sa nd p da U
    22. 22. Basic Usage
    23. 23. Help!• svn help• svn help subcommand
    24. 24. Importing • Working copy not required • Files are immediately committed to the repository • Original local directory not converted into a working copy$ svn import unversioned-directory http://svn.example.com/repos/trunk/magic
    25. 25. Create a working copy • Create a working copy on local machine • Every directory in a working copy contains an .svn subdirectory$ svn checkout http://svn.example.com/repos/trunk/magic working-copy
    26. 26. Basic Work Cycle• Update your working copy• Make your changes• Review your changes• Fix your mistakes• Resolve any conflicts• Publish (commit) your changes
    27. 27. Update working copy • Update to specified revision with -r • Commit new changes to out-of-date files and directories is not allowed by svn$ cd working-copy$ svn update
    28. 28. Make your change• File changes - Make changes using what ever tools - Svn automatically detects file changes• Tree changes - Changes to a directory’s structure - Use svn operations to “schedule”
    29. 29. Review Your Changes• Subcommand: status diff revert• Without Network
    30. 30. Review Your Changes• Subcommand: status diff revert• Without Network• Subversion keeping private caches of pristine versions in .svn/text-base/
    31. 31. Review Your Changes• Overview of your changes with svn status• --show-updates(-u) --verbose(-v) --no- ignore
    32. 32. Review Your Changes• Examine the detail of changes with svn diff• --diff-cmd
    33. 33. Fix Your Mistakes• Undoing your work with svn revert• Can undo any scheduled operation
    34. 34. Resolve Any Conflicts
    35. 35. Resolve Any Conflicts• View differences interactively• Resolving conflict differences interactively
    36. 36. Resolve Any Conflicts• Postponing conflict resolution• file.mine file.rOLDREV file.rNEWREV
    37. 37. Resolve Any Conflicts• Resolve conflicts with svn resolve• Removes three temporary files• Accepts the version of the file that you specified with the --accept option• No longer considers the file to be in a state of conflict
    38. 38. Commit Your Changes• Commit changes with svn commit• --message(-m) --file(-F)• SVN_EDITOR
    39. 39. Examining History• svn log• svn diff• svn cat• svn list• svn update --revision (-r)
    40. 40. SVN Changing Steps• Logs intentions in a private “to-do list”• Performs those action to affect the desired change, holding a lock on the relevant part of the working copy• Releases its lock and cleans up its private to-do list.
    41. 41. Clean Up• Recover from interruption with svn cleanup• Searches working copy• Runs any leftover to-do items• Removing working copy locks as it completes
    42. 42. Localization• Notices the value of LC_MESSAGES variable and attempts to print messages in the specified language• Locale is honored involves how svn interprets your input• The repository stores all paths, filenames, and log messages in Unicode, encoded as UTF-8
    43. 43. Localization• Notices the value of LC_MESSAGES variable and attempts to print messages in the specified language• Locale is honored involves how svn interprets your input• The repository stores all paths, filenames, and log messages in Unicode, encoded as UTF-8 svn: Can’t convert string from native encoding to ‘UTF-8’: svn: Can’t convert string from ‘UTF-8’ to native encoding:
    44. 44. Advanced Topics
    45. 45. Revision Tricks• Revision Keywords - HEAD - BASE - COMMITTED - PREV• Revision Dates (-r {2011-09-30})
    46. 46. Peg Revisions
    47. 47. Complexity
    48. 48. Complexity1 dream.c
    49. 49. Complexity1 2 dream.c dream.c
    50. 50. Complexity 1 2 3 dream.c dream.c dream.c$svn log dream.c # what do you mean?
    51. 51. Peg and Operative• Peg revisions• Operative revisions $svn command -r OPERATIVE-REV item@PEG-REV
    52. 52. Peg Revisions• A path and a peg revision can identify to a specific line of history• Peg revisions are specified using at syntax• Default peg revision is HEAD
    53. 53. Operative Revisions• Specified by --revision (-r) option• Subversion performs the requested operation using the operative revision
    54. 54. Properties• Versioned metadata on versioned files and directories• Property names contain only ASCII characters• Property values can be whatever you want• Revision Properties
    55. 55. Commands• svn proplist• svn propset• svn propedit• svn propget• svn propdel
    56. 56. Automatic Setting• Subversion tries to setting some common file properties automatically when adding and importing files• Subversion tries to determine the file’s MIME type• Provides flexible feature to create mappings of filename patterns to properties
    57. 57. Reserved Properties• svn:mime-type• svn:executable• svn:eol-style• svn:ignore
    58. 58. Sparse Directory• By default, operations on directories act in a recursive manner• This feature allows you to easily check out a working copy more shallowly than full recursion• Free to bring in previously ignored files and subdirectories at a later time
    59. 59. Sparse Directory• Using --depth option - --depth empty - --depth files - --depth immediates - --depth infinity
    60. 60. Sparse Directory• Using --depth option - --depth empty - --depth files - --depth immediates - --depth infinity$ svn checkout http://.../comm_proj/ --depth empty$ svn update --set-depth infinity export_include$ svn update --set-depth infinity export_lib_suse32
    61. 61. Locking• Copy-modify-merge models lives and dies on its data merging algorithm• Creating lock with svn lock• Lock token and Lock owner• svn:needs-lock as lock communication$svn info https://url-to-target | grep Lock
    62. 62. Breaking and Stealing• Breaking Locks - svn unlock --force• Stealing Locks - svn lock --force• svn status -u
    63. 63. Changelists• Working at multiple changes• Best to committed as several small logical units• Need to keep logical changes organized
    64. 64. Changelists• Allows you to create changelists by applying labels to files you want to be associated with the change list• Allow you to limit the scope of the files on which its subcommands operate to only those bearing a particular label
    65. 65. Changelists• Allows you to create changelists by applying labels to files you want to be associated with the change list• Allow you to limit the scope of the files on which its subcommands operate to only those bearing a particular label$ svn changelist ui-fixes dream.c$ svn commit --changelist ui-fixes
    66. 66. Changelist
    67. 67. Branching and Merging
    68. 68. Repository Layout
    69. 69. Repository Layouttrunk branches tags
    70. 70. What’s a Branch• A line of development that exists independently of another line• Shares a common history if look far enough back in time• Always begins life as a copy of something, and moves on from there, generating its own history
    71. 71. Creating a Branch
    72. 72. Creating a Branch$ svn copy http://svn.example.com/repo/trunk http://svn.example.com/repo/branches/my-branch -m “Creating a private branch”# Choice 1: check out new branch$ svn checkout http://svn.example.com/repo/branches/my-branch my-branch# Choice 2: switch to new branch in trunk working-copy$ svn switch http://svn.example.com/repo/branches/my-branch
    73. 73. Creating a Branch• Subversion has no internal concept of a branch• Subversion’s branches exist as normal filesystem directories in the repository• The only reason a copied directory is a “branch” is because humans have decided to treat it that way
    74. 74. Keeping Branch in Snyc • It’s very easy to drift too far apart. • May be near-impossible to merge back into the trunk without a huge number of conflicts. • Frequently keeping your branch in sync with the main line helps prevent “surprise” conflicts$ cd my-branch$ svn merge ^/trunk/
    75. 75. Reintegrating a Branch • Bring branch in sync with trunk first • Make sure trunk working copy do not have any local edits or be at mixed-revisions • Use svn merge with --reintegrate$ cd trunk$ svn merge --reintegrate ^/branches/my-branch$ svn delete ^/branches/my-branch
    76. 76. Mergeinfo and Previews• Use svn mergeinfo to see changesets has absorbed and eligible to receive• Using svn merge --dry-run option to get a more precise preview• Cherry Peeking
    77. 77. Undoing Change • Roll back a change that has already been committed • You can use svn merge to “undo” the change in your working copy, then commit • Specify a reverse difference$ svn merge -c -303 ^/trunk$ svn diff$ svn commit -m “Undoing change committed in r303”
    78. 78. Resurrect Deleted Item• Information is never lost in VCS• Delete a file just means it gone from the HEAD revision, still exists in earlier revisions
    79. 79. Resurrect Deleted Item • Define exactly which item you’re trying to resurrect (By path and peg revision) • Two choices to resurrect - Use svn merge to apply “in reverse” - Use svn copy command$ svn copy ^/trunk/dream.c@303 ./dream.c$ svn commit -m “Resurrected dream.c from r303”
    80. 80. Tags • A “snapshot” of a project in time • Nobody commits to it • svn copy comes to the rescue$ svn copy http://svn.example.com/repos/trunk http://svn.example.com/repos/tags/release-1.0$ svn copy working-copy http://svn.example.com/repos/tags/release-1.0
    81. 81. Branching Patterns• Release Branches• Feature Branches
    82. 82. Feature Branching
    83. 83. Feature Branching
    84. 84. This could be heaven
    85. 85. Or this could be hell
    86. 86. Branches and tags are cheap
    87. 87. Appendix:Bubble-Up Method
    88. 88. Modify a File 1 2 3 ... A B... code app main
    89. 89. Modify a File 1 2 3 ... A B... code app main main
    90. 90. Modify a File 1 2 3 ... A B... code app app main main
    91. 91. Modify a File 1 2 3 ... A B... code app app main main
    92. 92. Modify a File 1 2 3 ... A B... code code app app main main
    93. 93. Modify a File 1 2 3 ... A B... code code app app main main
    94. 94. Modify a File 1 2 3 ... A B A B... code code app app main main
    95. 95. Modify a File 1 2 3 ... A B A B... code code app app main main
    96. 96. Modify a File 1 2 3 ... A B A B... code code app app main main
    97. 97. Modify a File 1 2 3 ... A B A B... code code app app main main
    98. 98. Move a File 2 3 4 ... A B... code app main
    99. 99. Move a File 2 3 4 ... A B... code app svr main
    100. 100. Move a File 2 3 4 ... A B... code app svr main
    101. 101. Move a File 2 3 4 ... A B... code code app svr main
    102. 102. Move a File 2 3 4 ... A B... code code app svr main
    103. 103. Move a File 2 3 4 ... A B A B... code code app svr main
    104. 104. Move a File 2 3 4 ... A B A B... code code app svr main
    105. 105. Move a File 2 3 4 ... A B A B... code code app svr main
    106. 106. Move a File 2 3 4 ... A B A B... code code app svr main
    107. 107. Branches and Tags 3 4 5 ... A B... code app main
    108. 108. Branches and Tags 3 4 5 ... A B A B T... code app main
    109. 109. Branches and Tags 3 4 5 ... A B A B T... code app main
    110. 110. Branches and Tags 3 4 5 ... A B A B T... code app main
    111. 111. Branches and Tags 3 4 5 ... A B A B T... code app Cheap Copy main
    112. 112. References• Version Control with Subversion• Feature Branch• Subversion Design Document
    113. 113. Thank You

    ×