command line - SVN: Is there a way to mark a file as "do not commit"?

Question

With TortoiseSVN, I can move a file into the ignore-on-commit changelist, so that when I commit a whole tree, changes to that file do not get committed.

Is there a way to do something like that using the svn command-line tool?

EDIT: Thanks for the suggestions to use svn:ignore, but that doesn't do quite what I was looking for.

svn:ignore affects things like svn add & svn import. It gives it a list of filename patterns to ignore.

I have a file that's already under source control, but I want to make temporary changes to that file that I don't want to be committed later on when I commit the whole source tree. I am making a lot of other changes and I could stick a note on my monitor telling me to revert that file before I commit the tree, but it would be nice if svn could automatically skip that file.

Answer 1

Subversion does not have a built-in "do not commit" / "ignore on commit" feature, as of February 2016 / version 1.9. This answer is a non-ideal command-line workaround

As the OP states, TortoiseSVN has a built in changelist, "ignore-on-commit", which is automatically excluded from commits. The command-line client does not have this, so you need to use multiple changelists to accomplish this same behavior (with caveats):

• one for work you want to commit [work]
• one for things you want to ignore [ignore-on-commit]

Since there's precedent with TortoiseSVN, I use "ignore-on-commit" in my examples for the files I don't want to commit. I'll use "work" for the files I do, but you could pick any name you wanted.

First, add all files to a changelist named "work". This must be run from the root of your working copy:

svn cl work . -R

This will add all files in the working copy recursively to the changelist named "work". There is a disadvantage to this - as new files are added to the working copy, you'll need to specifically add the new files or they won't be included. Second, if you have to run this again you'll then need to re-add all of your "ignore-on-commit" files again. Not ideal - you could start maintaining your own 'ignore' list in a file as others have done.

Then, for the files you want to exclude:

svn cl ignore-on-commit pathofile-to-ignore

Because files can only be in one changelist, running this addition after your previous "work" add will remove the file you want to ignore from the "work" changelist and put it in the "ignore-on-commit" changelist.

When you're ready to commit your modified files you do wish to commit, you'd then simply add "--cl work" to your commit:

svn commit --cl work -m "message"

Here's what a simple example looks like on my machine:

D:workspacerunk>svn cl work . -R
Skipped '.'
Skipped 'src'
Skipped 'srcconf'
A [work] srcconfdb.properties
Skipped 'srcjava'
Skipped 'srcjavacom'
Skipped 'srcjavacomcorp'
Skipped 'srcjavacomcorpsample'
A [work] srcjavacomcorpsampleMain.java
Skipped 'srcjavacomcorpsamplecontroller'
A [work] srcjavacomcorpsamplecontrollerController.java
Skipped 'srcjavacomcorpsamplemodel'
A [work] srcjavacomcorpsamplemodelModel.java
Skipped 'srcjavacomcorpsampleview'
A [work] srcjavacomcorpsampleviewView.java
Skipped 'src
esource'
A [work] src
esourceicon.ico
Skipped 'srcest'

D:workspacerunk>svn cl ignore-on-commit srcconfdb.properties
D [work] srcconfdb.properties
A [ignore-on-commit] srcconfdb.properties

D:workspacerunk>svn status

--- Changelist 'work':
        srcjavacomcorpsampleMain.java
        srcjavacomcorpsamplecontrollerController.java
        srcjavacomcorpsamplemodelModel.java
M       srcjavacomcorpsampleviewView.java
        src
esourceicon.ico

--- Changelist 'ignore-on-commit':
M       srcconfdb.properties

D:workspacerunk>svn commit --cl work -m "fixed refresh issue"
Sending        srcjavacomcorpsampleviewView.java
Transmitting file data .done
Committing transaction...
Committed revision 9.

An alternative would be to simply add every file you wish to commit to a 'work' changelist, and not even maintain an ignore list, but this is a lot of work, too. Really, the only simple, ideal solution is if/when this gets implemented in SVN itself. There's a longstanding issue about this in the Subversion issue tracker, SVN-2858, in the event this changes in the future.