There is no reason, NONE WHATSOEVER, for updating SVN (or any other source code repository) with code that does not compile.  There are 2 rules for version control that are both #1:

1. Check code in frequently
1. Don't check projects in unless they compile

Some argue that this isn't a good practice (1 #2 above) but let me explain.  Let's say you are working on a distributed team and there are 3 people working on a project.  Team members 1 & 2 are working on a class library for a web project.  They figure they are done for the day and check in the code that they worked on. Team member 3 (me) wants to check out this class library when working on a new & unrelated project.

I add this library to my project, do my thing, build. WTF? 57 Errors and 2 warnings.  I should see 0 Errors and 2 warnings.  Warnings are usually harmless and a lot that I have seen lately stem from converting 1.x websites to 2.0, 3.5 projects and usually have something to do with obsolete code (which is still compatibile).  So now there are a couple of problems.  First of all, I have to get my project to compile, which means fixing YOUR code.  Then, I have to check the code in that I fixed. Then, I  have to recompile my project and continue to try and be in a good mood while I am pissed that I had to waste anywhere from 5 minutes to sometimes an hour or more (then I get really pissed!).

"Well I didn't want to write the method that reflects my object and creates an instance of T."

You don't have to. This will do:

public static T GetRecord<T>(List<IDbDataParameter> parameters, string commandText)
{
   return Activator.CreateInstance<T>();
} 

Or the following if you don't want the possibility of bugs slipping through the cracks due to incomplete data (which will never happen if you implement some sort of Unit Testing Framework but that is a whole other topic).

public static T GetRecord<T>(List<IDbDataParameter> parameters, string commandText)
{
   throw new NotImplementedException("Not done yet");
} 

Another beef is when people add references to .DLL's that will break the build.  Adding .DLL references is commonplace, especially if you use 3rd party solutions or existing class libraries.  This can break builds also.  I learned this after making a mistake once where I downloaded a control to my desktop and added the reference from there.  The next person to check out my code didn't have that assembly on his desktop and it broke his build.  A workaround for this is to have a Dependencies folder within a project that is the central location for all these add-on assemblies.  That way when a developer adds a reference the next person who checks the code out (or updates their existing codebase) will be able to hit the ground running.

Again, code doesn't have to be bug-free or work like it's supposed to.  As long as it compiles when I update my code I am happy.  It is impossible to check in code that works as it should every day (i.e. conversion projects).