如何避免子文件夹上的 svn:mergeinfos ?

发布于 2024-08-16 03:12:16 字数 276 浏览 12 评论 0原文

我们尝试仅将“svn:mergeinfo”属性保留在根分支文件夹上。然而,我们不断看到它蔓延到子文件夹中。我们已经能够确定一些可能的原因:

  1. 在存储库浏览器中移动文件夹
  2. 在 IntelliJ 中移动和/或重命名包
  3. 使用旧的 svn 客户

端任何人都可以提供我们不应该做的事情的列表,以避免通过以下方式创建这些属性事故?

我们使用的工具是 IntelliJ 8(即将推出 9)、Ankh、TortoiseSVN 和 SlikSvn。

We try to keep the 'svn:mergeinfo' property on the root branch folder only. However, we keep seeing it creep into subfolders. We've been able to identify some possible causes:

  1. Moving a folder in the repo-browser
  2. Moving and/or renaming packages in IntelliJ
  3. Using old svn clients

Can anyone provide a list of things we should not do in order to avoid creating these properties by accident?

The tools we are using are IntelliJ 8 (soon 9), Ankh, TortoiseSVN and SlikSvn.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

长安忆 2024-08-23 03:12:16

不幸的是,旧的 svn 客户端就是这么做的,任何基于这些旧版本 svn 的工具也都被破坏了。解决此问题的唯一方法是在提交之前删除创建的 svn:mergeinfo 条目。由于大多数人不知道它们是被创建的,因此强制执行这一点的唯一真正方法是预提交挂钩,或者只是简单地这样做:

svn propdel --recursive svn:mergeinfo $ROOT/*

时不时地清理它们。执行此操作时要小心,因为它会破坏您已完成的部分合并的任何记录,因此只有在您确实不进行部分合并时才应该执行此操作。提问者不知道,我们所处的环境也不知道。

该问题已在较新的 svn 客户端中得到解决,因此问题应该会慢慢消失,但这可能需要一些时间才能替换工作流程中的所有工具。

根据此问题的另一个答案,快速解释导致问题的原因。当您执行工作副本移动或删除 1.5.5 之前的 svn 客户端时,会创建一个虚假的 svn:mergeinfo 条目。这是在 svn 1.5.5 中解决的

Unfortunately, old svn clients just do this, and any tools that are based on these old versions of svn are also broken. The only way to resolve this issue is to delete the created svn:mergeinfo entries before they are committed. Since most people are not aware that they are created, then the only real way to enforce that is a pre-commit hook, or just simply do:

svn propdel --recursive svn:mergeinfo $ROOT/*

to clean them out every now and then. Be careful when doing this, as it will destroy any record of partial merges that you have done, so you should really only do this if you really don't do partial merges. The questioner does not, and nor do we in our environment.

The problem is fixed in the newer svn clients, so the problem should slowly die out, but that could take some time before all of the tools in your workflow are replaced.

Based on another answer to this question, a quick explanation of what causes the problem. When you do a working copy move or delete svn clients older than 1.5.5 created a spurious svn:mergeinfo entry. This is resolved in svn 1.5.5.

情归归情 2024-08-23 03:12:16

我们编写了一个 SVN 挂钩/触发器,它只是拒绝对非主干上的 svn:properties 的提交。我们从未回头。

We wrote a SVN hook/trigger that simply rejects commits to svn:properties on non-trunk. We never looked back.

一百个冬季 2024-08-23 03:12:16

我无法提供这样的清单。
我建议你使用 svn hook ,它会
记录导致文件夹属性更改的用户操作
并发出警告或拒绝该提交,
根据您的工作流程,任何合适的内容都可以。

I can't provide such a list.
I would recommend you to use svn hook that will
log user action that leads to folder property change
and either issue a warning or reject that commit,
whatever is appropriate according to your workflow.

旧梦荧光笔 2024-08-23 03:12:16

对子文件夹或单个文件执行合并会导致这种情况,并且它应该会导致这种情况,因为它必须记录合并信息。

最好的方法是在主级别执行合并,并在需要时有选择地应用它,恢复您不想合并的更改,然后提交。

Performing merges on subfolders or individual files causes this, and it should cause it, because it has to record merge information.

Best way is to perform your merges at the main level, and when needed to selectively apply it, revert the changes you don't want merged, and then commit.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文