In Subversion can I be a user other than my login name? - authentication

I'd like to know how to get Subversion to change the name that my changes appear under.
I'm just starting to use Subversion. I'm currently using it to version control code on an XP laptop where I'm always logged in under my wife's name. I'd like the subversion DB to show the changes under my name.
Later on I'll replicate the DB so it is accessible to the whole house. My wife uses the office computer where she is always logged in under my name. I'll probably set it up so that it automatically checks in modified documents... preferably under her name.
Eventually I'll probably be using it from a linux machine under another username.
Is there some way to modify the user environment to change the user name that Subversion calls you? I'd expect something like setting SVN_USERNAME='Mark' which would override however it usually gets the name.
Update: It looks like the --username flag that Michael referred to does work to change the name reported by "svn stat", even for local file: repositories. In addition, it is sticky so you don't need to specify it for the next command. I even rebooted and it still used the "--username" value from my previous boot.

Most Subversion commands take the --username option to specify the username you want to use to the repository. Subversion remembers the last repository username and password used in each working copy, which means, among other things, that if you use svn checkout --username myuser you never need to specify the username again.
As Kamil Kisiel says, when Subversion is accessing the repository directly off the file system (that is, the repository URL is of form file:///path/to/repo or file://file-server/path/to/repo), it uses your file system permissions to access the repository. And when you connect via SSH tunneling (svn+ssh://server/path/to/repo), SVN uses your FS permissions on the server, as determined by your SSH login. In those cases, svn checkout --username may not work for your repository.

For svn over ssh try:
svn list svn+ssh://[user_name]#server_name/path_to_repo
svn will prompt you for the user_name's password.

You can setup a default username via ~/.subversion/servers:
[groups]
yourgroupname = svn.example.com
[yourgroupname]
username = yourusername
Please be aware that older versions of svn do not support it (e.g. 1.3.1 [sic!]).

"svn co --username=yourUserName --password=yourpassword http://path-to-your-svn"
Worked for me when on another user account. You will be prompted to enter username/password again though. You need to login like the above once and you are all set for the subsequent times(Unless you restart your machine).

If you need to specify a username other than your logged in user for use with svn+ssh just add an entry to your .ssh/config file:
Host example.com
User jdoe

Subversion usually asks me for my "Subversion username" if it fails using my logged in username. So, when I am lazy (usually) I'll just let it ask me for my password and I'll hit enter, and wait for the username prompt and use my Subversion username.
Otherwise, Michael's solution is a good way to specify the username right off.

Most of the answers seem to be for svn+ssh, or don't seem to work for us.
For http access, the easiest way to log out an SVN user from the command line is:
rm ~/.subversion/auth/svn.simple/*
Hat tip: http://www.yolinux.com/TUTORIALS/Subversion.html

Using Subversion with either the Apache module or svnserve. I've been able to perform operations as multiple users using --username.
Each time you invoke a Subversion command as a 'new' user, your $HOME/.subversion/auth/<authentication-method>/ directory will have a new entry cached for that user (assuming you are able to authenticate with the correct password or authentication method for the server you are contacting as that particular user).

I believe if you use the file:// method to access your subversion repository, your changes are always performed under the user which accesses the repository. You need to use a method that supports authentication such as http:// or svn://.
See http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.choosing

If you are using svn+ssh to connect to the repository then the only thing that authenticates you and authorizes you is your ssh credentials. EVERYTHING else is ignored. Your username will be logged in subversion exactly as it is established in your ssh connection. An excellent explanation of this is at jimmyg.org/blog/2007/subversion-over-svnssh-on-debian.html

Go to ~/.subversion/auth/svn.simple/*, and you will see a list of files that contains the information about your svn user account. Just delete all others that you don't need.
After that, when you do anything that regards to SVN operation, such as commit, rm, etc,. You will be prompt again to enter username or passwords.

TortoiseSVN always prompts for username. (unless you tell it not to)

I believe you can set the SVN_USER environment variable to change your SVN username.

Related

Tortoisehg inconsistently asks for password on Push to Bitbucket

I have Tortoisehg set up with a clone of a remote repository on Bitbucket, using https protocol. I turned on the mercurial_keyring extension, and it took care of password handling just fine. Until one day it didn't. Every time I commit now, on push-after-commit it pops up and asks me for a password.
I carefully changed the password on the server, and started typing in that password when asked. IT DOESN'T HELP! It doesn't accept that password.
I hit cancel when asked for the password. Then I go and press the Push green arrow button at the top right of the screen. After asking for confirmation – IT GOES! No password required!
There are three computers that connect to this particular Bitbucket repository. For a while two of the three were working fine without asking a password. Then another one started asking! And then a third popped up asking for something different: "You need to identify yourself to the server." Once again, cancel, use the Push button, works fine!
I am so confused. Has anyone seen this, has anyone fixed it?
BTW, the remote repository is nowhere mentioned in my tortoisehg settings, but it is in my hgrc file:
[paths]
default = https://joymaker3#bitbucket.org/joymaker3/my-repo-name
I yjink, you have to re-read at least section 3.2. "Repository configuration (HTTP)" of extension wiki and check related settings of all repos:
good (full) URL in [paths]
only needed data (if needed) in [auth] (no password for configured remote repository)
you can also enable debug in TortoiseHG and inspect output on failed push

Pass username and password for git pull

is there any way to provide username and password for git pull as command line arguments? in svn there was something like:
svn up --no-auth-cache --username $SVN_USER --password $SVN_PASSWORD
Is there any equivalent of this in git? I can't store the credentials on the filesystem.
Basically, I have a script running build for multiple correlated projects. Because the script is on a shared server and is to be run by different users, I can't store the credentials on the server. I don't want to prompt the user, because the script fetches data from multiple SVN/GIT repositories with single username/pass so I want to read the credentials once via the script and then pass them to git pull or svn up commands
If you're using HTTPS, a solution might be in this answer:
The not secure way is to include credentials in the url you're pulling, https://user:password#server.com/path/to/repo. Apparently, your credentials end up as plain text in the .git folder and/or in log files.
The secure way is to configure a "credential helper" in git. Then it will remember the credentials once they're used. It will store the credentials securely on the machine, but if you use the system-wide configuration they will apply to all users. For example, with msysgit on Windows I'd use the wincred helper: git config --system credential.helper wincred. My understanding is that --system turns the credential helper on for all repositories and all users on the system, so you'll have to decide if this is okay for your server. Disclaimer: I've only used --global before.
I haven't seen better options for your situation, but some of the real git gurus might chime in.

Can I change gerrit authentication type from openid to ldap?

We in our team are planning to use gerrit. So, to get introduced, I did set up a server, used open-id for authentication and created some test-users and test-projects in it.
Now we are ready to use it. But we actually prefer LDAP for real use.
So, can I change my authentication system from open-id from LDAP? What will happen to current users then?
I want to clear test projects and changes. How can I do them?
Can I complete delete existing gerrit setup and initiate a fresh setup in same machine? (I tried extracting the jar in different folder, but I faced some problems in it)
I am using Ubuntu 12.04 as my server.
Please help.
Delete the database (you're not using the H2 database anymore, but some MySQL or PostgreSQL server, don't you?) plus the directory where Gerrit is running (the -d parameter, see docs). Additionally, remove the git repos, if you configured them to be located on a different path.
Then all your data is gone and you can start from scratch.

How to get Hudson CI to check out CVS projects over SSH?

I have my Hudson CI server setup. I have a CVS repo that I can only checkout stuff via ssh. But I see no way to convince Hudson to check out via ssh. I tried all sorts of options when supplying my connection string.
Has anyone done this? I gotta think it has been done.
If I still remember CVS, I thought you have to set CVS_RSH environment variable to ssh. I suspect you need to set this so that your Tomcat process gets this value inherited.
You can check Hudson system information to see exactly what environment variables the JVM is seeing (and passes along to the build.)
I wrote up an article that tackles this you can find it here:
http://www.openscope.net/2011/01/03/configure-ssh-authorized-keys-for-cvs-access/
Essentially you want to set up passphraseless ssh keys for your build user. This will allow authentication to occur without the need to work out some kind of way to key in your password.
<edit> i.e. Essentially the standard .ssh key client & server install/exchange.
http://en.wikipedia.org/wiki/Secure_Shell#Key_management
for the jenkins user account:
install user key (public & private part) in ~/.ssh (generate it fresh or use existing user key)
on cvs server:
install user key (public part) in ~/.ssh
add to authorized_keys
back on jenkins user account:
access cvs from command-line as jenkins user and accept remote host key (to known_hosts)
* note any time remote server changes key/ip you will need to manually access cvs and accept key again *
</edit>
There's another way to do it but you have to manually log from the build machine to your cvs server and keep the ssh session open so hudson/jenkins can piggyback the connection. Seemed kinda pointless to me though since you want your CI server to be as hands off as possible.

svn access to a https repository: username / password always being prompted for

I just moved my svn repository to a new server.
Previously I was accessing my repository via: svn://oldserver/yyy/zzz.
Now I want to access it via: https://newserver:8443/svn/yyy/zzz.
I used switch --relocate to re-point my source tree and this seemed to work well.
When I try to update the source I use:
svn.exe update zzz --username myusername --password mypassword --non-interactive
When I do it still asks me for the username and password (which if I re-enter works OK).
No matter what I do I can't get it to accept the username and password parameters.
Can anyone please help me out here?
I'm not really a SVN god, but I assume you got the checkout working? What happens if you just type
svn.exe update zzz
in the root directory of your project?
You may want to check the files under the %APPDATA%\Subversion\auth\ ($HOME/.subversion/auth in linux) folder and if there is an auth entry for this project, and edit or delete it as appropriate.
When you pass --username and --password, you're telling Subversion to ignore the cached username/passwords, and use those instead. There's probably an error in the username and/or password (maybe caused by your shell?)