Protect files from svn commit

Question

Hey, imagine a plain webapp with a log4j.properties which is under version control. I can't add it to svn:ignore because its a mandatory file. If i make custom changes for development and i don't want to commit them, i have to watch out for accidently commits. For one file it's easy to handle, with 3 or more files it becomes creepy.

Is there a way to disable these files temporary from svn commit? So its easiert to commit? I'm working with svn and subclipse.

Annulus

Answer 1

The typical way to handle situations like this is to do the following:

1. Make a copy of the file, under a name that indicates that it is a template
2. Commit the template to your repository
3. Ignore the original file

This way, you will have a fresh copy lying around, and during deployment you can copy the file back from the template to the real file.

This way you don't risk committing bad changes to this file, and at least for other version control system, you don't risk someone checking the file out and forgetting the lock.

There is no way in Subversion to indicate that a file is only-commit-first-time type of thing, so when you added it to your repository, you told Subversion to keep a track of changes in that file. Unless you manually make sure (or write a tool, or change your tools) to never commit changes to this file, Subversion will not help you.

Degrade

Ok, but isn't that very unconvinient for new workers to checkout the project and rename all these files to be able to boot the (thinking of wtp for example, where is no build script which can automatically rename the files)? – Annulus

Let me rephrase my answer. There is no way to get Subversion to do what you want. You basically have to pick which kind of inconvenience you want to use. I have no experience with "wtp". – Degrade

Answer 2

My solution to this problem was to create a new (kinda virtual) user on our svn server and add him to all projects, lets call him Locker. So I set a lock, as user Locker, on the configuration files which should not be modified in the code base.

Et voilà ! The files aren't committed by mistake anymore, however if the production system needs an update on the configuration files the lock can be forced by any team member or the files can be updated and re-locked by those aware of Lockers credentials!

Maybe it's not a solution for everyone, some company regulations may prohibit the use of proxy users.

Thriftless

Answer 3

The way I do this is to have files named log4j.properties.server, for instance, and then I have set up my deploy script to copy the .server files instead of the normal ones.

Porphyroid