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?
3 Answers
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.
answered Sep 1, 2011 at 11:18
-
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 ♦Sep 1, 2011 at 12:07
-
2So 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. Sep 1, 2011 at 12:14
-
3Suppose 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".) Sep 1, 2011 at 15:14
-
3Wrong information is unacceptable, therefore people must not be permitted to correct or clarify that information, as that would hide their malfeasance. Wow. Just wow. Sep 1, 2011 at 16:04
-
4You are honestly begin to look like a self-parody. "It has to be correct, therefore it must never be corrected." 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.
-
-
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. 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".– l0b0Sep 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 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.– TynamSep 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" URLwhere 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 FILEwhere 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.
answered Sep 1, 2011 at 11:42
-
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.– FalconSep 1, 2011 at 11:52
git-svnand noone will be the wiser.