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.
The typical way to handle situations like this is to do the following:
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.
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.
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.
