Am 19.12.2012 04:40, schrieb John Cowan:
> This is draft 1. Please check it over for clarity (and if you find
> errors, of course let me know). There will be later drafts.
I guess most comments below are subjective. But I'll want to tell them
anyway :)
> 2) Okay, all set. Now I want to check out a file so I can start working
> on it.
>
> There is nothing to do. Just open the file in your editor and begin
> making changes. All the files should be writable already.
In my experience with people who come from source control tools that
follow the lock-modify-unlock scheme, it is helpful to tell there is in
fact a "Lock" command available in (Tortoise-)SVN, which will "suggest"
to other committers not to commit to this file right now (can be
overridden, i. e. the lock can be "stolen", though).
But that feature should only be used for changes that are inherently
hard to merge (like edits of binary files like images, or massive
refactorings that change few files completely), the lock should have a
sensible lock message that tells your coworkers why you need to lock the
file, and locks should be held only for short time periods.
That will make acceptance of the "new tool" easier, and after a few
months you won't see any locked files any more anyway :-)
> 5) Okay, I'm done making changes to one or more files. Now what?
>
> Unless you know that your changes don't affect anybody else right now,
> DO A BUILD FIRST and fix any errors.
If making the changes took you some time, preferrably do an update
before the build. Unlike other source control systems (don't know about
ClearCase), an update will not destroy your local changes. And you can
be sure to test your changes against the latest code available.
> 6) Commit failed! What now??
The most likely case for a commit to fail in my experience is not a
conflict, but just a file that was edited by someone else in a
non-conflicting way. To avoid that, update before you commit (or before
you build). If it happens anyway, TortoiseSVN will ask you if you want
to update and retry the commit. Just say yes and most likely the changes
can be merged automatically. It might be a good idea to re-run the build
before retrying the commit, though.
> If you are modifying a file that has been modified by someone else, the
> file will appear in red in the dialogue box. The commit will fail and
> your file will be altered. In this case, you should open the file in
> an editor and look for the strings "<<<<" and ">>>>". These mark places
> in which the file was changed in two inconsistent ways. Use the editor
> to fix up the problem, including getting rid of those special strings.
The "Edit conflict" dialog of TortoiseSVN is helpful for resolving
conflicts in a "visual" way. It will show two diffs, your changes and
their changes, and a unified view on the bottom how the resulting file
will look like. Conflicts are marked in red and can be browsed with the
red arrow icons on the toolbar. The context menu of a conflict includes
useful options like "Use my changes before theirs", or you can edit the
file directly in the bottom pane. But I guess it is a matter of taste if
you prefer to use the edit conflict dialog or search for the conflict
markers in your favourite editor.
> Build or otherwise test the file for correctness.
Especially after merging a conflict it is a wise idea to have a look at
the diff again to make sure you did not accidentally throw out changes
in your merge.
> Now you must instruct Subversion that the conflict has been resolved.
> Right-click on the repaired file and choose TortoiseSVN / Resolved.
The "Edit conflicts" dialog has a "Resolved" button too :)
> Click OK and try the commit process again. If it fails again, you
> probably forgot to mark the file as resolved, or there are other files
> whose conflicts have not yet been resolved.
(Edit conflicts can also be invoked from the context menu of the update
dialog after you received a conflict in an update; you don't have to
wait until you want to commit or open a commit dialog if you prefer to
fix the conflict right away. But I guess again a matter of taste.)
> 8) I want to rename a file.
>
> Right click on the file and choose TortoiseSVN / Rename. Type in the
> new name. The rename will happen at once locally, and will be sent to
> the server at the next commit. DO NOT USE simple Rename, or Subversion
> will get confused. Renaming directories uses the same procedure as
> renaming single files.
Depending on what files you manage, having a good IDE integration can
help you rename files inside the IDE.
In case you accidentally renamed a file the wrong way, you can either
rename it back and rename it again the right way, or in the commit
dialog select the old and the new entry (do not update in between or the
old entry will get loaded again and no longer shows up as modified) and
choose "Repair move" in the context menu.
> 10) Oopsie. I need a deleted file back again.
>
> Right-click on the directory containing the deleted file, and choose
> TortoiseSVN / Show log. Scroll down to the change that deleted the file.
> (You did write a commit message making it easy to spot, didn't you?)
> Right click on the last change made to the file before its deletion and
> choose "Browse repository".
>
> The file should be visible in the next dialog window. Right-click and
> choose "Copy to working copy". Save the file in the place where it
> belongs; it will appear to be a new file but will keep its history. Commit
> the change.
As often deleting a file will also result in changing some other code,
and you may want to change that code back as well, it is often easier to
choose "Revert changes from this revision", which will both give you
back all deleted files in that revision, and undo all the other changes
in that revision. The changes will be undone in you working copy so you
have to commit them to make them permanent (or selectively revert those
you don't want to make permanent).
> 11) I want to see diffs for a file.
>
> Right click on the file and choose TortoiseSVN / Diff or Diff with
> previous version. You will be shown different versions of the file side
> by side.
You can also double click a (not conflicted) file in the commit dialog
to view a diff. In case you have lot of files with only one or two lines
changed and want to check nothing else crept in, you can also obtain a
diff file for more than one file at once from the commit dialog.
> 12) I don't like the changes I made and want to revert them. They are
> not yet committed.
>
> Right click on the file and choose TortoiseSVN / Revert.
In some scenarios when lots of files need to be reverted, it may be
easier to just delete the files and then update the working copy to get
the old version back. Will not work with reverting deletion or addition
of files, though.
Also note that the diff viewer has a toolbar button to selectively
revert changed parts of a file if you only want to partially revert
changes from a file. In case you "accidentally" revert all parts this
way, the file will be reverted automatically.
> Any feedback will be greatly appreciated.
HTH,
Michael
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3037271
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-12-19 17:22:18 CET