• Like
Version control with subversion
Upcoming SlideShare
Loading in...5
×

Version control with subversion

  • 812 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
812
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
29
Comments
1
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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

Transcript

  • 1. Version Control withSubversion Kent Wang Sep 27, 2011
  • 2. Sometimes there’s a single right way todo things; Sometimes there are many
  • 3. Agenda• Overview• Fundamental Concepts• Basic Usage• Advanced Topics• Branching and Merging• Appendix: Bubble-Up Method
  • 4. Overview
  • 5. What is Subversion?• Version control system (VCS)• Centralized• Free & Open Source (Apache License)
  • 6. History
  • 7. History• Early 2000, began in CollabNet, Inc.• May 2000, detailed design began• Aug 31, 2001 , “Self-hosting”• Early 2010, integrated into ASF
  • 8. Architecture
  • 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. Fundamental Concepts
  • 11. Version Control Basics Repository• The Repository• The Working Copy Client Client Client
  • 12. Version Control Basics• Versioning Models - The problem of file sharing - The lock-modify-unlock solution - The copy-modify-merge solution
  • 13. The problem of sharing
  • 14. Lock-modify-unlock
  • 15. Copy-modify-merge
  • 16. Copy-modify-merge
  • 17. Subversion Way• Subversion Repositories• Addressing the Repository• Revisions
  • 18. Revisions0
  • 19. Revisions0 1 2 3
  • 20. Subversion Way• Working copies - How the working copy works - Disposing of a Working Copy - Administrative directory - Mixed-revision
  • 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. Basic Usage
  • 23. Help!• svn help• svn help subcommand
  • 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. 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. Basic Work Cycle• Update your working copy• Make your changes• Review your changes• Fix your mistakes• Resolve any conflicts• Publish (commit) your changes
  • 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. 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. Review Your Changes• Subcommand: status diff revert• Without Network
  • 30. Review Your Changes• Subcommand: status diff revert• Without Network• Subversion keeping private caches of pristine versions in .svn/text-base/
  • 31. Review Your Changes• Overview of your changes with svn status• --show-updates(-u) --verbose(-v) --no- ignore
  • 32. Review Your Changes• Examine the detail of changes with svn diff• --diff-cmd
  • 33. Fix Your Mistakes• Undoing your work with svn revert• Can undo any scheduled operation
  • 34. Resolve Any Conflicts
  • 35. Resolve Any Conflicts• View differences interactively• Resolving conflict differences interactively
  • 36. Resolve Any Conflicts• Postponing conflict resolution• file.mine file.rOLDREV file.rNEWREV
  • 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. Commit Your Changes• Commit changes with svn commit• --message(-m) --file(-F)• SVN_EDITOR
  • 39. Examining History• svn log• svn diff• svn cat• svn list• svn update --revision (-r)
  • 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. 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. 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. 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. Advanced Topics
  • 45. Revision Tricks• Revision Keywords - HEAD - BASE - COMMITTED - PREV• Revision Dates (-r {2011-09-30})
  • 46. Peg Revisions
  • 47. Complexity
  • 48. Complexity1 dream.c
  • 49. Complexity1 2 dream.c dream.c
  • 50. Complexity 1 2 3 dream.c dream.c dream.c$svn log dream.c # what do you mean?
  • 51. Peg and Operative• Peg revisions• Operative revisions $svn command -r OPERATIVE-REV item@PEG-REV
  • 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. Operative Revisions• Specified by --revision (-r) option• Subversion performs the requested operation using the operative revision
  • 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. Commands• svn proplist• svn propset• svn propedit• svn propget• svn propdel
  • 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. Reserved Properties• svn:mime-type• svn:executable• svn:eol-style• svn:ignore
  • 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. Sparse Directory• Using --depth option - --depth empty - --depth files - --depth immediates - --depth infinity
  • 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. 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. Breaking and Stealing• Breaking Locks - svn unlock --force• Stealing Locks - svn lock --force• svn status -u
  • 63. Changelists• Working at multiple changes• Best to committed as several small logical units• Need to keep logical changes organized
  • 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. 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. Changelist
  • 67. Branching and Merging
  • 68. Repository Layout
  • 69. Repository Layouttrunk branches tags
  • 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. Creating a Branch
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. Branching Patterns• Release Branches• Feature Branches
  • 82. Feature Branching
  • 83. Feature Branching
  • 84. This could be heaven
  • 85. Or this could be hell
  • 86. Branches and tags are cheap
  • 87. Appendix:Bubble-Up Method
  • 88. Modify a File 1 2 3 ... A B... code app main
  • 89. Modify a File 1 2 3 ... A B... code app main main
  • 90. Modify a File 1 2 3 ... A B... code app app main main
  • 91. Modify a File 1 2 3 ... A B... code app app main main
  • 92. Modify a File 1 2 3 ... A B... code code app app main main
  • 93. Modify a File 1 2 3 ... A B... code code app app main main
  • 94. Modify a File 1 2 3 ... A B A B... code code app app main main
  • 95. Modify a File 1 2 3 ... A B A B... code code app app main main
  • 96. Modify a File 1 2 3 ... A B A B... code code app app main main
  • 97. Modify a File 1 2 3 ... A B A B... code code app app main main
  • 98. Move a File 2 3 4 ... A B... code app main
  • 99. Move a File 2 3 4 ... A B... code app svr main
  • 100. Move a File 2 3 4 ... A B... code app svr main
  • 101. Move a File 2 3 4 ... A B... code code app svr main
  • 102. Move a File 2 3 4 ... A B... code code app svr main
  • 103. Move a File 2 3 4 ... A B A B... code code app svr main
  • 104. Move a File 2 3 4 ... A B A B... code code app svr main
  • 105. Move a File 2 3 4 ... A B A B... code code app svr main
  • 106. Move a File 2 3 4 ... A B A B... code code app svr main
  • 107. Branches and Tags 3 4 5 ... A B... code app main
  • 108. Branches and Tags 3 4 5 ... A B A B T... code app main
  • 109. Branches and Tags 3 4 5 ... A B A B T... code app main
  • 110. Branches and Tags 3 4 5 ... A B A B T... code app main
  • 111. Branches and Tags 3 4 5 ... A B A B T... code app Cheap Copy main
  • 112. References• Version Control with Subversion• Feature Branch• Subversion Design Document
  • 113. Thank You