I'm using SVN. Sometimes I miss something when I write a commit message. But once it's been committed, it cannot be reverted, and even I can't edit the message. Why they didn't put the edit function in it?

  • 7
    Reminds me of the story of Dave.cpp on thedailtywtf
    – Falcon
    Commented Sep 1, 2011 at 11:21
  • 1
    Just use git, it allows to merge commits, edit messages and do whatever else you like with your history.
    – SK-logic
    Commented Sep 1, 2011 at 12:07
  • Or if you can't, then use git-svn and noone will be the wiser. Commented Sep 1, 2011 at 12:15
  • @Matthew: how on earth with git-svn enable you to change the history in a history-editing-disabled svn repo?
    – gbjbaanb
    Commented Sep 1, 2011 at 12:22
  • 2
    @gbjbaanb: It wouldn't, if you've already pushed up to the SVN server. But if you've only commited locally, you can still change the commit message before pushing it into the live repo. Commented Sep 1, 2011 at 13:15

3 Answers 3


According to the SVN FAQ, you can if the repository administrator has enabled it or if you have local administrative access to the repository.

However, doing this is probably a bad idea. You are, in effect, changing history. One of the points of version control is to maintain a history and audit trail for the project. Allowing arbitrary changes to the history defeats the audit trail. Instead, I would recommend that you perform smaller commits, writing concise yet explicit commit messages, and improving your personal workflow to prevent these errors.

  • 4
    @Matthew Even in git, changing history at any point is, in my opinion, a terrible idea. The history is supposed to serve as an audit trail and should never be changed by anyone at any point ever for any reason.
    – Thomas Owens
    Commented Sep 1, 2011 at 12:07
  • 2
    So have an audit trail for the commit message, because usually the purposes of changing the commit message is to make it easier to follow the history of the project. Commented Sep 1, 2011 at 12:14
  • 3
    Suppose I discover that a commit message I entered a month ago is misleading, confusing, and downright wrong. Shouldn't I be able to added a correcting notation that will be seen by everyone who sees the incorrect message? (I agree the original message should be easily available unmodified and the change itself should be tracked and timestamped. But I disagree that this constitutes "changing history".) Commented Sep 1, 2011 at 15:14
  • 3
    Wrong information is unacceptable, therefore people must not be permitted to correct or clarify that information, as that would hide their malfeasance. Wow. Just wow. Commented Sep 1, 2011 at 16:04
  • 4
    You are honestly begin to look like a self-parody. "It has to be correct, therefore it must never be corrected." Commented Sep 1, 2011 at 16:29

Because it's a centralized version control system - As soon as you commit a change (and your commit message is by convention bound to the commit), everybody who has read access to the repository can see that information. It is a bad idea to change information after it has been disseminated, because people end up with a different opinion of "reality."

Distributed version control systems like Git alleviate this problem by making sure that the act of making information available to others is atomic and without any additional information like commit messages. But the same principle applies here: You are discouraged from changing things locally which you have already made available to others.

  • They could allow multiple versions of the commit message... Commented Sep 1, 2011 at 14:22
  • 1
    @l0b0 isn’t it objectively worse to continue to disseminate information which is false, misleading, or prone to do damage? Record keeping does not require enshrining bad data.
    – user179700
    Commented Sep 2, 2011 at 7:10
  • 1
    @user179700: You're right. There is a fundamentally flawed design assumption in all VCSes I've ever seen: A commit has one commit message, which is immutable. As Alex says, we should "allow multiple versions of the commit message".
    – l0b0
    Commented Sep 2, 2011 at 10:29
  • @l0b0 I’m finding this question interesting the more I consider it. My first reaction was along the lines of, just write more carefully. The current practice seems to hamstring the process. I too wonder if any other systems implement a more robust practice. Time for another question methinks. +1
    – user179700
    Commented Sep 2, 2011 at 14:50
  • @user179700: I'm currently hoping to write up a script which allows you to change a commit message, but only by adding a (timestamped) additional string. That lets you correct mistakes while preserving audit trail.
    – Tynam
    Commented Sep 4, 2012 at 17:02

Essentially you have to have admin rights (directly or indirectly) to the repository to do this. You can either configure the repository to allow all users to do this, or you can modify the log message directly on the server.

Check the SVN FAQ here.

Log messages are kept in the repository as properties attached to each revision. By default, the log message property (svn:log) cannot be edited once it is committed. That is because changes to revision properties (of which svn:log is one) cause the property's previous value to be permanently discarded, and Subversion tries to prevent you from doing this accidentally. However, there are a couple of ways to get Subversion to change a revision property.

The first way is for the repository administrator to enable revision property modifications. This is done by creating a hook called "pre-revprop-change" (see this section in the Subversion book for more details about how to do this). The "pre-revprop-change" hook has access to the old log message before it is changed, so it can preserve it in some way (for example, by sending an email). Once revision property modifications are enabled, you can change a revision's log message by passing the --revprop switch to svn propedit or svn propset, like either one of these:

$svn propedit -r N --revprop svn:log URL 
$svn propset -r N --revprop svn:log "new log message" URL 

where N is the revision number whose log message you wish to change, and URL is the location of the repository. If you run this command from within a working copy, you can leave off the URL.

The second way of changing a log message is to use svnadmin setlog. This must be done by referring to the repository's location on the filesystem. You cannot modify a remote repository using this command.

$ svnadmin setlog REPOS_PATH -r N FILE

where REPOS_PATH is the repository location, N is the revision number whose log message you wish to change, and FILE is a file containing the new log message. If the "pre-revprop-change" hook is not in place (or you want to bypass the hook script for some reason), you can also use the --bypass-hooks option. However, if you decide to use this option, be very careful. You may be bypassing such things as email notifications of the change, or backup systems that keep track of revision properties.

Answer from Kamil Kisiel in response to a similar question on Stack Overflow.

  • When you copy paste an answer from stackoverflow, you should at least mark it as a quote and give credit to the OP (Kamil Kisiel in this case). Link to the original: stackoverflow.com/questions/304383/… Please edit your answer or I am going to downvote you.
    – Falcon
    Commented Sep 1, 2011 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.