7

How do I remove a file from SVN version control?

  • It has previously been committed by someone unintentionally.
  • It is a needed local file, but different for everyone, and needs not be in version control.
  • If I delete & commit, it will delete the file for everyone.
  • I cannot add a file to svn:ignore while it is in the repo.
  • If I remotely remove & locally ignore & commit, it would work, but I cannot commit because I would have to update first, but if I update, the file is removed.

I would like to remove & ignore this file so it doesn't need to be always manually removed from every commit for everyone, without it being deleted locally at anyone.

The "solution" found here doesn't work: https://stackoverflow.com/a/2038639/579078

Community
  • 1
  • 1
ᆼᆺᆼ
  • 14,442
  • 8
  • 53
  • 87
  • 1
    I don't see the issue, as the file is generated. You delete it, commit and it gets deleted for everyone. Until they regenerate it. – Oded Mar 18 '12 at 19:41
  • 1
    "...if I update, the file is removed." –  Mar 18 '12 at 19:47
  • 1
    (And my nightmares usually revolve around the dreaded "Tree Conflicts", which I still have no idea how to create/solve, except that removing/adding files and directories always seems to be involved.) –  Mar 18 '12 at 19:51
  • Hm sorry for this confusion, it is indeed autogenerated, but only in SOME IDEs, and we use 3 different IDEs at least, so It's not ok to delete the file because at least one of them does not autogenerate it... – ᆼᆺᆼ Mar 18 '12 at 19:57

3 Answers3

3

TortoiseSVN has a feature called 'Unversion and add to ignore list' which can be found in the windows explorer context menu (if you have TortoiseSVN configured to show the context menu).

TortoiseSVN documentation article

Baldy
  • 3,583
  • 4
  • 32
  • 57
2

There really isn't any good way to accomplish this with SVN. About the best you can do is to warn users that they need to update in a certain way for the next update by copying the file out and then back in after the update.

Sometimes, the easiest (or only) way to work around technical issues is with "social engineering".

Lastly, I would highly suggest you switch away from SVN when you get a chance. The other options out there, like Mercurial or Git, are much more forgiving.

cdeszaq
  • 29,170
  • 25
  • 111
  • 169
1

Given that SVN isn't designed to allow this, the best approach might be a two step update wherein the first update renames the file to some unimportant name. Then, email the developers to let them know that after the update they will have to manually copy the file back to its original name. Then, once everyone has handled the update (or ignored it at there peril), you can remove the file from SVN and commit.

John Haager
  • 2,037
  • 1
  • 19
  • 22
  • Yeah but unfortunately some of the files involved is for example Eclipse's `.settings`, and for those people who use Eclipse, a delete coming from an SVN update will never suceed while Eclipse holds some files open in that dir. (And if the dir is renamed their Eclipse will autoregenerate it with some useless defaults) – ᆼᆺᆼ Mar 19 '12 at 22:19