The top pane has an Actions column containing icons that summarize what has been done in that revision. There are four different icons, each shown in its own column. If a revision modified a file or directory, the modified icon is shown in the first column.
If a revision added a file or directory, the added icon is shown in the second column. If a revision deleted a file or directory, the deleted icon is shown in the third column. If a revision replaced a file or directory, the replaced icon is shown in the fourth column. If a revision moved or renamed a file or directory, the moved icon is shown in the fourth column.
If a revision merged a file or directory, the merged icon is shown in the fourth column. If a revision reverse merged a file or directory, the reverse merged icon is shown in the fourth column. The top pane of the Log dialog has a context menu that allows you to access much more information. Some of these menu entries appear only when the log is shown for a file, and some only when the log is shown for a folder. Compare the selected revision with your working copy. If the log dialog is for a folder, this will show you a list of changed files, and allow you to review the changes made to each file individually.
Blame the selected revision, and the file in your working BASE and compare the blame reports using a visual diff tool. This shows only the differences with a few lines of context. It is harder to read than a visual file compare, but will show all file changes together in a compact format. If you hold down the Shift key when clicking on the menu item, a dialog shows up first where you can set options for the unified diff.
These options include the ability to ignore changes in line endings and whitespaces. Compare the selected revision with the previous revision. This works in a similar manner to comparing with your working copy. For folders this option will first show the changed files dialog allowing you to select files to compare.
Show the changed files dialog allowing you to select files. Blame the selected revision, and the previous revision, and compare the results using a visual diff tool.
Save the selected revision to a file so you have an older version of that file. Open the selected file, either with the default viewer for that file type, or with a program you choose. Open the repository browser to examine the selected file or folder in the repository as it was at the selected revision. Create a branch or tag from a selected revision. This is useful e. Update your working copy to the selected revision. Useful if you want to have your working copy reflect a time in the past, or if there have been further commits to the repository and you want to update your working copy one step at a time.
It is best to update a whole directory in your working copy, not just one file, otherwise your working copy could be inconsistent. If you want to undo an earlier change permanently, use Revert to this revision instead. Revert to an earlier revision. If you have made several changes, and then decide that you really want to go back to how things were in revision N, this is the command you need. The changes are undone in your working copy so this operation does not affect the repository until you commit the changes.
If your working copy is in an unmodified state, after you perform this action your working copy will show as modified. If you already have local changes, this command will merge the undo changes into your working copy. What is happening internally is that Subversion performs a reverse merge of all the changes made after the selected revision, undoing the effect of those previous commits. If you simply want to see what a file or folder looked like at an earlier revision, use Update to revision or Save revision as Undo changes from which were made in the selected revision.
The changes are undone in your working copy so this operation does not affect the repository at all! Note that this will undo the changes made in that revision only; it does not replace your working copy with the entire file at the earlier revision.
This is very useful for undoing an earlier change when other unrelated changes have been made since. What is happening internally is that Subversion performs a reverse merge of that one revision, undoing its effect from a previous commit. You can undo the undo as described above in Revert to this revision. Merge the selected revision s into a different working copy.
A folder selection dialog allows you to choose the working copy to merge into, but after that there is no confirmation dialog, nor any opportunity to try a test merge. It is a good idea to merge into an unmodified working copy so that you can revert the changes if it doesn't work out! This is a useful feature if you want to merge selected revisions from one branch to another. Make a fresh checkout of the selected folder at the selected revision.
This brings up a dialog for you to confirm the URL and revision, and select a location for the checkout. This brings up a dialog for you to confirm the URL and revision, and select a location for the export. Edit the log message or author attached to a previous commit. View and edit any revision property, not just log message and author. Copy the log details of the selected revisions to the clipboard. This will copy the revision number, author, date, log message and the list of changed items for each revision.
Search log messages for the text you enter. This searches the log messages that you entered and also the action summaries created by Subversion shown in the bottom pane. The search is not case sensitive.
This menu is shown only if the SmartBear code collaborator tool is installed. When invoked for the first time, a dialog is shown prompting the user to enter user credentials for both code collaborator and SVN. Once the settings are stored, the settings dialog is no longer shown when the menu is invoked, unless the user holds Ctrl while executing the menu item.
The configuration and the chosen revision s are used to invoke the code collaborator graphical user interface client, which creates a new review with the selected revisions. If you select two revisions at once using the usual Ctrl -modifier , the context menu changes and gives you fewer options:.
Compare the two selected revisions using a visual difference tool. If you select this option for a folder, a further dialog pops up listing the changed files and offering you further diff options.
Blame the two revisions and compare the blame reports using a visual difference tool. If you specify a single date as a revision without specifying a time of day for example , you may think that Subversion should give you the last revision that took place on the 27th of November. Instead, you'll get back a revision from the 26th, or even earlier. Remember that Subversion will find the most recent revision of the repository as of the date you give.
If you give a date without a timestamp, like , Subversion assumes a time of , so looking for the most recent revision won't return anything on the day of the 27th. You can also use a range of dates. Subversion will find all revisions between both dates, inclusive:. Users should be aware of a subtlety that can become quite a stumbling-block when dealing with dates in Subversion.
Since the timestamp of a revision is stored as a property of the revision—an unversioned, modifiable property—revision timestamps can be changed to represent complete falsifications of true chronology, or even removed altogether. This will wreak havoc on the internal date-to-revision conversion that Subversion performs. The most recent revision prior to, or equal to, BASE , in which an item changed. The revision immediately before the last revision in which an item changed.
HEAD , on the other hand, can be used in conjunction with both of these path types. Revision numbers reveal nothing about the world outside the version control system, but sometimes you need to correlate a moment in real time with a moment in version history. Subversion accepts the standard ISO date and time formats, plus a few others. Here are some examples.
Keep in mind that most shells will require you to, at a minimum, quote or otherwise escape any spaces that are included as part of revision date specifiers. Certain shells may also take issue with the unescaped use of curly braces, too. Consult your shell's documentation for the requirements specific to your environment.
When you specify a date, Subversion resolves that date to the most recent revision of the repository as of that date, and then continues to operate against that resolved revision number:. If you specify a single date as a revision without specifying a time of day for example , you may think that Subversion should give you the last revision that took place on the 27th of November. Adding a new file to the repository.
Deleting a file from the repository. To resolve conflicts in a file marked with a C. Creating a new project in the svn repository. Copying an older revision of a file or folder back into the current svn revision. Checking out an older revision from SVN. Removing subversion control for a folder. Then you would do either of the following: svn checkout url svn co url The above will check it all out into a default folder name. To update the local file s with just the changes made in the repository, do an "svn update":.
To overwrite local file s with the one in the repository, do an "svn revert"—you would do this if you want to go back to the version of the file in the repository you will lose all changes you had made since the last commit :. If, when doing an "svn status" of a folder you find any files marked with a C, then it means such files are in conflict with their corresponding versions in the svn repository. Doing an "svn update" may indicate files are in conflict as well.
If you performed an "svn update" on some files or on a folder and one or more came up with the status C then you have a conflict. It means that changes to the same file on the same lines had been committed to the svn repository as what you have been working on.
The update could not successfully merge the corresponding lines as it didn't know which lines to keep and which to overwrite: the lines are in conflict. Open up the file that's in conflict in an editor.
Each occurrence marks a conflicted section and needs to be resolved. Deal with marked sections as appropriate: decide which parts you want to keep, which should be removed or how to combine the best of both. Once you've finished editing out the conflicts in the file, you have to set the file's status to resolved for it to be up to date and updateable with svn :.
To find out the list of changes made to code in a file:. Or, if you know the specific line of change for which you want to understand the reasoning or view the log message:. If you want to find all the files in a particular commit and the log message for them:.
In order to set up or adjust the svn:externals property on a folder, so it knows upon checkout which other folders and files to grab from SVN as its subelements: Use a terminal to set up an editor to adjust the svn externals property. To start editing the svn externals property at this folder.
0コメント