I’ve set up a repository that is served through apache2. Users first need to authenticate to apache in order to read / write to the repository.
I has come to my attention, that if users set some crazy name as ‘username’, this name will used for the commit – and not the apache authentication name.
Now, is there a way so that either
- the username is replaced by the apache login name?
- or I add the apache login name to the username as defined in the commit?
I know that subversion & apache will always use the apache login name, so that should be possible with mercurial too, right?
EDIT:
I think what I need is to write a hook which extracts the http username and checks whether it matches the commit username. if it doesn’t, then the push request should be rejected.
Does anyone know how to do this?
This is the wrong approach to this, and is guaranteed to cause more headache and problems than whatever problem it is that you’re trying to solve right now.
Let’s assume that you succeeded in implementing the proposed method, what would happen?
Well, in my local repository, that I’m trying to push, I have changesets 1, 2, and 3, with hashes ABC, DEF and KLM. For some reason, I did not use the apache username when committing, so they’re wrong, according to your proposed changes.
I push to the server.
In-flight, your code changes my commits to have the apache username instead. This causes the hashes of those changesets to become recalculated, and different. In other words, my changeset 1, 2, and 3 will now have hashes XYZ, DEF and JKL.
So now my changes are on the server. I did not get a conflict during push since I was the last person cloning.
However, if I now try to pull, I now suddenly discover there are 3 changesets I don’t have, so I pull those, and discover that I now have those 3 changesets in parallel with the 3 I had, with the same contents, a different committer name, and different hashes.
This is how every push and pull will behave from now on.
You push, and immediately you can pull the “same” changesets back, with new hashes, in a parallel branch to yours.
And now the fun begins. How does your local client discover how what to push? It asks the server, “what do you have?”, and then compare that. Well, the server still doesn’t have your 3 original changesets, so the outgoing-command is going to figure, well, those 3 changesets should be pushed.
But if you try to push that, you then recreate the same 3 new changesets, which can’t be pushed, so you’re going to have troubles with that.
What you have to do is impose the following workflow on your users:
A better approach would be for the server to prevent the push in the first place, with a message about using the wrong commit name.
Then you place the burden on the user to fix those changesets before trying to push, for instance by importing them into MQ and reapplying them one at a time.
Or… not.
What if I do a pull from you? You fix a bug, and you’re not yet ready to push everything to the server, so you allow me to pull from you, and now I have outgoing changesets with your name on it, and a server that will enforce my name on them all.
About now you should realise that this approach is going to cause a lot of problems, you’re basically trying to make a distributed version control system behave like a centralised version control system.