Svn support

I've converted the indentation to 4-space tabs.

I removed the modifications to git URI handling.

Note, the SVN URI handling remains as a repository check as opposed to a regular expression of the URI. Since this part seems to be in flux in the Git support, I didn't take the time to write the equivalence of the code in GitVcsSupport.

It will go on to the next module.  To make it "fail" we could manually check if there are local changes before running "svn update".  But that has the problem where svn sometimes requires that the user update their local copy before committing changes to the repository.  This would force the user to go to that module, run "svn update", then commit their changes.  I think it's better to just run "svn update" within Pride.

The other possibility is to check for conflicts after "svn update" is run and return an error then, requiring the user to resolve conflicts before moving on.

Why do you want Pride to fail when svn update has conflicts?  If svn considers the command successful, wouldn't we want Pride to consider it a success and move forward?  I think if git and svn handle things differently, it's okay for Pride to handle git the way git does things and svn the way svn does things.  This way, if the user has all svn repositories, they will get the behavior they expect from svn.  Same for git. It's only when the repositories are mixed in a pride that the user would notice the difference... and the difference is in VCSes, not Pride.  This philosophy will also make it easier to add support for future VCSes.

When it comes down to it, I'll go with whatever decision you decide.  I like to argue the case that I think is best... and I'm perfectly willing to be convinced that the current case I'm arguing for is not the best.  What I really want is for software to be the best it can.

Last... I'm noticing there is this problem of the user knowing that a conflict exists.  If all updates are done silently and seem to succeed, the user may not know there is action they need to take to resolve conflicts.  This issue is complicated by having Pride continue from module to module even when conflicts exist.  But, if we are to detect conflicts and force Pride to stop, we could instead detect conflicts, continue to update all modules, and report the conflicts at the end of the Pride run in a summary of the results for each module update.