Currently i’m running an apache web server on a windows server hosting a bunch of repositories with individual settings about who has write and/or read access. The authentication will be done against our Active Directory so user can user their normal credentials as usual. So far everything works fine and everybody is happy.
But now one co-worker saw an interesting effect, which i could easily reproduce on a vanilla base:
Within one repository she (lets call her Alice) has read/write access and one other guy (lets call him Bob) has only read access. Bob found an error within the code and fixed it. When he tried to commit the changes the repository denied it cause of the wrong credentials. So Bob called Alice to come over. He reviewed the code, found it okay and he hit the Commit button again. The saved credentials failed again and Alice entered her credentials (without hitting the save checkbox) and the data was committed to the repository.
Everything worked as expected and everybody was happy…
But then Alice took a look into the subversion log of the repository and the author for that specific commitment was not her, it was Bob.
So it seems that TortoiseSVN didn’t take the login credentials as author, instead it took the currently logged in user on the Windows 7 machine.
As Alice told me this i was quite surprised and setup an empty repository on the server with two users (my normal windows account as read-only, some special account with read/write access). I made an checkout of the repository with my normal windows credentials, added a file and tried to commit it. It failed in the first run and after applying the credentials of the special account the file was added to the repo. But the author in the repo was my normal account not the special account! In contrast within the apache logs i can see that the file was really committed by the special account and that the beforehand tries with the normal account have failed.
Due to the fact that i tried it with a newly created repository their are no hooks that could lead to this problem, also their are no rewrite rules or something else running on the apache server that could maybe lead to the problem.
All these tests have been done on a Windows 7 machine using Tortoise 1.7.3 – 1.7.5 with all the same results. Then i found an older machine running Windows XP with Tortoise 1.6.5 and tried the same scenario from their. Here the behavior is different!
The conclusion is that Tortoise 1.7.x on Windows 7 uses a different author than Tortoise 1.6.5 on Windows XP, but i can’t find any information of this change somewhere in the changelogs or release notes of Tortoise.
Does anyone else also already noticed this change and exists their a way to switch it back to the old behavior?
After getting the comment from bta i made a little more tries and know i’m understanding how and when the author will be set:
The name that appears as author within the subversion log is determined by the first successful user authentication entered after hitting the OK button of the commit dialog, regardless if this user has the right to write to the subversion repository. If the user doesn’t has write access the user authentication dialog will show up a second time asking for the credentials for writing.
Normally everybody hits the Save authentication check box, which leads to the fact that Tortoise always tries to use these credentials for committing the data leading to a successful authentication to fill out the author, but failed for writing. Thous leading to ask the user for the second authentication for getting write access.
I did this tests on Windows 7 with Tortoise 1.7.5 only, so i don’t know if this behavior is really different on XP with Tortoise 1.6.x, but at least i understood how and when Tortoise sets the author.