views:

91

answers:

3

Source control is great. One of the nice features is that I know that I can 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.

+4  A: 

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.

JacobM
how do you do named tags in tortoisesvn? i saw the "copy (branch / tag)" option but that seems to copy the entire repo. I just want to mark a particular revision with a name - or can I only do that in git?
Claudiu
You use the branch/tag option. It looks like it copies the entire repo, but it doesn't actually; it's just tagging the revision and pointing to it. Use it-- it does what you want.
JacobM
oo awesome, just what i wanted.
Claudiu
A: 

You can do that by viewing changes in Tortoise SVN...however...

I personally prefer Mercurial. http://mercurial.selenic.com/

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.

badpanda
I've used git so I know some of the benefits of distributed version control. However you're addressing a different issue. Even with Hg or Git, it's annoying to find an old file and look at it (although github does a pretty good job w/ it)
Claudiu
Hmm it is always annoying, but I tend to find it much easier with Mercurial because I commit much more often locally, and am specific with my comments. That way I simply have to find the right revision and run through the correct class, rather than checking like 4 different commits, which is somewhat similar to the tag idea that JacobM proposed. Sorry if I didn't connect the dots on that one ><
badpanda
A: 

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).

jason.rickman