0

We use svn (version 1.6.11) to check-out only files to working copy we are working on. With check-in these files will be deleted locally. But if I do a svn status I get listed up all deleted files with: !

Is there a way to delete the files in this way, that they also vanish in the status list?

I found one answer here to delete the files in entries file of .svn directory, but manually editing is not suitable for me.

To my research there seems to be no other way to do so, but is there a way to do it automatically? I cannot read this file. Do you have a link to a documentation of this file structure.

Besides in entries the file (name) is also in text_base directory (easy to delete as file) and in all-wcprops (deletion can be scripted: starts with file name and ends with END).

Do you have a better solution?

Community
  • 1
  • 1

1 Answers1

2

You can remove that file using svn update:

svn update <your file> --set-depth=exclude

This will remove the file from your working copy and updating will not pull it back down unless you do so explicitly:

svn update <your file> --set-depth=infinity

This is a feature known as sparse directories.

Note that this feature only worked for directories prior to version 1.7 by design.

Patrick Quirk
  • 23,334
  • 2
  • 57
  • 88
  • Thanks Patrick, unfortunately exclude does only work with directories. Then all files inside the directory of working copy are deleted, but one may like to check-in only one of two locally changed files. – Matthias Bonn Mar 07 '16 at 12:52
  • Maybe it's a new feature since 1.6 but `--set-depth=exclude` **definitely** works for just files as well. I just tested it using 1.9 on my machine. – Patrick Quirk Mar 07 '16 at 13:28
  • 1
    Thank you! I looked in the bug fix list and this feature works since 1.7. So I have to start a request to update the client at our company. – Matthias Bonn Mar 07 '16 at 14:08
  • Good find! I've updated my answer to include a link to the specific issue. Also, SVN 1.6 will be 6 years old in April and there's no good reason not to update the client since [backward and forward compatibility is fairly strict](https://subversion.apache.org/docs/community-guide/releasing.html#release-compat) and always documented. – Patrick Quirk Mar 07 '16 at 14:20