They don't actually sound like someone doing any real work.
> Why do I need to download 500 files in a project if I'm only going to edit 3 of them
Either their project structure sucks and they combine a lot of unrelated items together, or this guy is just an manager/architect who isn't making any significant changes but wants to poke in the codebase.
Why do you need to download the entire project? So you can build/compile/launch it and view/test your changes. Are we just talking about a README.md file here?
The author is in devops[1], which intuitively seems like the sort of job that would have that 'not making any significant changes, just working on single files' type of flow that isn't the same flow as a standard dev approach (where it's common to work across an entire repo). So it's understandable from that perspective that they might come to that conclusion.
Put another way, in a software product, you bring down those 500 files because you want to locally make sure that your changes to the 3 files you care about are compatible with the 500 files you don't. In a dev-ops repo, perhaps they are dealing with a situation where small amount of files they deal with have less impact on the whole.
I'm in DevOps and this desire to view an entire repository through the small lens of a few files concerns me, specifically for the reasons you call out.
> In a dev-ops repo, perhaps they are dealing with a situation where small amount of files they deal with have less impact on the whole.
Do they not test against the real thing and assume their test cases hit every corner case?
Edit: Also as a DevOps person it is your responsibility to make sure things work well. If this is onerous for you and you're not doing anything to make it better and instead are trying to shy away from the reality of working with the reposit, you're doing your job wrong.
I was making some large assumptions and reading through the lines that they have repos that track many products where particular folders / files have zero overlap with the whole. Or perhaps they have situations where they're working on configurations that can only be tested by deploying them and not by local tests. There's lots of reasonable reasons for only needing to be concerned with a portion of a repo. I'm giving the author the benefit of the doubt as the expert in their own job that they are in one of those reasonable situations.
If you're working on any kind of team doing work in parallel.. Just dont bother with SVN.
Got can get into strange states sometimes but I've never not been able to fix it. I don't personally find the same difficulties as the author though.