Does any version control system have a "persistent local only change" feature?

Question

This question occurred to me whilst playing around with git, but I'll ask the general case...

I just thought of a feature which might be nice for version control, but I don't know if it exists or what it is called. I want to call it persistent local changes.

Say I have a config file in svn, which has lots of useful non-recreatable stuff (and so must be in version control), but has one section which everyone needs to edit for themselves. Maybe a database config, or a username and password, or the local path to some 3rd party software. Your options in this situation are

1. Edit wars in version control. Just keep changing the file and hope that everyone else gives up editing the file before you do.

2. Edit it, but never commit those changes. They just sit there making your "What's new/changed" command look dirty, and you have to remember to not commit it.

3. Template it. Remove the file from version control and check in a copy of it with .template on the end. Locally copy the file and rename it back, with your changes in.

4. Use the new (fictional?) persistent local change feature. Make your change then issue the record-changes-as-local-persistent command, which figures out a patch, and after every update reapplies your patch.

Does this feature exist anywhere (it feels like git stash, but the purpose is slightly different)? If it doesn't exist, is there a good reason why not? (has someone thought about it and decided it was a bad idea?)

Answer 1

You can do this in git with a master (or "vendor") branch and a local branch. Your local commits go on the local branch, and you rebase that on top of master when it changes. If you don't specify a remote for the local branch you won't be able to push it accidentally; if you accidentally commit something you want persisted to the local branch, just cherry-pick to master and push from there.

Answer 2

You can ignore any configuration file from the version control. It's the .gitignore file.

For example if you want to ignore all your log directory, you add a line to that file with :

log/*

To ignore the .DS_Store file, you add a line with :

.DS_Store

You can then update the file locally, you will never see it in the modified but uncommitted files. And if you do a git add ., it won't be added to the commit.

If you need to put your configuration file to git but only keep one password or var somewhere out of it, what I do is calling a distant file inside that configuration file. And this file contains my password.

On a rails project for example, my database configuration looks like that :

production:
 database: project_database
 username: database_user
 password: <%= File.read('path/to/my/password/file').chomp if File.readable? 'path/to/my/password/file' %>

The file "path/to/my/password/file" is not in version control.
So my configuration file is versionned. But the password depends of the machine on which we are.

It also has the advantage of not having the passwords in your version control to be read by potentially anyone.

Answer 3

This might be a little more specific to Visual Studio but I assume most IDEs will have some similar feature.

In all of my app/web configs that have settings that change for different enviroments I split them into their own files so that my main config looks like this

  <dataConfiguration configSource="Config\Development\dataConfiguration.config" />
  <connectionStrings configSource="Config\Development\connectionStrings.config" />
  <appSettings configSource="Config\Development\appSettings.config"/>

Then for each file it's similar to

<?xml version="1.0" encoding="utf-8" ?>
<dataConfiguration defaultDatabase="defaultDatabase"/>

After that I create folders for each environment Dev/Staging/Prod etc and use a different sub config file in each folder so all the settings can be checked into TFS. I have my web deployment project setup to pull in the appropriate files per release configuration. Later when I configure TFS to manage my releases this can easily be achieved by just having it copy the correct config.

At this point you can check in a baseline for the program and then when developers need to change things for themselves only that they don't plan to check in they can easily just make the file not readonly and edit it.