Replace SharpSvn library by svnlook.exe tool

[steffen-wilke]

Due to incompatibilities with SVN 1.10.x and slow development on the SharpSVN library, I've removed this external dependency from this library and replaced it by the usage of the default SVN tool svnlook.exe.

• Add a .gitignore file with a few common c#/vs ignores
• Implement possiblity to specify the binary folder that contains the svn binaries with -svnbin
• Implement fallback that uses svnlook via cmd.exe
• Add unittests for the string parsing functions of the SvnLook class
• Remove some unused properties from the IRepoChangeInfo and IRepoAffectedItem interfaces: -> They weren't used anyway and it would just bloat up the implementation with unnecessary stuff
• Tested post and pre commit hooks with a local 1.10.0 SVN repository and it worked. test cases included:
  • LogMessageCondition (min length, [No Reference] required,...)
  • ChangedPathCondition (forbidden areas)
  • MailInstruction

[BrightLight]

Hi @steffen-wilke. Thanks for your contribution. My issue with this PR is that is sort-of changes the spirit of how RepoCop was designed. The idea was that there is a "Core" for the actual evaluation (Silverseed.RepoCop.csproj; a DLL) and multiple executable implementations that decide on their own how they retrieve the data. The one implementation that currently exists is in the "Console" folder (Silverseed.RepoCop.Subversion.csproj) targets Subversion and uses SharpSvn to retrieve the metadata. You are now introducing a new/different way how to retrieve the data (via svn command line tools instead of SharpSvn). In my opinion this could and should simply be a second executable project (instead of replacing the existing one). Same as this: if at some point this project will target different repositories, there will be a new executable that targets that repository type (next to the executable for Subversion). It will not replace the Subversion executable.

So in my opinion, Console should be renamed to something like SubversionSharpSvn and your new executable could go in a folder SubversionCLT (CLT = command line tools).

Does that make sense?

[steffen-wilke]

Yes, I was also thinking about that option yesterday but it was a carefully taken decision and I decided against it for the following reasons:

1. In my eyes, there wouldn't be any actual benefit for keeping the sharpsvn implementation: The CLT version is capable of providing the same functionality because it is fully backward compatible.
2. It would be confusing for the user of this library to have two different Subversion implementations with different compatibilities
3. It would be necessary to always maintain the SharpSVN whenever they update it (if even).
4. I don't see any benefit from using the SharpSVN library other than maybe the fact that it doesn't require an SVN installation. But then I would wonder, why one would even use a SVNHook Plugin if there is no SVN server in place.
5. I think it's an advantage to have one less external library on which this framework depends on (especially since this library isn't currently actively developed)

I only see the necessity for additional maintainance work when keeping the SharpSVN implementation without any benefit for the user whatsoever.

If you still want me to provide a separate implementation, I can do so.