0

We have a number of developers for some projects locally and we'd like to include our Eclipse Workspace settings when we first check the project in so that future developers can check them out and have it all set up and ready to go.

However, if they use Eclipse and are doing work, we don't want them constantly updating this folder and checking the files back in because many of the preferences they might change are simply cosmetic in nature and who's to say who's right?

Thus, we have checked in the project and the workspace files, but when we go to do any sort of "ignore" on the folder after that point, it wants us to delete the folder or the files from SVN.

We don't want to delete them from SVN - just have them ignored after they're checked out without affecting the SVN Repo. Basically Project/.settings would never prompt for a file to be checked in or show that it is changed.

A Senior Programmer might later update that folder, but not any of the junior ones.

Dracorat
  • 1,184
  • 7
  • 12
  • Perhaps. I just read that link (thanks for providing it) and its two years old and didn't have any solution other than "sorry you can't". Maybe you still can't. That would make me sad. – Dracorat Aug 15 '14 at 20:06
  • Actually, the accepted answer has two solutions: *"1) Create a pre-commit hook script that reject the commit when a specific property is being added. You can then add this property to files in the working copy to prevent commits. 2) TortoiseSVN will exclude files in the special changelist "ignore-on-commit". However, this is not honored by the SVN command-line client."* – ThisSuitIsBlackNot Aug 15 '14 at 20:08
  • Solution 1 allows the files to show in Tortoise SVN and even encourages devs to try to commit them, at which point they're only rejected at the last moment by this gatekeeper, which isn't exactly desirable. Solution 2 is a per-client customization. We could do it if necessary, but if someone doesn't do it (which they have to do extra to checking the solution out) then they'll be committing their changes back. We effectively now have to track (check in to another repo path?) a second file for the sole purpose of making our repo behave as we desire? – Dracorat Aug 15 '14 at 20:14
  • 1
    Unfortunately, most of the solutions to this are hacks, because project settings aren't really supposed to be versioned. You've probably already seen it, but [this answer](http://stackoverflow.com/a/951066/176646) to another similar question says it best: "The answer is: don't put that file under version control. Instead, put a template of the file under version control, something like 'file.tmpl'. Then, after the initial 'svn checkout', have your users (or your build system) do a normal OS copy of the template to the proper filename, and have users customize the copy." – ThisSuitIsBlackNot Aug 15 '14 at 20:31
  • Alright, thanks. Less than ideal but we will deal with it I guess. – Dracorat Aug 16 '14 at 18:16

0 Answers0