On Thu, Nov 21, 2024 at 5:25 AM Dr. Thomas Orgis < thomas.or...@uni-hamburg.de> wrote:
> 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'. 'svn up --depth empty foo' ensures that you have the foo object in your working copy that corresponds to foo in the repository, while any command that creates foo in your working copy is creating a new and distinct object, hence the tree conflict. It's an interesting thought that if some command is going to create foo in your working copy and foo already exists in the repository, then perhaps you really want the foo that exists in the repository, but that would change how the Subversion client works in a fundamental way that is incompatible with current expectations. For example, 'svn mkdir foo' is expected to create a new empty directory foo, and if the user wasn't aware that a directory foo already existed in the repository, a tree conflict is preferable here, as opposed to just silently merging the directories. 'svn copy --parents' is the logical equivalent of running 'svn mkdir' to create each missing directory along the way, the same as if you created them manually. By running 'svn up --depth empty foo' you are explicitly telling Subversion that you want the same foo that exists in the repository, not a new and distinct foo that happens to share the same name. So, no, it's not a bug. But here's a suggestion: if this is a workflow you do often enough, you could implement a script that performs these actions? Perhaps there are additional repetitive steps you could automate? More below: 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. There is 'svn update --set-depth=exclude foo' which will exclude foo from your working copy (i.e., delete foo from your disk without affecting the repository). It sounds like that is what you're looking for. 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 Hope this helps... Cheers, Nathan
