Subversion: prevent local modifications to one file from being committed?

Question

I have a Subversion working copy where I made some local modifications to one file. The modifications are only relevant to me, I do not want to commit them. (The version in the repository contains some default values which are suitable for the other users, just not for me, which is why I want to override them locally.)

Note that although I do not want to commit my changes, I do want to receive any updates made in the repository when I do svn update. Also, it is only in my working copy that I do not want to commit the changes to that file, the other users should not be affected. So svn:ignore or commit hooks do not fit my purpose.

Currently, I simply do:

svn commit file1 file2...

where I specify explicitly the files that have changes excluding the particular file that I do not want to commit.

However, while I'm working, I have the habit of simply writing:

svn commit -m "Log of what I just did"

and I fear that I will inadvertently commit the "forbidden" file by using the above command at a moment when I'm not attentive.

In short, what I'm looking for is simply a way of "marking" a file in a working copy which prevents Subversion from committing the changes in that file (it doesn't have to be automatic exclusion, even if I just get an error when I try to commit all files, it is fine). Sort of like marking files in a "conflict" state...

Does such a thing exist?

Update: akent, thanks for pointing out this very similar question.

Answer 1

There have been a few answers that can work:

1. Create a pre-commit hook script that reject the commit when a specific property is being added. You can then add this property to files in the working copy to prevent commits.
2. TortoiseSVN will exclude files in the special changelist "ignore-on-commit". However, this is not honored by the SVN command-line client.

CoverosGene suggested that the default commands such as svn commit operate on a default changelist, such that you can exclude a file if you assign it to another changelist, but I can't find any reference of that in the documentation, and in my testing this does not work.

Since there is no good solution for the SVN command-line client, I've opened an enhancement request here. The request suggests that the command-line client could also honor the "ignore-on-commit" changelist.

Update: This is now issue 2858 and there is a feature outline to handle it with an svn:hold property.

Answer 2

Create a changelist with that file in it, and then just pay no attention to the changelist. The file will sit there waiting to be committed, but your regular commits, which work on the default changelist, will never pick it up.

svn changelist mylocal file1

will create a changelist called mylocal and assign the file file1 to it.

Answer 3

I understand the problem you're having; probably this "forbidden" file contains configuration settings and the like that are only relevant to your local build environment. I've not found any way directly to tell SVN just to ignore changes in a versioned file, but here's a workaround I've used in the past.

Assuming your file is called, say, "build.conf". Name the SVN versioned file something like build.conf.example. Then, in your Makefile or build script or whatever, you can automatically copy the build.conf.example to the real build.conf, which remains unversioned. Then you svn ignore build.conf and each developer can then make any local changes they need to it.

But "there must be a better way"...

Edit: Almost identical question here: SVN: Is there a way to mark a file as "do not commit"?

Answer 4

Actually, a pre-commit script would do the job.

Write a pre-commit script that executes 'svnlook diff' and rejects the commit if there is a property named 'nocommit' being set in the changeset.

Then, in your working copy, you can just set a 'nocommit' property on any file that shouldn't be committed. Any subsequent commit will fail if any file has the 'nocommit' property. If you later do need to check in changes on the file, all you have to do is remove the 'nocommit' property from your working copy.

Answer 5

Speaking of Tortoisesvn and changelists, it already comes with a changelist called ignore-on-commit, which does what you are looking for.

Answer 6

