I probably have underwear older than you.
Don't bet on it. I myself have been in the programming game for over two decades
I have no Subversion anywhere except on a Linux server.
On your Linux server you have will be running a Subversion server.
On you local machine you will be connecting to this Subversion server using a Subversion client.
In your case the Subversion client is most probably TortoiseSVN but it is still a client.
In the case of AgentSVN, it connects to the server using the svn.exe Subversion client.
Do I need to get and install a local version on my Windows 7 system?
Yes.
This link contains the Subversion client installer:
http://sourceforge.net/projects/win32svn
Now what might be creating some confusion is the svn.exe has a bit of a split personality.
The svn.exe is a client but it can also connect to a file protocol SVN repository without needing a Subversion server.
In other words by creating a local machine repository using the file protocol, means you can basically run Subversion without needing a full blown Subversion server.
This is one of the reasons I suggest doing all the initial testing with this type of setup.
In the directory I created on my C: drive (C:\QA_SC_Repository) I see folders conf, db, hooks, and locks, as well as README.txt and a format file.
Did you create this usg the AgentSVN Configuration Utility.
The AgentSVN does not actually create the SVN repository, but instead it uses the svnadmin.exe tool that comes as part of the Subversion client installer mentioned above.
Has the local repository has been created?
If you did create the repository using the AgentSVN Configuration Utility then you will now have an empty SVN repository.
If you did not, then just delete the repository and use the AgentSVN Configuration Utility to create the repository.
I navigated and executed the Agent SVN Configuration from the Start menu.
That is the tool I am talking about.
The SVN Project Manager field was left blank, I enter "C:\QA_SC_Repository" in the Folder field, and "C:\program files\collabnet\subversion client\diff.exe" "$f1" "$f2" in the Command line field, and the protocol field was set to "Local File(file://)". I already described my entries in the SVN Ignore field.
That sounds perfect.
Now if you delete the C:\QA_SC_Repository folder then open up the Configuration Utility it will create a new repository for you.
The svn.exe we obtained from CollabNet and it is version 1.7.4. The subversion version is 1.6.6, according to the server admin.
This may well cause issues.
If CollabNet changed the database schema between these two version then that client will not work with that server.
But using the local test described above, that will not matter at this time since you will not be going anywhere near that Linux repository.
You will be talking to your local repository.
Given those details, I opened an existing TestComplete project from my Y: drive, that I want to put inot my new repository C:\QA_SC_Repository.
Unfortunately you will not be able to do this, because this is not how Subversion works
For the Subversion client to work it must have a valid working copy.
Now your Y: working copy will be pointing to your Linux Subversion repository and there will be now way you will be able to point it to the C:\QA_SC_Repository repository.
If instead you follow the seven steps that I outlined what should happen is this:
1) AgentSVN will create the local repository
2) AgentSVN will import a new project into the repository
3) AgentSVN will create a valid working copy for that project
For this testing stage you will need to create a new dummy test project, or you will need to remove the svn details found in that folder.
Now you don't want to be removing svn details from you y: folder because you will be corrupting that working copy.
It is much easier, much safer to just create a new test project.
As I said before, once you are sure AgentSVN and TestComplete actually working, only then it is time to try to connect to a real Linux svn repository.
At this point I do not know what to enter in the fields.
What is happening is you are confusing AgentSVN and svn.exe.
On the one hand you are pointing AgentSVN to the empty SVN repository is found here: C:\QA_SC_Repository
On the other hand you are then opening a TestCase project that contains a valid SVN working copy and that working copy is pointing to the Linux SVN repository.
So to have any chance of getting this to work you have to either:
1) Forget doing any local repository testing and connect directly to the Linux Server
2) Forget the Linux Server for now and do the much simpler local machine repository test
As I said befor IMHO the second option is the simplest and easiest option.
Cheers Jussi