Question

what I’d like to do is have files in a central location so that when I add people to my development team they can see the base version of these files but meanwhile have the ability for the rest of the team to work with their own local version.
I know I can just put the files in source-control (we use Tortoiese-SVN) and have my team change the local versions but I’d rather not as the exclamation mark signaling the file has been changed and needs to be committed, quite frankly, irritates me greatly.
I’ll give two examples of what I mean:

1. We use quite a few build.xml files which relate to a single properties files which contains many definitions. Some of them can be different between team-members (mainly temporary working directories) and I’d like a new team-member to have the ability to get the properties file with the base config but change it if they wish.
2. Have the eclipse settings file in the SVN so that when a new team-member joins they can just retrieve the files from the server and have a base system running. If they wish they will be able to change some of these settings.

Thanks,
Ittai

Answer 1

What I have done in the past is having the file in a different location or with a different name inside the repository with an ignore real_file rule so that the subversion will not complain on the changed file, and have a small script that will copy the files to the concrete location.

For example, the .project Eclipse project file can be named eclipse-project-default in the repository. When a user downloads the local copy they run the script and they get a fresh .project (copy of eclipse-project-default) that they can change and will not show in the subversion status command.

The problem with this approach is that it is often easy to make a change to the file that should go to the central repository and is forgotten. The approach requires changing the actual file, and applying the same change to the config file that is actually uploaded. And then commit that change.