I was at the opposite end of this question, it was my responsibility to commit code to an SVN instance my client had set up. Neither I nor the other contractor on the project could ever get SVN to work properly. It got to the point where we were zipping the code and emailing the project to the customer, and leaving it up to them to sort it out.
My 'workday' is about 3 to 3.5 hours. This is how much time I spend at the computer coding, and it's how many hours I bill. Since I work out of my house, I spend some time doing laundry, making tea, running around getting lunch or haircuts or cars fixed, etc. And, of course, perusing questions on boards, including SE and LinkedIn.
At various times I have mentored people, often quizzing them over dinner on matters related to programming, business, science, etc. As I did this I got better and better at explaining things. I remember dozens of times when I was trying to explain something I would come to a realization on the spot, something tangential to the explanation but nevertheless a useful insight. Often these were of critical importance later. Among the things I got from this is learning how to communicate with non-technical people, and how to be patient with people that are doing their best under the circumstances, but are in over their head.
Your contractor may simply be doing things however (s)he thinks they should be done: they've been micromanaged before and pretty much tune it out. They could either spend time explaining to you why they do it the way that they do it, or they could just get it done. They've been told it has to be done by a particular date, they probably knew at the start it wasn't going to happen, so they're producing at the natural rate of code development. I was told on one project that I had to be done by a legislative deadline six months hence; 18 months later I was finished. If you fire them and hire someone else with the same deadline, you'll get the same results if the problem simply can't be solved in the timeframe you're demanding.
In short, when people are contracting out of choice, it's usually so that they can 'make their own rules'. They have generally discovered that they can do their best work by freeing themselves from what would be routine concerns as employees: 'drop ins' from users or co-workers, detailed procedures by managers, 'all-hands' meetings, baked-Alaska cubicles, etc.
Some contractors can explain this if their customers are listening, others aren't so good at it. There is nothing wrong with asking for the code, but if SVN is creating problems just have them send you an archive and you can split it out to a duplicate project folder. I never have a problem showing my work; however there are some people that get highly defensive when a manager asks for routine progress updates. In that case the contractor is probably not doing their job at all.
Treating Contractors the same as Employees
A lot of contractors would like to be employees - they consider the 'arms length' relationship to be unfortunate. Usually this is true when they are seeking benefits like vacation and health care, don't mind the 8:00 to 5:00 routine, and would like to believe the employer will keep them around for years. These people tend to work on site, make their desks look like full timers, and get weird when managers don't keep them up to date on renewal status. When you find these, treat them like employees, and when possible, make them so.
When the contractor prefers to work at home, seems to have little patience with bureaucracy, and has fingers in multiple pies, they aren't wannabe employees. They're only one step away from starting their own company and hawking their own product. These are best treated as highly independent consultants.
'Over The Top'
The particular point you brought up wouldn't bother me, it is a reasonable request. However, being asked to do little things all the time is bothersome, particularly when it breaks up concentration. I'm used to spending chunks of time focused on a problem, which in some cases is days. I've been in work situations, both as a contractor and as an employee, where the working environment was so full of interruptions I couldn't make forward progress.
Signs Nothing Is Being Done At All
From time to time, employers run into people that don't have a snowball's chance of working out.
One example was a civil service employee responsible for administering some servers. This individual was both silent and reclusive, to the point of being a hikikomori. The base was set to close, and this individual succeeded in finding work with a major private employer in town. He handed over his passwords on his way out the door on the last day of his employment. We discovered nearly immediately is that he had done nothing during the entire term of his employment.
In short, in software and systems administration, silence is not golden. Real programmers tend to be noisy, they insist the programming language they use is the greatest, they'll argue over databases and processor architectures and browsers and whatever. In a group of like minded people, they tend to complain about bosses, users, working associates, vendors, and help sites. Note what percentage of users on this board are IT related.
I picked up a client that was in desperate straights. Originally the two developers sat at a computer in the client's office and muddled through the design issues required to get a medical billing system to work. Eventually, however, they did progressively more of their 'work' in their rural compound and avoided any presence on site. They were charging a certain amount of money for 'support', what this consisted of was coming in once a month to re-index files. I was unable to locate the source code, which they had agreed in the contract to leave on-site. When they gave us their copy, it was on a different disk capacity from the ones in the client's office - we had to go through other people in town to get the files transferred. In short, they had simply moved from development to milking the client, and real issues remained unresolved, such as in particular changes in Medicare billing forms. It took me about six weeks to fix the critical issues - from there on out I was making other enhancements that kept me busy and made the doctor's office more productive.
The third story is a bit of hearsay - I had been hired to replace someone that had found other opportunities. The most senior manager on this project would have lunch with me from time to time, and after a few months of work he told me the circumstances under which the previous employee had left. Her job was basically to fix some FoxPro code that was out of date - the system had severe performance problems and some stuff was buggy. When I looked at the code it was a bit bewildering, the backend was SQL Server (6.5) using stored procedures. This was non-Y2K compliant, so we were under some pressure. At any rate, after she had been there a month the senior manager had dropped in on her to get a status update, she took offense at the question and said basically 'Why are you bothering me? I quit!'. With that she walked out the door.
It was my opinion, after working on the FoxPro stuff for a few days, that it was unmaintainable, and we should just write the new system in VB6 and be done with it. As it turned out, the real performance issues were with the server, which we replaced with a significant upgrade. Had she made the project manager aware of the difficulty of maintaining the code, and the constraint imposed by the server, it's unlikely she would have felt put on the spot a month later when the boss asked for status.
For someone to take this personally meant that she either had no idea what she was doing at all, or didn't feel like she could discuss refocusing development efforts to better effect. I tend to suspect the former, since the people in our group were just trying to find the best way to get the contract delivered.