删除 SVN 提交的所有痕迹 [英] Delete all traces of a SVN commit

问题描述

我们团队中有人不小心将包含密码的文件提交到我们的存储库.密码不能轻易更改.

有没有办法在拥有完全管理员权限的情况下删除此提交的所有痕迹?我不是在谈论恢复或删除，这显然会将密码保留在文件历史记录中.

解决方案

是的，但它不适合胆小的人.您必须使用 svnadmin dump 和 svnadmin load 来重新创建您的存储库.

如果您选择这样做，第一步是阻止您的用户提交，并备份您的存储库.我还建议您完成存储库副本上的步骤；您可以使用 rsync 将整个存储库目录复制到一个临时目录中，然后从那里开始工作.

对于这些说明，我将在临时目录中创建一个新存储库:

tmp, 502>svnadmin 创建 example.repotmp，503>svn co file://`pwd`/example.repo 示例已检出修订版 0.

我创建了一个包含四个修订版的文件，其中第 3 个需要删除:

示例，536>svn 日志测试.txt-----------------------------------------------------------------r4 |新闻中心 |2011-04-06 08:46:59 -0400(2011 年 4 月 6 日，星期三)|1 行错误提交后-----------------------------------------------------------------r3 |新闻中心 |2011-04-06 08:46:42 -0400(2011 年 4 月 6 日，星期三)|1 行修改错误-----------------------------------------------------------------r2 |新闻中心 |2011-04-06 08:46:28 -0400(2011 年 4 月 6 日，星期三)|1 行很好的修改-----------------------------------------------------------------r1 |新闻中心 |2011-04-06 08:46:02 -0400(2011 年 4 月 6 日，星期三)|1 行初步修订-----------------------------------------------------------------

因此，我们需要在错误之前和之后转储修订，使用 -r 标志来指定修订范围.第二个转储上的 --incremental 标志很重要，因为它会告诉 load 命令不要创建新文件.

请注意，我是从保存存储库的同一目录中运行这些命令的.

svnadmin dump -r 1:2 example.repo/>svndump文件* 转储修订版 1.* 转储修订版 2.tmp，552>svnadmin dump -r 4:4 --incremental example.repo/>svndump文件* 转储修订版 4.

现在将原始存储库移开，并创建一个同名的空存储库:

tmp, 540>mv example.repo example.repo.baktmp，541>svnadmin 创建 example.repo

并导入转储文件的内容.

tmp, 569>svnadmin --quiet load example.repo <svndump文件tmp，570>svnadmin --quiet --ignore-uuid 加载 example.repo <svndump文件

现在告诉大家删除他们的工作目录并检查新的.您应该会看到以下日志:

示例，574>svn 日志测试.txt-----------------------------------------------------------------r3 |新闻中心 |2011-04-06 08:46:59 -0400(2011 年 4 月 6 日，星期三)|1 行错误提交后-----------------------------------------------------------------r2 |新闻中心 |2011-04-06 08:46:28 -0400(2011 年 4 月 6 日，星期三)|1 行很好的修改-----------------------------------------------------------------r1 |新闻中心 |2011-04-06 08:46:02 -0400(2011 年 4 月 6 日，星期三)|1 行初步修订-----------------------------------------------------------------

有一个巨大警告:此过程假设自错误提交以来没有对文件进行任何提交(即，后继转储仅包含对其他文件的更改).

如果不是这种情况，您仍然可以删除修订版，但需要做更多的工作.您需要创建一个新的签入，其中包含文件的干净副本以及在损坏时随它更改的任何其他文件.然后创建多个转储文件，排除包含错误文件的任何修订版.

最后:我强烈建议进行几次试运行.正如你在我的例子中的历史数据中看到的那样，我搞砸了几次.正如我在开头所说的，将 Subversion 存储库复制到临时目录中很容易.当你这样做时，你可以继续尝试直到你做对了，然后只需将固定存储库复制回原位.

Someone in our team accidentally committed files containing a password to our repository. The password can't easily be changed.

Is there a way, with full admin permissions, to delete all traces of this commit? I'm not talking about a revert or delete, which would obviously keep the password in the file history.

解决方案

Yes, but it is not for the faint of heart. You have to use svnadmin dump and svnadmin load to recreate your repository.

If you choose to do this, the first step is to stop your users from committing, and make a backup of your repository. I also recommend walking through the steps on a copy of your repository; you can use rsync to copy the entire repository directory into a temporary directory, and work from there.

For these instructions, I'm going to create a new repository in a temporary directory:

tmp, 502> svnadmin create example.repo
tmp, 503> svn co file://`pwd`/example.repo example
Checked out revision 0.

I created a file that contained four revisions, the 3rd of which needs to be deleted:

example, 536> svn log test.txt 
------------------------------------------------------------------------
r4 | kgregory | 2011-04-06 08:46:59 -0400 (Wed, 06 Apr 2011) | 1 line

post-bad commit
------------------------------------------------------------------------
r3 | kgregory | 2011-04-06 08:46:42 -0400 (Wed, 06 Apr 2011) | 1 line

bad revision
------------------------------------------------------------------------
r2 | kgregory | 2011-04-06 08:46:28 -0400 (Wed, 06 Apr 2011) | 1 line

good revision
------------------------------------------------------------------------
r1 | kgregory | 2011-04-06 08:46:02 -0400 (Wed, 06 Apr 2011) | 1 line

initial revision
------------------------------------------------------------------------

So, we need to dump revisions both before and after the bad one, using the -r flag to specify revision ranges. The --incremental flag on the second dump is important, because it will tell the load command not to create a new file.

Note that I'm running these commands from the same directory that holds the repository.

svnadmin dump -r 1:2 example.repo/ > pred.svndump
* Dumped revision 1.
* Dumped revision 2.
tmp, 552> svnadmin dump -r 4:4 --incremental example.repo/ > succ.svndump
* Dumped revision 4.

Now move the original repository out of the way, and create an empty repository with the same name:

tmp, 540> mv example.repo example.repo.bak
tmp, 541> svnadmin create example.repo

And import the contents of the dump files.

tmp, 569> svnadmin --quiet load example.repo < pred.svndump 
tmp, 570> svnadmin --quiet --ignore-uuid load example.repo < succ.svndump 

Now tell everyone to delete their working directories and check out fresh. And you should see the following log:

example, 574> svn log test.txt 
------------------------------------------------------------------------
r3 | kgregory | 2011-04-06 08:46:59 -0400 (Wed, 06 Apr 2011) | 1 line

post-bad commit
------------------------------------------------------------------------
r2 | kgregory | 2011-04-06 08:46:28 -0400 (Wed, 06 Apr 2011) | 1 line

good revision
------------------------------------------------------------------------
r1 | kgregory | 2011-04-06 08:46:02 -0400 (Wed, 06 Apr 2011) | 1 line

initial revision
------------------------------------------------------------------------

There is one HUGE caveat: this process assumes that there haven't been any commits to the file since the bad commit (ie, the successor dump only contains changes to other files).

If that's not the case, you can still delete the revision, but it's a lot more work. You need to create a new check-in, containing a clean copy of the file along with any other files that were changed with it while bad. Then create multiple dumpfiles, excluding any revisions that contained the bad file.

Finally: I strongly suggest several dry runs. As you can see from the history numbers in my examples, I screwed up a few times. As I said at the beginning, it's easy to copy a Subversion repository into a temporary directory. And when you do that, you can keep trying until you get it right, then just copy the fixed repository back into place.

这篇关于删除 SVN 提交的所有痕迹的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！