作为错误用户提交的更改？乌龟SVN、颠覆
我们遇到了一个奇怪的问题，它已经持续了一段时间——也许一年了。对于某些用户，身份验证似乎已损坏，我们将签入，它会显示为另一个用户。具体来说，我们的“BuildMachine”帐户在后台运行，用于进行“官方”构建（它检查分支、构建并签入二进制文件）。不知何故，该帐户会转移到我们的团队成员从本地工作站签入的内容中。
我们已经对 TortoiseSVN 和 SVN 本身进行了多次修订 - 事实上，我们从运行旧版本 SVN+Apache 的旧服务器迁移过来，使用 SVN 身份验证。现在我们通过 VisualSVN 服务器使用当前的 SVN，使用 LDAP 进行身份验证。 （完全不同的身份验证，对吧？）我确信，这会“解决”这个问题。但不...
- 我们的客户都使用 TortoiseSVN 1.6.16、Subversion 1.6.17。
- 服务器是 VisualSVN 服务器，版本：2.1.9
- Subversion 命令行客户端（在服务器上）是 1.6.17
我们有几个（相当广泛的）预提交和提交后挂钩，用于针对某些公司变更/缺陷跟踪系统进行审核，创建代码审查等等。所以这让事情变得有点复杂。
我不知道事情是如何变成这样的，但“解决办法”（临时的）是清除 Tortoise 中的身份验证数据缓存。这看起来很奇怪，因为我好像从来没有从我的电脑上提交过任何“BuildMachine”的东西。但清除我的凭据会以某种方式神奇地摆脱 BuildMachine。诡异的。
有人知道什么会导致这个吗？我知道现在已经发布了 Tortoise 1.7，但我们还没有准备好推出它，而且发行说明似乎表明“升级”我所有的本地副本是一件大事。
谢谢， 克里斯
We've got a weird problem, it's been going on for a while - maybe a year. For some users, the authentication seems to get corrupted and we'll check-in and it'll appear as another user. Specically, our "BuildMachine" account that runs in a back room, to make our "official" builds (it checks out a branch, builds, and checks-in the binaries). Somehow, that account carries over into things that our team members check-in from our local workstations.
We've been through several revs of both TortoiseSVN and SVN itself - in fact, we moved from an older server running older versions of SVN+Apache, using SVN authentication. Now we're on current SVN via VisualSVN server, using LDAP for authentication. (totally different authentication, right?) I figured for sure, this would "cure" this issue. But nope...
- Our clients are all on TortoiseSVN 1.6.16, Subversion 1.6.17.
- The server is VisualSVN server, Version: 2.1.9
- Subversion command-line client (on the server) is 1.6.17
We have several (pretty extensive) pre-commit and post-commit hooks that audit against some corporate change/defect tracking systems, create code reviews, etc.. So that complicates things a bit.
I have no idea how things get this way, but the "cure", temporary as it is, is to clear the authentication data cache in Tortoise. That seems weird because it's not as if I'd ever committed anything as "BuildMachine" from my PC. But clearing MY credentials will somehow magically get rid of BuildMachine. Weird.
Anybody know what can cause this? I know there's a Tortoise 1.7 out now, but we're not ready to roll that out, and the release notes seem to indicate that it's kind of a big deal to "upgrade" all my local copies.
Thanks,
Chris
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在建立一个新的 Jenkins 项目后，我遇到了几乎同样的问题 - 我的本地签到被记入我们的夜间构建帐户。
在命令行提示符下，运行 svn auth - 它将显示所有用于 subversion 的凭据。我发现有一个适合我的条目，还有一个针对夜间构建“用户”的类似条目，然后我将 svn auth --remove 与有问题的用户名一起使用。下次我尝试进行 svn 操作时，我必须登录，但没什么大不了的。
I had pretty much the same problem after standing up a new Jenkins project - my local check-ins were credited to our nightly-build account.
From a command line prompt, run
svn auth- it will show you all of the credentials for subversion. I found there was an entry for me, and also a similar entry for the nightly-build "user" I then usedsvn auth --removewith the offending user name. Next time I tried to do an svn operation, I had to log in, but no big deal.我在 Stackoverflow 上看到几个人对 VisualSVN 有奇怪的问题。最近有人推荐了一个名为Fiddler2 用于调试 HTML 流量。
这可能会让您了解是什么搞乱了身份验证。
如果您想修复提交的作者身份，可以使用 svn propset --reveprop 命令来设置特定修订版的 svn:author 修订版属性。您必须启用 pre-revprop-change.sh 挂钩，因为默认情况下不允许更改修订版属性。
I've seen several people have strange issues with VisualSVN on Stackoverflow. The most recent one someone recommended something called Fiddler2 to debug the HTML traffic.
That might give you an idea what's messing up the authentication.
If you want to fix the authorship of your commits, you can use the
svn propset --revepropcommand to set thesvn:authorrevision property for a particular revision. You'll have to enable the pre-revprop-change.sh hook because the default is to disallow revision property changes.