Subversion User Guide


Published on

Subversion Beginners User Guide

Published in: Technology
  • It's really awesome and hilarious. Extremely good Tutor to learn Subversion in detail.
    Are you sure you want to  Yes  No
    Your message goes here
  • Chào Bạn

    Bên mình hiện cung cấp gói Hosting đã tích hợp sẵn SVN bạn nhé. Mình có các gói Hosting bình thường (có tích hợp - có thể test luôn) và gói chuyên dùng SVN (Không có MySQL - dung lượng ổ đĩa lớn hơn gói hosting bình thường.

    Các Bạn có nhu cầu sử dụng dịch vụ SVN thì liên hệ mình nhé

    Link bảng giá hosting SVN:

    Hướng dấn sử dụng SVN:

    Liên hệ:
    Nguyễn Trung Văn
    Email: /
    YM: vannt_99 - Skype: vannt_99
    ĐT: 01656.95.86.88
    Are you sure you want to  Yes  No
    Your message goes here
  • its good
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Subversion User Guide

  1. 1. Subversion <ul><li>Official Subversion site: </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li> </li></ul></ul><ul><li>Wikipedia topic: </li></ul><ul><ul><li> </li></ul></ul> [email_address]
  2. 2. Repository and Modules <ul><li>Repository are created and maintained by SVN Administrator </li></ul><ul><li>Modules are imported and updated by Users </li></ul><ul><li>Many Repositories can exist in a SVN Server </li></ul><ul><li>Many Modules can exist in a single Repository </li></ul><ul><li>As an end user we care about modules </li></ul> [email_address]
  3. 3. Subversion Workflow <ul><li>Create a repository (once) </li></ul><ul><li>Import or Checkout repository (once) </li></ul><ul><li>Update and Checkin </li></ul><ul><li>Merge </li></ul><ul><li>Commit </li></ul> [email_address]
  4. 4. User Workflow <ul><li>Step 1 </li></ul><ul><ul><li>Obtain SVN Repository URL from SVN Admin </li></ul></ul><ul><ul><li>Ex 1: svn:// </li></ul></ul><ul><ul><li>Ex 2: </li></ul></ul><ul><li>Step 2 </li></ul><ul><ul><li>Checkout SVN module (Repository Copy) to local file system (Working Copy) </li></ul></ul><ul><li>Step 3 </li></ul><ul><ul><li>Update, Commit, Branch, Tag etc., </li></ul></ul> [email_address]
  5. 5. Subversion Architecture [email_address]
  6. 6. Repository Access <ul><li>As of version 1.4, Subversion repositories can be accessed by the following means: </li></ul><ul><ul><li>Local filesystem or network filesystem, accessed by client directly. </li></ul></ul><ul><ul><li>WebDAV/DeltaV (over http or https) using the mod_dav_svn module for Apache 2. </li></ul></ul><ul><ul><li>Custom &quot;svn&quot; protocol (default port 3690), using plaintext or over SSH. </li></ul></ul> [email_address]
  7. 7. Subversion Components <ul><li>svn (this is what you need) </li></ul><ul><ul><li>The command-line client program . </li></ul></ul><ul><li>svnadmin </li></ul><ul><ul><li>A tool for creating, tweaking or repairing a Subversion repository. </li></ul></ul><ul><li>svnserve </li></ul><ul><ul><li>A custom standalone server program, runnable as a daemon process or invokable by SSH; another way to make your repository available to others over a network. </li></ul></ul> [email_address]
  8. 8. Repository – Client Usage [email_address]
  9. 9. Repository URL's <ul><li>Subversion repositories can be accessed through many different methods—on local disk, or through various network protocols, depending on how your administrator has set things up for you. A repository location, however, is always a URL . </li></ul><ul><ul><li>Schema Access Method </li></ul></ul><ul><ul><ul><li>file:/// direct repository access (on local disk) </li></ul></ul></ul><ul><ul><ul><li>http:// access via WebDAV protocol to Subversion-aware Apache server </li></ul></ul></ul><ul><ul><ul><li>https:// same as http://, but with SSL encryption. </li></ul></ul></ul><ul><ul><ul><li>svn:// access via custom protocol to an svnserve server </li></ul></ul></ul><ul><ul><ul><li>svn+ssh:// same as svn://, but through an SSH tunnel. </li></ul></ul></ul> [email_address]
  10. 10. Repository – common layout <ul><li>Subversion allows you to layout your repository any way that you choose, we recommend you create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies, and a tags directory to contain tag copies, </li></ul><ul><ul><li>for example: </li></ul></ul><ul><ul><ul><li>svn list file:///usr/local/svn/repos </li></ul></ul></ul><ul><ul><ul><ul><li>/trunk </li></ul></ul></ul></ul><ul><ul><ul><ul><li>/branches </li></ul></ul></ul></ul><ul><ul><ul><ul><li>/tags </li></ul></ul></ul></ul> [email_address]
  11. 11. Understanding Revisions <ul><li>Revision numbers are global across the whole repository </li></ul><ul><li>Identify how the entire repository looks at that instant in time </li></ul><ul><li>A commit creates a snapshot of the entire tree in the repository at that revision number </li></ul><ul><li>Allows users to say, “Hey so-and-so, go get revision 1432 of XYZ and try to compile it.” </li></ul><ul><li>Before an update, both bar.c and foo.c are at revision 25 </li></ul><ul><ul><li>Modify bar.c and commit </li></ul></ul><ul><ul><li>Then update the working copy </li></ul></ul><ul><li>Now bar.c and foo.c are at revision 26, except that foo.c in revision 25 and 26 are identical </li></ul><ul><li>No additional space in repository required, i.e. a cheap copy or a symbolic link is made </li></ul> [email_address]
  12. 12. Understanding Revisions [email_address]
  13. 13. Import <ul><li>Import - I have the files and I want to put them into the initial repository </li></ul><ul><ul><li>(Working Copy to Repository) </li></ul></ul><ul><ul><li>$ svnadmin create /usr/local/svn/newrepos </li></ul></ul><ul><ul><li>$ svn import mytree file:///usr/local/svn/newrepos/some/project </li></ul></ul><ul><ul><li>-m &quot;Initial import&quot; </li></ul></ul><ul><ul><li>Adding mytree/foo.c </li></ul></ul><ul><ul><li>Adding mytree/bar.c </li></ul></ul><ul><ul><li>Adding mytree/subdir </li></ul></ul><ul><ul><li>Adding mytree/subdir/quux.h </li></ul></ul><ul><ul><li>Committed revision 1. </li></ul></ul> [email_address]
  14. 14. Checkout <ul><li>Checkout - I want to start working on an existing repository </li></ul><ul><ul><li>(Repository to Working copy) </li></ul></ul><ul><ul><ul><li>$ svn checkout </li></ul></ul></ul><ul><ul><ul><li>A trunk/ </li></ul></ul></ul><ul><ul><ul><li>A trunk/build.conf </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul><ul><ul><ul><li>Checked out revision 8810. </li></ul></ul></ul> [email_address]
  15. 15. Basic Work Cycle <ul><li>Update your working copy </li></ul><ul><li>Make changes </li></ul><ul><li>Examine your changes </li></ul><ul><li>Possibly undo some changes </li></ul><ul><li>Resolve Conflicts (Merge Others' Changes) </li></ul><ul><li>Commit your changes </li></ul> [email_address]
  16. 16. Basic Work Cycle <ul><li>Update your working copy </li></ul><ul><ul><li>svn update </li></ul></ul><ul><li>Make changes </li></ul><ul><ul><li>svn add </li></ul></ul><ul><ul><li>svn delete </li></ul></ul><ul><ul><li>svn copy </li></ul></ul><ul><ul><li>svn move </li></ul></ul><ul><li>Examine your changes </li></ul><ul><ul><li>svn status </li></ul></ul><ul><ul><li>svn diff </li></ul></ul> [email_address]
  17. 17. Basic Work Cycle <ul><li>Possibly undo some changes </li></ul><ul><ul><li>svn revert </li></ul></ul><ul><li>Resolve Conflicts (Merge Others' Changes) </li></ul><ul><ul><li>svn update </li></ul></ul><ul><ul><li>svn resolved </li></ul></ul><ul><li>Commit your changes </li></ul><ul><ul><li>svn commit </li></ul></ul> [email_address]
  18. 18. Update <ul><li>Update - Updates the local files to match the central repository </li></ul><ul><ul><li>NOTE: Change to the working folder (the local folder that you have checked out from the repository into your local file system) </li></ul></ul><ul><ul><ul><ul><li>svn update </li></ul></ul></ul></ul><ul><ul><ul><ul><li>U foo.c </li></ul></ul></ul></ul><ul><ul><ul><ul><li>U bar.c </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Updated to revision 2. </li></ul></ul></ul></ul> [email_address]
  19. 19. Update – Working Copy <ul><li>svn add foo </li></ul><ul><ul><li>Schedule file, directory, or symbolic link foo to be added to the repository. When you next commit, foo will become a child of its parent directory. Note that if foo is a directory, everything underneath foo will be scheduled for addition. If you only want to add foo itself, pass the --non-recursive (-N) option. </li></ul></ul> [email_address]
  20. 20. Update – Working Copy <ul><li>svn delete foo </li></ul><ul><ul><li>Schedule file, directory, or symbolic link foo to be deleted from the repository. If foo is a file or link, it is immediately deleted from your working copy. If foo is a directory, it is not deleted, but Subversion schedules it for deletion. When you commit your changes, foo will be removed from your working copy and the repository. [4] </li></ul></ul> [email_address]
  21. 21. Update – Working Copy <ul><li>svn copy foo bar </li></ul><ul><ul><li>Create a new item bar as a duplicate of foo and automatically schedule bar for addition. When bar is added to the repository on the next commit, its copy history is recorded (as having originally come from foo). svn copy does not create intermediate directories. </li></ul></ul> [email_address]
  22. 22. Update – Working Copy <ul><li>svn move foo bar </li></ul><ul><ul><li>This command is exactly the same as running svn copy foo bar; svn delete foo. That is, bar is scheduled for addition as a copy of foo, and foo is scheduled for removal. svn move does not create intermediate directories. </li></ul></ul> [email_address]
  23. 23. Update – Working Copy <ul><li>svn mkdir blort </li></ul><ul><ul><li>This command is exactly the same as running mkdir blort; svn add blort. That is, a new directory named blort is created and scheduled for addition. </li></ul></ul> [email_address]
  24. 24. Update <ul><li>Update working copy </li></ul><ul><ul><li>Update all files and directories to the most current version </li></ul></ul><ul><ul><li>% svn update </li></ul></ul><ul><ul><li>Go to a particular older revision for all files and directories </li></ul></ul><ul><ul><li>% svn update –r 1345 </li></ul></ul><ul><ul><li>I want an even older version of svn-doc.el </li></ul></ul><ul><ul><li>% svn update –r 999 svn-doc.el </li></ul></ul><ul><li>Update output and what it means </li></ul><ul><ul><li>U `foo' </li></ul></ul><ul><ul><ul><li>File `foo' was (U)pdated (received changes from the server.) </li></ul></ul></ul><ul><ul><li>A `foo' </li></ul></ul><ul><ul><ul><li>File or directory `foo' was (A)dded to your working copy. </li></ul></ul></ul><ul><ul><li>D `foo' </li></ul></ul><ul><ul><ul><li>File or directory `foo' was (D)eleted from your working copy. </li></ul></ul></ul><ul><ul><li>R `foo' </li></ul></ul><ul><ul><ul><li>File or directory `foo' was (R)eplaced in your working copy; that is, `foo' was deleted, and a new item with the same name was added. While they may have the same name, the repository considers them to be distinct objects with distinct histories. </li></ul></ul></ul><ul><ul><li>G `foo' </li></ul></ul><ul><ul><ul><li>File `foo' received new changes, but also had changes of your own to begin with. The changes did not intersect, however, so Subversion has mer(G)ed the repository's changes into the file without a problem. </li></ul></ul></ul><ul><ul><li>C `foo' </li></ul></ul><ul><ul><ul><li>File `foo' received (C)onflicting changes from the server. The changes from the server directly overlap your own changes to the file. No need to panic, though. This overlap needs to be resolved by a human (you). </li></ul></ul></ul> [email_address]
  25. 25. Examine Local Changes <ul><li>svn status </li></ul><ul><ul><li>A stuff/loot/bloo.h # file is scheduled for addition </li></ul></ul><ul><ul><li>C stuff/loot/lump.c # file has textual conflicts from an update </li></ul></ul><ul><ul><li>D stuff/fish.c # file is scheduled for deletion </li></ul></ul><ul><ul><li>M bar.c # the content in bar.c has local modifications </li></ul></ul><ul><ul><li>A item </li></ul></ul><ul><ul><li>The file, directory, or symbolic link item has been scheduled for addition into the repository. </li></ul></ul><ul><ul><li>C item </li></ul></ul><ul><ul><li>The file item is in a state of conflict. That is, changes received from the server during an update overlap with local changes that you have in your working copy. You must resolve this conflict before committing your changes to the repository. </li></ul></ul><ul><ul><li>D item </li></ul></ul><ul><ul><li>The file, directory, or symbolic link item has been scheduled for deletion from the repository. </li></ul></ul><ul><ul><li>M item </li></ul></ul><ul><ul><li>The contents of the file item have been modified. </li></ul></ul> [email_address]
  26. 26. Examine Local Changes <ul><li>svn status -u -v </li></ul><ul><ul><li>M * 44 23 sally README </li></ul></ul><ul><ul><li>M 44 20 harry bar.c </li></ul></ul><ul><ul><li>* 44 35 harry stuff/trout.c </li></ul></ul><ul><ul><li>D 44 19 ira stuff/fish.c </li></ul></ul><ul><ul><li>A 0 ? ? stuff/things/bloo.h </li></ul></ul><ul><ul><li>Status against revision: 46 </li></ul></ul><ul><ul><li>Notice the two asterisks: if you were to run svn update at this point, you would receive changes to README and trout.c. This tells you some very useful information—you'll need to update and get the server changes on README before you commit, or the repository will reject your commit for being out-of-date. (More on this subject later.) </li></ul></ul> [email_address]
  27. 27. Examine Changes in detail <ul><li>svn diff </li></ul><ul><ul><li>Index: bar.c </li></ul></ul><ul><ul><li>=================================================================== </li></ul></ul><ul><ul><li>--- bar.c (revision 3) </li></ul></ul><ul><ul><li>+++ bar.c (working copy) </li></ul></ul><ul><ul><li>@@ -1,7 +1,12 @@ </li></ul></ul><ul><ul><li>+#include <sys/types.h> </li></ul></ul><ul><ul><li>+#include <sys/stat.h> </li></ul></ul><ul><ul><li>+#include <unistd.h> </li></ul></ul><ul><ul><li>+ </li></ul></ul><ul><ul><li>+#include <stdio.h> </li></ul></ul><ul><ul><li>int main(void) { </li></ul></ul><ul><ul><li>- printf(&quot;Sixty-four slices of American Cheese... &quot;); </li></ul></ul><ul><ul><li>+ printf(&quot;Sixty-five slices of American Cheese... &quot;); </li></ul></ul><ul><ul><li>return 0; </li></ul></ul><ul><ul><li>} </li></ul></ul> [email_address]
  28. 28. Undoing local changes <ul><li>svn revert ITEM has exactly the same effect as deleting ITEM from your working copy and then running svn update -r BASE ITEM. However, if you're reverting a file, svn revert has one very noticeable difference—it doesn't have to communicate with the repository to restore your file. </li></ul><ul><ul><li>$ svn revert README </li></ul></ul><ul><ul><li>Reverted 'README' </li></ul></ul> [email_address]
  29. 29. Resolove Conflicts <ul><li>Suppose you run svn update and some interesting things occur: </li></ul><ul><ul><li>$ svn update </li></ul></ul><ul><ul><li>U INSTALL </li></ul></ul><ul><ul><li>G README </li></ul></ul><ul><ul><li>C bar.c </li></ul></ul><ul><ul><li>Updated to revision 46. </li></ul></ul><ul><li>The U and G codes are no cause for concern; those files cleanly absorbed changes from the repository. The files marked with U contained no local changes but were Updated with changes from the repository. The G stands for merGed, which means that the file had local changes to begin with, but the changes coming from the repository didn't overlap with the local changes. </li></ul><ul><li>But the C stands for conflict. This means that the changes from the server overlapped with your own, and now you have to manually choose between them. </li></ul> [email_address]
  30. 30. Resolove Conflicts <ul><li>Whenever a conflict occurs, three things typically occur to assist you in noticing and resolving that conflict: </li></ul><ul><ul><li>Subversion prints a C during the update, and remembers that the file is in a state of conflict. </li></ul></ul><ul><ul><li>If Subversion considers the file to be mergeable, it places conflict markers—special strings of text which delimit the “sides” of the conflict—into the file to visibly demonstrate the overlapping areas. </li></ul></ul><ul><ul><li>For every conflicted file, Subversion places three extra unversioned files in your working copy: </li></ul></ul><ul><ul><ul><li>filename.mine </li></ul></ul></ul><ul><ul><ul><ul><li>This is your file as it existed in your working copy before you updated your working copy—that is, without conflict markers. This file has only your latest changes in it. (If Subversion considers the file to be unmergeable, then the .mine file isn't created, since it would be identical to the working file.) </li></ul></ul></ul></ul><ul><ul><ul><li>filename.rOLDREV </li></ul></ul></ul><ul><ul><ul><ul><li>This is the file that was the BASE revision before you updated your working copy. That is, the file that you checked out before you made your latest edits. </li></ul></ul></ul></ul><ul><ul><ul><li>filename.rNEWREV </li></ul></ul></ul><ul><ul><ul><ul><li>This is the file that your Subversion client just received from the server when you updated your working copy. This file corresponds to the HEAD revision of the repository. (Here OLDREV is the revision number of the file in your .svn directory and NEWREV is the revision number of the repository HEAD.) </li></ul></ul></ul></ul> [email_address]
  31. 31. Resolove Conflicts <ul><li>For example, Sally makes changes to the file sandwich.txt in the repository. Harry has just changed the file in his working copy and checked it in. Sally updates her working copy before checking in and she gets a conflict: </li></ul><ul><ul><li>$ svn update </li></ul></ul><ul><ul><li>C sandwich.txt </li></ul></ul><ul><ul><li>Updated to revision 2. </li></ul></ul><ul><ul><li>$ ls -1 </li></ul></ul><ul><ul><li>sandwich.txt </li></ul></ul><ul><ul><li>sandwich.txt.mine </li></ul></ul><ul><ul><li>sandwich.txt.r1 </li></ul></ul><ul><ul><li>sandwich.txt.r2 </li></ul></ul><ul><li>At this point, Subversion will not allow you to commit the file sandwich.txt until the three temporary files are removed. </li></ul> [email_address]
  32. 32. Resolove Conflicts <ul><ul><ul><li>$ svn commit -m &quot;Add a few more things&quot; </li></ul></ul></ul><ul><ul><ul><li>svn: Commit failed (details follow): </li></ul></ul></ul><ul><ul><ul><li>svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict </li></ul></ul></ul><ul><li>If you get a conflict, you need to do one of three things: </li></ul><ul><ul><li>Merge the conflicted text “by hand” (by examining and editing the conflict markers within the file). </li></ul></ul><ul><ul><li>Copy one of the temporary files on top of your working file. </li></ul></ul><ul><ul><li>Run svn revert <filename> to throw away all of your local changes. </li></ul></ul><ul><li>Once you've resolved the conflict, you need to let Subversion know by running svn resolved. This removes the three temporary files and Subversion no longer considers the file to be in a state of conflict.[6] </li></ul><ul><ul><ul><li>$ svn resolved sandwich.txt </li></ul></ul></ul><ul><ul><ul><li>Resolved conflicted state of 'sandwich.txt' </li></ul></ul></ul> [email_address]
  33. 33. Merge <ul><li>We both update the same file at the same time. What happens? </li></ul><ul><li>Update tells me there is a conflict </li></ul><ul><ul><li>You checked yours in first </li></ul></ul><ul><li>I have to merge the two updates together. </li></ul><ul><ul><li>Before checking in </li></ul></ul> [email_address]
  34. 34. Merge Conflicts by hand <ul><li>Merging conflicts by hand can be quite intimidating the first time you attempt it, but with a little practice, it can become as easy as falling off a bike. </li></ul> [email_address] <ul><li>Here's an example. Due to a miscommunication, you and Sally, your collaborator, both edit the file sandwich.txt at the same time. Sally commits her changes, and when you go to update your working copy, you get a conflict and you're going to have to edit sandwich.txt to resolve the conflicts. First, let's take a look at the file: </li></ul><ul><ul><li>$ cat sandwich.txt </li></ul></ul><ul><ul><li>Top piece of bread </li></ul></ul><ul><ul><li>Mayonnaise </li></ul></ul><ul><ul><li>Lettuce </li></ul></ul><ul><ul><li>Tomato </li></ul></ul><ul><ul><li>Provolone </li></ul></ul><ul><ul><li><<<<<<< .mine </li></ul></ul><ul><ul><li>Salami </li></ul></ul><ul><ul><li>Mortadella </li></ul></ul><ul><ul><li>Prosciutto </li></ul></ul><ul><ul><li>======= </li></ul></ul><ul><ul><li>Sauerkraut </li></ul></ul><ul><ul><li>Grilled Chicken </li></ul></ul><ul><ul><li>>>>>>>> .r2 </li></ul></ul><ul><ul><li>Creole Mustard </li></ul></ul><ul><ul><li>Bottom piece of bread </li></ul></ul>
  35. 35. Merge Conflicts by hand <ul><li>The strings of less-than signs, equal signs, and greater-than signs are conflict markers, and are not part of the actual data in conflict. You generally want to ensure that those are removed from the file before your next commit. The text between the first two sets of markers is composed of the changes you made in the conflicting area: </li></ul><ul><ul><li><<<<<<< .mine </li></ul></ul><ul><ul><li>Salami </li></ul></ul><ul><ul><li>Mortadella </li></ul></ul><ul><ul><li>Prosciutto </li></ul></ul><ul><ul><li>======= </li></ul></ul><ul><ul><li>The text between the second and third sets of conflict markers is the text from Sally's commit: </li></ul></ul><ul><ul><li>======= </li></ul></ul><ul><ul><li>Sauerkraut </li></ul></ul><ul><ul><li>Grilled Chicken </li></ul></ul><ul><ul><li>>>>>>>> .r2 </li></ul></ul> [email_address] <ul><li>Usually you won't want to just delete the conflict markers and Sally's changes—she's going to be awfully surprised when the sandwich arrives and it's not what she wanted. So this is where you pick up the phone or walk across the office and explain to Sally that you can't get sauerkraut from an Italian deli.[7] Once you've agreed on the changes you will check in, edit your file and remove the conflict markers. </li></ul><ul><ul><li>Top piece of bread </li></ul></ul><ul><ul><li>Mayonnaise </li></ul></ul><ul><ul><li>Lettuce </li></ul></ul><ul><ul><li>Tomato </li></ul></ul><ul><ul><li>Provolone </li></ul></ul><ul><ul><li>Salami </li></ul></ul><ul><ul><li>Mortadella </li></ul></ul><ul><ul><li>Prosciutto </li></ul></ul><ul><ul><li>Creole Mustard </li></ul></ul><ul><ul><li>Bottom piece of bread </li></ul></ul>
  36. 36. Merge Conflicts by hand <ul><li>Now run svn resolved, and you're ready to commit your changes: </li></ul><ul><ul><ul><li>$ svn resolved sandwich.txt </li></ul></ul></ul><ul><ul><ul><li>$ svn commit -m &quot;Go ahead and use my sandwich, discarding Sally's edits.&quot; </li></ul></ul></ul><ul><li>Note that svn resolved requires an argument. In any case, you want to be careful and only run svn resolved when you're certain that you've fixed the conflict in your file—once the temporary files are removed, Subversion will let you commit the file even if it still contains conflict markers. </li></ul><ul><li>If you ever get confused while editing the conflicted file, you can always consult the three files that Subversion creates for you in your working copy—including your file as it was before you updated. You can even use a third-party interactive merging tool to examine those three files. </li></ul> [email_address]
  37. 37. Merge – Copying File <ul><li>Copying a File Onto Your Working File </li></ul><ul><ul><li>If you get a conflict and decide that you want to throw out your changes, you can merely copy one of the temporary files created by Subversion over the file in your working copy: </li></ul></ul><ul><ul><ul><li>svn update </li></ul></ul></ul><ul><ul><ul><ul><ul><li>C sandwich.txt </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Updated to revision 2. </li></ul></ul></ul></ul></ul><ul><ul><ul><li>ls sandwich.* </li></ul></ul></ul><ul><ul><ul><ul><ul><li>sandwich.txt sandwich.txt.mine sandwich.txt.r2 sandwich.txt.r1 </li></ul></ul></ul></ul></ul><ul><ul><ul><li>cp sandwich.txt.r2 sandwich.txt </li></ul></ul></ul><ul><ul><ul><li>svn resolved sandwich.txt </li></ul></ul></ul> [email_address]
  38. 38. Merge – Reverting File <ul><li>Punting: Using svn revert </li></ul><ul><ul><li>If you get a conflict, and upon examination decide that you want to throw out your changes and start your edits again, just revert your changes: </li></ul></ul><ul><ul><ul><li>$ svn revert sandwich.txt </li></ul></ul></ul><ul><ul><ul><ul><ul><li>Reverted 'sandwich.txt' </li></ul></ul></ul></ul></ul><ul><ul><ul><li>$ ls sandwich.* </li></ul></ul></ul><ul><ul><ul><ul><ul><li>sandwich.txt </li></ul></ul></ul></ul></ul><ul><ul><li>Note that when you revert a conflicted file, you don't have to run svn resolved. </li></ul></ul> [email_address]
  39. 39. Checkin <ul><li>Check-in - Update the central repository to match your local files </li></ul><ul><li>Always update before checking in (svn enforces this) </li></ul><ul><li>Always test with the latest update before checking in (not enforced) </li></ul> [email_address]
  40. 40. Commit <ul><li>svn commit command sends all of your changes to the repository. When you commit a change, you need to supply a log message, describing your change. Your log message will be attached to the new revision you create. Log message can be set in command line using the --message (or -m) switch: </li></ul><ul><ul><li>$ svn commit -m &quot;Corrected number of cheese slices.&quot; </li></ul></ul><ul><ul><ul><li>Sending sandwich.txt </li></ul></ul></ul><ul><ul><ul><li>Transmitting file data . </li></ul></ul></ul><ul><ul><ul><li>Committed revision 3. </li></ul></ul></ul> [email_address]
  41. 41. Examining History <ul><li>Subversion repository keeps a record of every change ever committed, and allows you to explore this history by examining previous versions of files and directories as well as the metadata that accompanies them. With a single Subversion command, you can check out the repository (or restore an existing working copy) exactly as it was at any date or revision number in the past. </li></ul> [email_address]
  42. 42. Examining History <ul><li>However, sometimes you just want to peer into the past instead of going into the past. </li></ul><ul><li>svn log </li></ul><ul><ul><li>Shows you broad information: log messages with date and author information attached to revisions, and which paths changed in each revision. </li></ul></ul> [email_address] <ul><li>svn diff </li></ul><ul><ul><li>Shows line-level details of a particular change. </li></ul></ul><ul><li>svn cat </li></ul><ul><ul><li>This is used to retrieve any file as it existed in a particular revision number and display it on your screen. </li></ul></ul><ul><li>svn list </li></ul><ul><ul><li>Displays the files in a directory for any given revision. </li></ul></ul>
  43. 43. Branching [email_address]
  44. 44. Branching [email_address]
  45. 45. Creating a Branch <ul><li>Create a branch by making a copy of the project in the repository using the svn copy command. Subversion is not only able to copy single files, but whole directories as well. </li></ul><ul><ul><li>svn copy </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li>-m &quot;Creating a private branch of /calc/trunk.&quot; </li></ul></ul><ul><ul><li>Committed revision 341. </li></ul></ul> [email_address]
  46. 46. Creating a Tag <ul><li>A tag is just a “snapshot” of a project in time. In Subversion, this idea already seems to be everywhere. Each repository revision is exactly that—a snapshot of the filesystem after each commit. </li></ul><ul><ul><li>svn copy </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li>-m &quot;Tagging the 1.0 release of the 'calc' project.&quot; </li></ul></ul><ul><ul><li>Committed revision 351. </li></ul></ul> [email_address]
  47. 47. Summary <ul><li>Import / Checkout </li></ul><ul><ul><li>The first time to add / retrieve module </li></ul></ul><ul><li>Update </li></ul><ul><ul><li>Everytime to refresh working copy </li></ul></ul><ul><li>Merge </li></ul><ul><ul><li>Working copy conflicts with repository copy, the repository copy is updated by another user </li></ul></ul><ul><li>Commit </li></ul><ul><ul><li>Send local changes to the repository </li></ul></ul> [email_address]
  48. 48. Resources <ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul> [email_address]
  49. 49. IntelliBitz Technologies <ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><ul><li>168, Medavakkam Main Road, Madipakkam </li></ul></ul><ul><ul><li>Chennai, 600091, India. </li></ul></ul><ul><ul><li>+91 44 2247 5106 </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul> [email_address]
  50. 50. IntelliBitz Technologies [email_address] <ul><ul><li>Thank You! </li></ul></ul>