Source control is great. One of the nice features is that I know that I c开发者_如何学运维an go back to previous revisions in case something messes up.
However, I still find myself loathe to delete a large batch of code that is no longer necessary, but that I might want to use parts of in the future. It really has no business in the current code base. However, I don't like to delete it, because I don't have an easy way to trawl through my revision history and find it. I'll often cut + paste it and put it in files with such descriptive names as "unused" and "tmp", and they'll sit there for a while.
This problem would be solved if I had a great way to browse through the repository history / search for code from the past. Is there any GUI that lets me do this, or any easy to use process I can use? Is there any way to do this with TortoiseSVN? Right now the only approach I'd know to take is to checkout different revision numbers to see if the file I want is there, and that just takes way too lang.
What I like to do is add a tag: say "Codebase_before_removing_such_and_such_function". Then you can go into the Repository Browser in TortoiseSVN, browser to that tag, and dig into it to find the old file. Click on that file and select "open" to just see the code in that file.
You can also do the same by changing the Repository Browser to point to a particular revision rather than pointing to HEAD (and, again, then browsing to the particular file you want and opening it) but it's easier to tag because you can give tags meaningful names.
You can use svn command line, with the -v (verbose, showing changed paths) and --xml options, and pipe the result into XMLStarlet. This will allow you to filter by the deleted action, and show you revisions where files were deleted (which you can then pipe through grep to get the file you were looking for).
Example:
svn log -v --xml /path/to/repo | xml sel -T -t -m "//logentry/paths/path[@action='D']" -v "concat(../../@revision,': ',.)" -n
Sample Output:
103: /foo/deprecated.h
99: /foo/bar/badfile.hpp
Obviously, with svn log you can constrain that to a range of revisions (-r M:N), or range of dates (-r {date1}:{date2}), or last N revisions (-l C) .
The only downside is false positives due to the fact that SVN moves are really copy+delete.
Once you know the revision in which it was deleted, you can then use svn cat or svn export to look at the file:
svn cat /path/to/repo/foo/deprecated.h@102
Since deprecated.h was deleted in r103, I told svn to get the path to deprecated.h as it existed in r102 (prior to deletion).
You can do that by viewing changes in Tortoise SVN...however...
I personally prefer Mercurial.
When you are working in a group, you are able to commit locally as often as you please, then when you want to try to commit to the group solution you can merge everything. This way, no matter what happens during a merge, no data is lost because everyone has back up repositories on their hard drives, and the pre-merge version is available on the group repository. It also means that you can commit every time you make a change, regardless of whether or not it works, because no one else sees it until you push it to the group repo. I like to add rather lengthy comments to my commits, because it means I absolutely don't have to search for the right version.
It's a bit different than Tortoise (which I use at work), but definitely better as far as I am concerned.
精彩评论