Some files in our repository are individual to each developer. For example some developers use a local database, which is configured in a properties file in the project. So each developer has different settings. When one developer commits, he always has to take care to not commit his individually configured files.
How do you handle this?
Use SVN:Ignore (or its equivalent) to make sure they are not checked into your trunk branch.
Okay, but for example a db-config-file should be kept under version control and not be ignored.
We build or app using ant and our ant build files has a reference to a file name like this:
${env.COMPUTERNAME}-.properties
All of the properties in this file will override the properties in the main build file, if they exist. So developers can create an override file, named after their machine name, to override any of the properties that they like, for example database name and or jdbc url. This file can then be checked into version control
Our properties files are under a "properties" directory. Each developer has their own "username.properties" files which they can override properties in the environment-specific files such as "dev.properties", or "test.properties". This takes advantage of ANT's immutable properties (include personal first, THEN environment properties).
Don't keep them under version control, and use your tool's ignore ability to keep them from being accidentally checked in. Instead, version a script that generates them, which can use version-controlled data and local, non-version-controlled data. This keeps them up to date, while having any appropriate local modifications, without any danger of these modifications slipping back into the repository.
EDIT: some file formats have abilities to optionally use local overrides. These can be checked in, but in general, many aren't smart enough to do this. Hence this workaround.
They should absolutely be kept under version control. You can use an environment variable in the user's environment to detect the developer-specific properties. In ant, for example:
<property environment="env" />
<property file="${basedir}/online/${env.LOGNAME}.build.properties" />
<property file="${basedir}/online/${env.USERNAME}.build.properties" />
<property file="${basedir}/online/default.properties" />
If you have LOGNAME set to, say, 'davec' and davec.build.properties exists, it will override any values in default.properties.
This is also helpful for examining your co-workers configurations to get started or diagnose problems.
If they have to be in the same repository, create a "dev" folder or something and then a sub-folder for every developer to check in their user files.
Or have a separate repository for user files.
Or leave it up to the individual developer on what they do with their own files.
This was sort of answered in a previous post. While the question was more directed toward WebApps, the actual issue is exactly what you are facing now.
Our project is setup similar to others where you have some sort of properties file unique to the developer, however I do not believe that files specific to a single developer should be checked into source control.
We have a file personal.properties which is loaded and overrides any project default values. The file is located in the users home directory. For any values that are specific to the user, the default value is set like this:
database_user_name = DATABASE_USER_NAME_MUST_BE_SET_IN_PERSONAL_PROPERTIES_FILE
The file is never edited by a developer so no user-specific information is checked into source control and if a developer forgets to set the value in their personal.properties file you get an obvious error like:
Unable to login to database with username: "DATABASE_USER_NAME_MUST_BE_SET_IN_PERSONAL_PROPERTIES_FILE"
Keep a set of defaults in source control and then either:
have each developer have an optional set of configs that they manage themselves (eg. not kept in source control) or
have each developer keep their own configs in source control under some sort of identification scheme (username.properties like @Dustin uses)
The advantage of keeping the developer's specific configs in source control makes it easy to migrate from one computer to another (eg. in the case of a hardware failure or upgrade). Its a simple svn co [repos] and ant
Use templates, you don't add db-config to source control(actually you use SVN:IGNORE on him), and add db-config.tmpl or db-config.template or db-config.tmp or something else that clearly tells you it is a template.
This file has the basic configuration and is meant to be copied into 'db-config'(just copied leave the template there to receive updates) for each developer to customize.
Use git or another decentralized version control system. Then each developer can keep his private changes in his own private branch, work on that branch, and then cherry pick completed features back out of that branch into the main trunk of development.
We just keep a standard between developers. Everyone uses the same directories, database names and users, so we don't need to worry about those things.
Kind Regards