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