From my experience: don`t put that file under version control and use svn:ignore on it.

It’s a little hard at the beginning, since you cannot ignore a file that is allready under version control, and you cannot remove a file from version control without removing it from hard drive (and from every working copy on next update...). But when you finally manage to set up the repo correctly, it works like charm. Don’t forget to add a generic-template in place of your original config file (so that everyone knows about new config variables, and so on).

For new repo:

mkdir config
svn add config
svn propset svn:ignore '*.conf' config 

For existing repo: be sure, to have a backup of your config in every working copy, then remove (svn del) config from the repo, commit (please note: the file will be deleted in every working copy on next update! you have to have a backup) and then restore the file and set the ignore property.

Another way is a lock. It guarantees that noone commits the file, but it will result in an error on every commit. not very nice.

And the third way - changesets, a new feature in SVN 1.5 clients. This is neat, but it’s only related to one working copy, not to a repository globally. And you have to set them up manually, add every new file — it’s hard to maintain.

Answer 7

For the last several years I have been using a simple solution which achieves exactly what you are looking for. It is called the NOCOMMIT keyword.

What I do is that I have a pre-commit hook in my SVN repository which checks to see whether any file contains the string NOCOMMIT, and if so, it fails the commit.

So, when a programmer makes a modification that should not be committed, (say, they changed the project-wide database connection string from the company-wide test server to their own local test server, or they added diagnostic debug statements that are going to be spamming the log with thousands of lines per second,) they append a //NOCOMMIT comment to it, and they do not have to worry about accidentally committing it. When the time comes to commit, they are prevented, so they are forced to either:

• move that file to their do-not-commit changelist, or
• search for NOCOMMIT and remove any occurrences of it, thus hopefully fixing the code that they had attached it to.

Personally, I find the NOCOMMIT keyword so useful that I use it even when working on pet projects of mine, where obviously, I am the only programmer in the team.

If you are using windows, you can paste the following text into file called pre-commit.bat in the hooks folder of your SVN repository.

:: Stops commits that contain the NOCOMMIT keyword.
setlocal  
set REPOS=%1  
set TXN=%2           
SVNLook diff %REPOS% -t %TXN% | findstr /I /M /L NOCOMMIT > nul
if %errorlevel% gtr 0 (
    exit 0
) else (
    echo Your commit has been blocked because it contains the keyword NOCOMMIT. 1>&2  
    exit 1
)

On Unix systems, something like the following should do the trick, though please note that I have not tested it.

#!/bin/sh
REPOS="$1"
TXN="$2"
SVNLOOK=/usr/local/bin/svnlook
$SVNLOOK diff -t "$TXN" "$REPOS" | grep -i "NOCOMMIT" > /dev/null && { echo "Your commit has been blocked because it contains the keyword NOCOMMIT." 1>&2; exit 1; }

Answer 8

Lock certainly isn't what you want, and I don't think any of the built in features will do it for you.

Depending on which environment you are working in, I'd write a script that:

1. Gets the list of files
2. Removes the ones I don't want to commit
3. Commits the files

Something along the lines of:

svn status | grep ^M | grep -v exclude.c | awk -F' ' '{print $2}' | xargs svn ci -m "I'm committing something"

Or if the list of files is really static, just fix the list!

Answer 9

If you're on Windows, use TortoiseSVN. You can add files to the special "ignore-on-commit" changelist that behaves exactly as you described.

Answer 10

This question is in the Subversion FAQ. But the answer is not very helpful if you do not control the repository.

Maybe try to manage your local copy with git on top of subversion. There is a simple course for git available. You can then use git-svn for tracking changes in svn repository and for commiting your changes. It will need some learning and training through.

Answer 11

Add all files to a changelist and then remove the files you do not want to commit. Finally commit the changelist as shown below:

$ svn status
M file01 
M ...
M file100
M file_not_ready_for_commit

// This will add all working copy files, can be adjusted to add only relevant files
$ svn changelist mychangelist -R .

// Remove the nascent one(s)
$ svn changelist mychangelist --remove file_not_ready_for_commit

// Commit only the files in the changelist
$ svn commit --changelist mychangelist

Source of above information is this blog which also has a link to http://svnbook.red-bean.com for further details. All credits to the author of the blog.

Answer 12

You can use a pre-commit hook. In the hook use svnlook author to see if you are the one committing the changes. If so, use svnlook changed to see if you are changing one of the forbidden files.

Answer 13

You can use a personal branch and switch that file for this effect. Like this:

 svn cp ^/trunk ^/branches/your_name -m "Creating a personal branch."    
 cd working_copy_of_trunk/sub_path/
 svn switch ^/branches/your_name/sub_path/your_file your_file

Note that:

1. You can check the switched status with the 'S' appearing on the fifth column with command: svn status
2. You will never work on the branch, your working_copy_of_trunk still is synchronized against the repository trunk directory except the files you have switched, so whenever you commit changes on your_file, commits for that file will be done on your branch and not on the trunk.

3. The copy have been done complete server side, and this is the recommended way with svn. Complete server side copy is instantaneous and will not spent extra space on the server. However, it is also recommended that people do not checkout the top directory containing trunk/ tags/ and branches/ but directly trunk/ otherwise all files will be duplicates locally when updating from this top dir. If this is the case rather subtitute the first command with :

   svn cp --parents ^/trunk/sub_path/your_file ^/branches/your_name/sub_path/your_file

   Finally if for any reason you do not want to copy your file elsewhere on your repository server, then you may still combine this approach with an external server and svn:external keywords (not really recommended).