我正在使用 subgit 通过中间存储库进行 SVN 和 Gitlab 存储库的双向同步（就像在连接到 Github 的官方文档中解释的那样。这是从当前 SVN 到 Git 的非常缓慢的过渡过程的一部分。
我不知道我的问题是否与这个特定案例有关，但我注意到 SubGit 也在同步根文件夹上设置的属性 - 这些属性是 Subgit 本身设置的一些锁定时间戳（如subgit:lock 2018-02-12T17:00:24.067）。就 SVN 端的开发人员而言，这些属性完全无关紧要，也不需要。
属性仅从 Git 端移动到 SVN。当来自 SVN 时，没有什么特别之处。
有没有办法阻止 SubGit 这样做？我已经在config文件中使用了同步过滤，但仅适用于某些特定文件。我将如何为属性做同样的事情？
注意： 对于那些感兴趣的人，我的场景有点具体：SVN repo 在 VPN 后面，而 Gitlab 在实时服务器上，它没有访问该 VPN 的权限。
同步是通过本地计算机（具有 VPN 访问权限）作为代理完成的。
这一切都需要继续接受来自 SVN 和 Git(lab) 方面的提交。
这subgit:lock（和它类似）用于处理 2 个用户同时提交到 SVN 和 Git 的情况。在早期版本中，SubGit 只是发送了一个命令来删除这个属性（即使它没有设置）并且“hack”解决了这种情况。
从 Subversion 1.9 开始，它停止工作，Subversion 开始忽略删除不存在的属性。所以 SubGit 开始subgit:lock每次都设置一个唯一的字符串。不幸的是，这导致了合并冲突（SGT-1215），并且在编写这些行时，它设置了一个具有唯一名称但subgit:lock每次都带有前缀的属性。
由于很难区分 1.8 和 1.9 Subverion 服务器版本，SubGit 对于 SVN 1.8+ 版本具有这种行为，但对于 1.7 以上的版本，它仍然具有其旧行为：删除不存在的属性。它还具有 file:/// 协议访问的旧行为，因为它不依赖于 Subversion 软件版本。
目前没有关闭这个新行为的选项，但如果这真的伤害了你，我认为我们可以实现这样一个选项，然后在SubGit 问题跟踪器中创建一个问题。
如果您一次推送 1 个提交，则没有subgit:lock属性不会有显着变化。但是，如果您同时推送 A 和 B，并且同时有人向 SVN 提交修订版 C，那么在 SVN 中以 C、A、B 或 A、C、B 修订版结尾的可能性会更高存储库作为结果。所以，没什么大不了的。
我是 SubGit 开发人员之一。