3

svn commit from the command line pulls up my editor for me to write a commit message. Then if the message is empty it asks 

Log message unchanged or not specified
(a)bort, (c)ontinue, (e)dit:

I never use (or want to use) the continue or edit options. And, since I usually run the commit in the background, having to remember to fg it in order to answer the question is annoying. I regularly get the bash: a: command not found error.

I would like svn to not ask and always abort (like git does). Is there a configuration option for this?

Edit: I am using a repository at work that I share with more than 1K other developers and I am not an admin. So I need the auto-abort to work without modifying the server or its configuration.

Eponymous
  • 6,143
  • 4
  • 43
  • 43

2 Answers2

3

You can use a pre-commit hook to abort on empty commit messages. It's not too difficult, and I believe Subversion comes with a template pre-commit hook that does this.

Use the svnlook log command to pull up the commit comment. If it's empty, you can exit with a non-zero exit code and the commit won't work. You can also print something to STDERR which the committer will see, so they know why their commit was rejected. Something like this:

log_message=$(svnlook -t $TXN log)
if [[ -z $log_message ]]
then
    echo "Your commit message was empty. Recommit with a commit message" 1>&2
    exit 2
else
    exit 0
fi

I have a pre-commit hook that is a way more powerful, and can set who has permission to modify or add particular files, that properties are set correctly, and that the commit message is in the correct format. you can take a look at that.

David W.
  • 105,218
  • 39
  • 216
  • 337
  • [This answer](http://stackoverflow.com/questions/4798201/client-side-pre-commit-hooks-in-subversion) implies that I'd have to do this server-side. Since there are about 10K other users of the repository (one of whom will surely be inconvenienced) and I'm not an admin anyway, I'd like to have this happen client-side, only for me. (I'll edit my answer to make this constraint clear.) – Eponymous May 13 '15 at 20:38
  • @Eponymous - Client side hooks are usually a bad idea because for the hook to work, it must know of the client's configuration. For example, if I write a Python or Perl hook, and either an older version of Python or Perl are installed (or not even installed), my hook won't work. Or, the client environment could be manipulated to get around the hook. This is why Subversion uses server hooks. – David W. May 14 '15 at 13:50
  • @Eponymous - If you use TortoiseSVN, you can write your own _client side_ hook. This hook will only work via TortoiseSVN and not via the command line or via Eclipse. I've written a Bash function called `svn`. In most cases, my function merely passes the various parameters to the actual `svn` command. However, in cases where the first parameter to the function is `co` or `commit`, I verify that there is an `-m` parameter, and that the `-m` parameter has a log entry. This way, I use the `svn` function just like the `svn` command and still have the option to call the real `svn` command directly. – David W. May 14 '15 at 13:55
2

There is no configuration option for this. Any requirement being imposed upon a commit must be performed via a hook script on the server.

If this is only for your own usage, you could write your own shell script which performs your checks for you before calling the svn binary to perform the commit. But this will fall apart if you use any other client on your system (like an IDE plugin).

alroc
  • 27,574
  • 6
  • 51
  • 97
  • That sounds like I'd have to duplicate the svn binary functionality of creating the temp file, extracting status, opening the editor, storing the temp file somewhere if the commit fails, etc. Lots of effort. This feature is probably a very simple 20 line patch to the main executable. Do you know how willing the svn developers are to take patches from the community? – Eponymous May 13 '15 at 21:03
  • They're open to patches if they align with the direction of the project. Look at the API, you may be able to re-use functionality that's already there. But I'd suggest asking on the mailing list first, to gauge how likely it is that they'll accept it. – alroc May 13 '15 at 22:22