Is there a way to make TortoiseSVN temporarily ign

问题:

We have certain configuration files which we want to be in version control as they specify project's default settings: search path, conditional defines etc. Unfortunately these files are also used by the IDE (Delphi 5) to hold temporary information. The IDE continually updates the files during development which causes Tortoise to flag the working directory as modified all the time even though all that might have happened is a build of the project. Sometimes we do genuinely want to commit changes to these files, for example if the projects search path dependencies change, but the grand majority of the time they are just a source of noise.

My first thought was to check the files out, apply a global ignore pattern in TortoiseSVN to ignore the offending files types and remove the global ignore when I have made a genuine change to the code I want to check-in. It appears however that if a version of a file is already in the repository, Tortoise will not ignore it.

Is there a way that I can set this up so that
1) The files get pulled in during a checkout
2) There is some means of ignoring changes to these files
3) There is an way of checking in significant changes to the files if required

回答1:

The general solution to allowing local modifications to version-controlled configuration files is not to keep the config file itself under version control, but to version a template of it, e.g. with .template appended to the filename.

The first time a developer checks out the project, they make a copy of this file, removing the .template from the filename of the copy. Then they add the copy (the non-template) to the ignore list to ensure it is not accidentally added or committed.

Any changes that are made to the config which need to go into version control, must be made to the template. And each time a developer updates and finds a change in the template, they must again follow the copy/rename procedure. But hopefully this will not be often.

回答2:

Since version 1.5, TortoiseSVN has supported change lists allowing you to group files together within the commit dialog. TortoiseSVN provides one special change list, called ignore-on-commit, that "is used to mark versioned files which you almost never want to commit even though they have local changes." See Excluding Items from the Commit List for more.

To use the ignore-on-commit feature, within the Check for Modifications or Commit dialogs, select one or more files, then on the context menu select change lists >> ignore-on-commit. The result is that those files are now grouped together and when you open the Commit dialog files in the ignore-on-commit group are by default unchecked while all other files are checked. Be aware that once you check in files in a change list, they are removed from that change list; TortoiseSVN assumes the group membership is no longer needed. In this case, though, since you are not checking in items from the ignore-on-commit group, I believe this group will persist indefinitely.

(I started writing this answer 3+ years after the question was posed with the intention of saying now there is an easy way to do this. But I could not resist doing some checking first. It turns out that the answer I just provided was available as of TortoiseSVN 1.5 which was officially released as of June 2008--thus, my answer was applicable when this question was asked as well.)

回答3:

No, I don't think that is possible. A solution might be to put the "canonical" version of these files into some subdirectory such as "idefiles", which gets checked in, but not used by the IDE. The files in use by the IDE can then be deleted from the repo and ignored.

If you want to check in "important changes", just copy them to "idefiles".

Only disadvantage:

On first checkout, people must remember to copy stuff from "idefiles" to the proper location. But first checkouts are usually rare...

Also, if "idefiles" changes, changes must be manually copied into the read IDE files. But that might be useful (dev might not want local config to be overwritten).

BTW, the problem of "config files in version control" has been discussed before, e.g.:

How to store configuration parameters in SVN?