Codestriker: collaborative code reviewer

I've committed this in. Since pegged versions have been available since
Subversion 1.1, I haven't bothered with the version check.

That makes sense. Ok - I'll make sure this gets committed in - thanks for
taking the time to explain this.

We had a topic that pointed to an URL that was later moved in the
repository. Trying to fetch the content of a file via "svn cat" with an
operative revision gave out an error saying that the path was not found in
a later revision. Using a pegged revision worked fine.

You probably right... just curious, can you tell me in your situation where
not using the pegged version is causing issues with a specific example?

I see. But here, the fix is in the "retrieve" method, which is used to pull
the content of a file for a specific revision, NOT in the method that
generates the diff (which means that the revision passed to "retrieve"
comes from the topicfile, not from the start_tag and end_tag entered by the
user). In this case, using the pegged revision seems to make more sense. If
we ask for the content of file@REV, without specifying an operative
revision, we're basically asking for the latest version of file, looking at
the given history line, which will return what we want.

Is there a case where "retrieve" would need to work on something other than
a pegged revision?

The semantics of using pegged vs operative revisions are actually a little
bit different: http://svnbook.red-bean.com/en/1.1/ch07s03.html.

Pegged revisions have been around since 1.1 - 1.5 allowed them for
svn:externals properties, but that doesn't affect us here.

To do this right - we really need to just support the user entering in
pegged revisions directly into the start and end tag, and making the module
argument optional.

This would allow people to create some pretty complicates diffs as a
result.