Chris Thornton
Chris Thornton

Reputation: 15817

Changes committed as wrong user? TortoiseSVN, Subversion

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...

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

Upvotes: 1

Views: 926

Answers (2)

GTAE86
GTAE86

Reputation: 1846

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 used svn auth --remove with the offending user name. Next time I tried to do an svn operation, I had to log in, but no big deal.

Upvotes: 1

David W.
David W.

Reputation: 107080

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 --reveprop command to set the svn:author revision 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.

Upvotes: 0

Related Questions