Changes between Version 2 and Version 3 of Cross/SVNGuidelines
- Timestamp:
- 09/14/09 09:06:48 (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Cross/SVNGuidelines
v2 v3 30 30 31 31 Before you can commit changes to a file to the repository, you must first tell the repository that it should monitor the file. To do this, use the ‘add’ command: 32 32 {{{ 33 33 $ svn add <file> 34 34 }}} 35 35 Note that a file only needs to be ‘added’ to the repo once! 36 36 … … 39 39 40 40 Now that the SCM is monitoring the file, you can commit the changes you have made to the file by using the ‘commit’ command: 41 42 43 41 {{{ 42 $ svn ci <file> -m “Initial check-in.” 43 }}} 44 44 Note that each time you commit changes to a file, you should submit a comment explaining what you changed. This is done by using the ‘-m’ option, and putting the comment in quotes. 45 45 … … 51 51 52 52 Subversion provides a way to add files to the repo and commit them recursively in one fell-swoop. This is done using the svn ‘import’ command. 53 54 55 53 {{{ 54 $ svn import <file/directory> <URL> 55 }}} 56 56 The ‘import’ command will recursively add and commit an entire directory, or a single file, to the repo at the provided URL. Furthermore, if the directory structure passed into the URL doesn’t exist, ‘import’ will create the folders necessary to create the path. 57 57 … … 61 61 62 62 Let’s say that there is a file in the repository that you want to edit. First, you need to ‘check-out’ the file to get the most recent copy of it on your computer. 63 64 65 63 {{{ 64 $ svn co <https://path/to/repo/and/file> 65 }}} 66 66 This will pull the file from the repo into the current directory on your computer. Again, note that if the passed path actually points to a directory rather than a single file, the whole directory will be downloaded to your machine. 67 67 … … 71 71 72 72 ‘Updating’ a file simply means pulling the most recent version of the file from the repo. This should be done on a regular basis to ensure that you are always working on the most up-to-date version of the file. Updating is quite simple: 73 74 75 73 {{{ 74 $ svn update <file> 75 }}} 76 76 If no file argument is passed to the command, then it will update every file in the current directory. This is the most common usage of the command. 77 77 78 78 It is also possible to ‘update’ a file to a specific revision. This is done using the ‘-r’ option: 79 80 81 79 {{{ 80 $ svn update -r<revision> <file> 81 }}} 82 82 If the passed revision number is lower than your current revision, then you are effectively downgrading that file. 83 83 … … 85 85 86 86 There is a subversion command to do exactly what the standard ‘mv’ UNIX command does – i.e. move a file from one name/location to another: 87 88 89 87 {{{ 88 $ svn mv <file1> <file2> 89 }}} 90 90 Just like the traditional UNIX command, svn ‘mv’ can be used to rename a file or change it’s directory location. Any changes made will need to be committed, using the process discussed previously. 91 91 … … 93 93 94 94 So you’ve been editing a bunch of files, and you’ve forgotten which files you’ve edited and exactly what changes you have made (Note: If you are in this position, then you have probably violated a basic principle of using a SCM, which we will discuss later). In order to see what files you have changed, you can use the ‘status’ command: 95 96 97 95 {{{ 96 $ svn status 97 }}} 98 98 This command will list every file in the current directory that has been modified in some way. These files are listed with keys, indicating how they have been changed. Now, let’s say you want to look at the specific changes made in one file. This can be done with the ‘diff’ command: 99 100 101 99 {{{ 100 $ svn diff <file> 101 }}} 102 102 This command will list all of the differences between your local copy of the file, and the version currently stored in the repo. 103 103 … … 105 105 106 106 Argh! You accidently just wrote a bunch of changes to a file that broke everything! Time to revert! 107 108 109 107 {{{ 108 $ svn revert <file> 109 }}} 110 110 Reverting a file will throw away all of the changes you made to the file, and pull a pristine copy of the file from the repository. 111 111 … … 119 119 120 120 Creating a ‘branch’ is really very easy. You merely copy the current trunk development line into another directory: 121 122 123 121 {{{ 122 $ svn copy https://path/to/repo/trunk https://path/to/repo/branch 123 }}} 124 124 All of your experimental work should be committed to your branch to prevent breaking the trunk code-base for everyone else. 125 125 … … 129 129 130 130 Let’s say that when you originally branched, you were at revision 100. Your branch line at the end of development was at revision 150. To commit the changes occurring in your branch from revisions 101 to 150, from the trunk directory, you would do: 131 132 133 131 {{{ 132 $ svn merge -r101:150 https://path/to/repo/branch 133 }}} 134 134 This tells the VCS to grab all of the changes made to the passed branch directory from revisions 101 to 150, and apply them to the current directory, which should be trunk if you run it from the trunk directory. 135 135 … … 139 139 140 140 Tags provide a way of storing what the development line looked like at a certain point in time. They should be treated as read-only directories, created solely for check-outs. They are primarily used for indicating a release. To create a tag, merely copy the current development line into another directory: 141 142 143 141 {{{ 142 $ svn copy https://path/to/repo/trunk https://path/to/repo/tag 143 }}} 144 144 Note that calling something a tag does not make it read-only in the repo. It is up to the developers to honor something called a ‘tag’, and not commit changes to it. 145 145
