CODEWITHSUNDEEP
javaversion-control
cretzel
cretzel

Reputation: 20164

How do you handle developer individual files under version control?

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?

Upvotes: 7

Views: 1045

Answers (13)

marcospereira
marcospereira

Reputation: 12214

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

Upvotes: 2

skiphoppy
skiphoppy

Reputation: 102803

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.

Upvotes: 0

levhita
levhita

Reputation: 2171

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.

Upvotes: 0

Chris Gow
Chris Gow

Reputation: 7924

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

Upvotes: 3

Alex B
Alex B

Reputation: 24936

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"

Upvotes: 0

Spencer Kormos
Spencer Kormos

Reputation: 8441

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.

How do you maintain java webapps in different staging environments?

Upvotes: 0

wnoise
wnoise

Reputation: 9932

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.

Upvotes: -1

Mark Cidade
Mark Cidade

Reputation: 99957

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.

Upvotes: 0

davetron5000
davetron5000

Reputation: 24841

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.

Upvotes: -1

DustinB
DustinB

Reputation: 11284

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).

Upvotes: 4

Kevin
Kevin

Reputation: 1247

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

Upvotes: 2

cretzel
cretzel

Reputation: 20164

Okay, but for example a db-config-file should be kept under version control and not be ignored.

Upvotes: 0

Steve Moyer
Steve Moyer

Reputation: 5733

Use SVN:Ignore (or its equivalent) to make sure they are not checked into your trunk branch.

Upvotes: 2

Related Questions