Marking a file as "do not commit" for a repository (not locally) in Subversion?

Question

I'm wondering if there is some trick to keep a file in the repository that will be fetched by anyone checking out the repository, but that will never be committed to the repository unless some kind of explicit action is performed.

Basically, what I'm looking for is a way to have files with default values that can be modified locally without affecting the repository.

I know of two ways to kind of do this, but I'm looking for a better way:

1. Have the developers make a changelist that ignores the files on commit. (pro: the project compiles out-of-the-box, con: some developers might inadvertently check in changes related to their local configuration.)
2. Keep a copy of the file in the repository with an extension such as .default or .template, and have the developers copy it. (pro: no risk of checking in changes inadvertently, con: does not compile without copying the template files.)

Both of these solutions require additional action from the developers, and I'm afraid I can't trust that everyone will follow the correct procedures... Is there a way to make the process transparent to the developers?

Answer 1

Hi,

Unfortunatly, I've never seen an "easy and out of the box" way to do that.

I'm generally using your 2) solution, based on files with some kind of .default extension.

A solution that might be possible, though, is to use some pre-commit SVN hook, that would :

• check the list of files that are being impacted by the currect commit
• refuse the commit if some specific file is in that list

And, as a safety precaution, as you might, one day, need to modify one of those "not modifiable" files, you might want to add a test on the commit-comment :

• if it contains something like "FORCE COMMIT",
• then, do not refuse the commit, even if it impacts one of the files that should not be modified.

I've never tested this precise situation, but I've already seen pre-commit hooks used to ensure some conditions like "each commit must have a comment longer than X characters" -- so it should be possible...

For more informations, you can take a look at Implementing Repository Hooks and at pre-commit.

I just hope you can get the list of files that are affected by the current commit... looking at this article, it seems to be possible, using svnlook.

Answer 2

I would use your method #2, and then add defensive code to the application that checks the developer did the right thing to create the local file, and alerts them if they got it wrong.

If your project is like every other that I've worked on, there's probably a checklist of things a new developer has to get right before they have a valid working tree. Add this to that list, and make the application check its correctness as much as possible.

Answer 3

I am following your second method with a pre-build action which copies the files to the correct locations ,change the extension and modify it if necessary according to build configuration selected.In this method there is no risk of accidental commit and the project builds out-of-the-box.