Hi, I hope this is not just a dumb user question in case I missed the functionality. I will describe a use case that I think would benefit from the ability to delete things from a working copy without deleting them from the server. If that ability is already there, I apologize and are thankful for the pointer.
I am making heavy use of svn's partial checkouts. We got a big tree of scripts or configuration and various instances of working directories that only have parts of that present. One particular application is a repository where each user of the repository checks out only the parts that are in actual use. It starts out empty: svn co --depth empty $repo_path . and then, if a specific thing is needed I so svn up --parents foo/bar to only have the relevant files and directories for _this_ instance. I also do on-the-fly branching via svn copy ^/root/foo/bar foo/baz work on baz and then commit it. The idea here is that foo/bar doesn't even appear in the working copy as it is not part of the deployment here. One caveat is that I need to do svn up --depth empty foo first, as svn copy --parents ^/root/foo/bar foo/baz will create _another_ local foo that will give a nasty conflict on attempting to commit. I wonder if this could be considered a bug, though. I expected this to mean 'ensure that parents exists as in the repository', not 'create and add local paths as necessary, disregarding repository'. Now, if I did checkout part of a tree that is not really supposed to be part of the deployment, or which was supposed to be part of it but not now, I'd like a clean way to remove that from the working copy, without touching the repository. I see svn rm --keep-local but wonder if we could have svn rm --keep-remote too? Is this something tricky to do with the current wc format? I guess not. Maybe I could implement it, given a starting point. This would make svn a lot more useful for me. I think improving the support for partial checkouts of a big file tree is important for Subversion. Apart from properly recording renames, this is a main feature that makes me use it and not just give in to git everywhere. Subversion is my versioned file system. I know I could do a repository branch for each instance that now is a working copy, but this would be unnecessary noise for my setup, and also I do not want to encourage actual divergence of the versioned contents, only give each working copy its selection of parts of the tree. Alrighty then, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg