Suppose you check out the top-level of the Subversion repository with --nonrecursive, so you just get the
README, INSTALL, HACKING files etc, but none of the subdirs.
Now you have a flat, one-level working copy with just some files.
Currently, if you run svn update in that working copy, everything goes to pot. The update state report is incorrect:
the client doesn't tell the server anything about subdirs (because the client has no record of any subdirs, neither on
disk nor in the entries file), so the server assumes that the client has revision X of the entire tree, where X is whatever
the client got when it checked out.
Depending on what has changed in the repository since X, various sorts of errors will happen at this point. No need to go into it, you can use your imagination.
So what is the desired behavior?
Nonrecursiveness should be sticky. That is, when you check out something --nonrecursive, the local wc directory created should remember that it is a nonrecursive tree, and tell that to the server in state reports, so the server doesn't try to send updates for anything not that directory level.
How would the working copy record this? Probably by setting an attribute on the `this-dir' entry, plus recording all the
subdir entries with a similar attribute on them.
So svn update in this working copy would behave non-recursively by default; but if you pass the --recursive flag, then it
clears those attributes and fetches everything. That way, the intention expressed in the initial checkout is honored, until
the user says otherwise.
This also implies that the --recursive vs --nonrecursive state variable in the client needs to become a three-state enum: --default, --recursive, and --nonrecursive.