为什么我不能编辑SVN提交消息?


12

我正在使用SVN。有时,我在编写提交消息时会错过一些东西。但是一旦提交,就无法还原,甚至我也无法编辑该消息。为什么他们没有在其中添加编辑功能?


7
让我想起了thedailtywtf上Dave.cpp 的故事
猎鹰

1
只需使用git,它就可以合并提交,编辑消息以及对历史进行任何其他操作。
SK-logic

或者,如果不能,请使用git-svn,没有人会更明智。
Matthew Scharley 2011年

@Matthew:到底如何使用git-svn来使您能够在禁用历史记录编辑的svn存储库中更改历史记录?
gbjbaanb

2
@gbjbaanb:如果您已经推送到SVN服务器,则不会。但是,如果您只在本地提交,则仍可以在将提交消息推送到实时仓库之前更改提交消息。
马修·沙利

Answers:


15

根据SVN常见问题解答,如果存储库管理员已启用它,或者您具有对存储库的本地管理访问权限,则可以

但是,这样做可能不是一个好主意。实际上,您正在改变历史。版本控制的要点之一是维护项目的历史记录和审核跟踪。允许对历史记录进行任意更改会破坏审核跟踪。相反,我建议您执行较小的提交,编写简洁而明确的提交消息,并改善个人工作流程以防止这些错误。


4
@Matthew即使在git中,在我看来,随时改变历史也是一个可怕的主意。历史记录应作为审计跟踪,任何人都不得以任何理由在任何时候更改历史记录。
Thomas Owens

2
因此,对提交消息进行审核跟踪,因为通常更改提交消息的目的是使跟踪项目历史记录变得更加容易
彼得·泰勒

2
假设我发现一个月前输入的提交消息具有误导性,令人困惑并且完全错误。我是否应该能够添加一个更正的符号,以便看到错误消息的每个人都能看到?(我同意原始消息应该易于获得且未经修改,并且更改本身应该被跟踪并加盖时间戳。但是我不同意这构成了“不断变化的历史”。)
David Schwartz

2
错误的信息是不可接受的,因此,不得允许人们更正或澄清该信息,因为这将掩盖他们的渎职行为。哇。哇
David Schwartz

3
老实说,你看起来像是在自嘲。“它必须是正确的,因此绝不能加以纠正。”
大卫·史瓦兹

5

本质上,您必须具有(直接或间接)存储库的管理员权限才能执行此操作。您可以配置存储库以允许所有用户执行此操作,也可以直接在服务器上修改日志消息。

在此处检查SVN 常见问题

日志消息作为附加到每个修订版的属性保留在资源库中。默认情况下,提交日志消息属性(svn:log)后就无法对其进行编辑。这是因为对修订版属性(其中svn:log是其中之一)的更改导致该属性的先前值被永久丢弃,并且Subversion试图防止您意外地执行此操作。但是,有两种方法可以让Subversion更改修订版属性。

第一种方法是使存储库管理员启用修订版属性修改。这是通过创建一个称为“ pre-revprop-change”的钩子来完成的(有关如何执行此操作的更多详细信息,请参见Subversion的本节)。“ pre-revprop-change”钩子可以在更改之前访问旧的日志消息,因此它可以以某种方式(例如,通过发送电子邮件)进行保存。启用修订版属性修改后,您可以通过将--revprop开关传递给svn propedit或svn propset来更改修订版的日志消息,如以下任意一种:

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

其中N是要更改其日志消息的修订号,URL是存储库的位置。如果从工作副本中运行此命令,则可以省略该URL。

更改日志消息的第二种方法是使用svnadmin setlog。这必须通过参考存储库在文件系统上的位置来完成。您不能使用此命令修改远程存储库。

$ svnadmin setlog REPOS_PATH -r N FILE

其中REPOS_PATH是存储库位置,N是要更改其日志消息的修订号,而FILE是包含新日志消息的文件。如果“ pre-revprop-change”钩子不存在(或者由于某些原因要跳过钩子脚本),则也可以使用--bypass-hooks选项。但是,如果决定使用此选项,请务必小心。您可能会绕过诸如更改的电子邮件通知或跟踪修订属性的备份系统之类的内容。

从回答卡米尔Kisiel的响应堆栈溢出类似的问题


当您复制并粘贴来自stackoverflow的答案时,至少应将其标记为报价并归功于OP(在这种情况下为Kamil Kisiel)。链接到原始文件:stackoverflow.com/questions/304383/…请编辑您的答案,否则我将投票给您。
猎鹰

4

因为它是一个集中的版本控制系统 -提交更改(并且提交消息按照约定绑定到提交),所有对存储库具有读取权限的人都可以看到该信息。在信息传播后更改信息是一个坏主意,因为人们最终对“现实”持不同的观点。

像Git这样的分布式版本控制系统通过确保使信息可供他人使用的行为是原子的,并且没有诸如提交消息之类的任何其他信息,从而缓解了此问题。但是,同样的原则也适用于此:不鼓励您在本地更改已经可供他人使用的东西。


他们可能允许提交消息的多个版本……
Alex Feinman

1
@ l0b0在客观上更糟,继续传播虚假,误导或易于造成损害的信息吗?记录保存不需要包含不良数据。
user179700 2011年

1
@ user179700:是的。我见过的所有VCS都有一个根本上有缺陷的设计假设:提交有一条提交消息,这是不可变的。正如亚历克斯所说,我们应该“允许提交消息的多个版本”。
l0b0 2011年

@ l0b0我觉得这个问题越有趣,我就越思考。我的第一个反应是顺其自然,只是写得更仔细。当前的做法似乎阻碍了这一进程。我也想知道是否有其他系统可以实施更可靠的实践。是时候问另一个问题了。+1
user179700 2011年

@ user179700:我目前希望编写一个脚本,该脚本允许您更改提交消息,但是只能通过添加(带有时间戳)附加字符串来进行。这样一来,您就可以在保留审核记录的同时纠正错误。
Tynam'9
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.