I have a personal learning project that I shelved for awhile but recently decided to get back into. After hearing so much about Git, I decided to give it a try. Thus far I've been able to initialize an empty Git repository but then it prompts me for a password of which I've misplaced. My first question, where is the password being prompted from? My assumption was SVN, so I've tried looking for a way to view or reset it but I haven't come across anything that seems to make sense in this scenario. Below is where I keep getting caught...
$ git svn fetch
me#myemail.com's password:
Permission denied, please try again
Connection closed by xx.xxx.xxx.xx (occurs on third attempt)
Network connection closed unexpectedly: Connection closed unexpectedly at /usr/local/git/libexec/git-core/git-svn line 1477
SVN Version: 1.4.4 (r25188)
Mac Version: 10.5.8
Currently, I'm the only one working on this project, so I'm open to suggestions drastic or otherwise, that would make collaborating in the future easier.
many thanks!
Shawn
Presumably you've set up a password in your Subversion server. Depending on how exactly you've set up authentication for your Subversion repository, you may may need to look in the conf/authz and/or conf/passwd files in your Subversion repository. If you're using simple password authentication, your password will be in plaintext in the conf/passwd file. Otherwise, see the Subversion documentation to find out what you did.
Related
I'd like to upgrade to the newest version of Perl6,
rakudobrew build moar
Update git reference: rakudo
Cloning into 'rakudo'...
fatal: unable to connect to github.com:
github.com[0: 140.82.114.4]: errno=Connection timed out
Failed running git clone git://github.com/rakudo/rakudo.git rakudo at /home/con/.rakudobrew/bin/rakudobrew line 57.
main::run("git clone git://github.com/rakudo/rakudo.git rakudo") called at /home/con/.rakudobrew/bin/rakudobrew line 397
main::update_git_reference("rakudo") called at /home/con/.rakudobrew/bin/rakudobrew line 368
main::build_impl("moar", undef, "") called at /home/con/.rakudobrew/bin/rakudobrew line 115
this is just a simple connection failure, but how do I fix this?
Your connection problem is not really anything to do with any P6 related software, or in fact any software you're using. It is, as you say, "just a simple connection failure". And most such failures are transient and "fix themselves". As JJ notes, in such scenarios you just wait and then things start working again.
So by the time you read this it'll probably be working for you again without you having fixed anything. But I'm writing an answer anyway with these sections:
Consider not using rakudobrew
Connection problems that "fix themselves"
Connection problems you investigate or fix yourself
Getting around single points of failure
Consider not using rakudobrew
The main purpose of rakudobrew is to support installation of many versions of Rakudo simultaneously and the main audience for the tool is folk hacking on the Rakudo compiler, not those merely using it.
If you're just a regular user, not someone developing the Rakudo compiler and/or don't need to have multiple versions of Rakudo, with complete source code, installed simultaneously, then consider just downloading and installing Rakudo files directly, eg. via rakudo.org/files, rather than via rakudobrew.
Connection problems that "fix themselves"
rakudobrew failed because a git clone ... command failed because the connection with the github.com server timed out.
A server timing out when doing something that usually works using a connection that usually works is likely a transient problem, aka a "please try later" problem.
Transient problems typically "fix themselves" a few seconds, minutes or hours later.
If there's still a problem when you try again, and you want to spend time trying to find out what's going on officially, then look for a status page for that server.
Here are two status pages I know of for github.com:
https://www.githubstatus.com/
https://twitter.com/githubstatus?lang=en-gb.
And for unofficial scuttlebutt I suggest reading the twitter feed.
For me, right now, github.com is working fine and the status page says all systems are go.
So it should now be working for you too.
If it's not, then you can wait longer, or investigate. It you want to investigate, start by looking at the status pages above.
Connection problems you investigate or fix yourself
If github claims it's working fine then there's presumably a problem with your local internet "on-ramp" (your system or your internet service provider's) or somewhere further afield between your on-ramp and the server you're failing to connect to. (You can only know approximately where the server is based on which region of the world administers the IP address the server is associated with at any given moment.)
The next place to look will be places like the internet traffic report; this indicates traffic jams and the like across the planet. (Ignore the visual display, which is broken on some browsers, and click on the links in the table to drill down.)
If it's all green between you and the region that administers the IP address of the server you're failing to connect to, then the next place to turn would be your system's administrator and/or ISP.
Failing that, then perhaps you can ask a question at a sister stackexchange site like serverfault.com or superuser.com.
Getting around single points of failure
Perhaps you were thinking there might be some system redundancy and/or you're interested in that aspect.
P5's ecosystem and its tools are generally mature and limit spofs. This is unlike the ecosystems and tools of most of the other languages out there; so if you've gotten used to the remarkable reliability/availability of CPAN due to its avoidance of spofs, and by extension perlbrew, well, you've been spoiled by P5.
The P6 ecosystem/tool combinations are evolving in the P5 tradition.
For example, the zef package manager automatically connects to CPAN alongside github, and is built to be able to connect to other repos. The ecosystem is partway there to take advantage of this zef capability in that many modules are redundantly hosted on both CPAN and github.
rakudobrew ignores CPAN and assumes use of git repos. It is impressively configurable via its Variables.pm file which includes a %git_repos variable, which could be re-targeted to an alternative git repo site like gitlab. But no one has, to my knowledge, arranged to redundantly copy and update the relevant rakudo files to another git repo site, so this spof-avoidance ability apparently inherent in rakudobrew's code is, afaik, moot for now.
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
I installed Subversion on a rootserver running CentOS 6. Took me a while, but now I can access the repository using Chrome. I can add files (svn import at command line level), but only when specifying a file:/// path for the destination, https:// giving me "svn: The project archive was moved permanently to [...]; please relocate". I didn't find a single answer helping me with that particular error / message. So I don't even know what it means, what triggers it, ...
On my client I want to use UEStudio (UltraEdit Studio) which has built-in support for Subversion. When trying to do a checkout in UEStudio using the account I created when installing Subversion on the server it tells me "unable to connect to a repository at URL [...]" and also asks for a password. I saved username and password in UEStudio and can login using the exact same credentials in Chrome. The URL UEStudio isn't able to find a repository at is the same I use to browse my repository in Chrome. I'm puzzled!
So I need help setting up Subversion and UEStudio so they finally work together. I cannot offer more details because I'm not sure which ones are necessary. I already spent a couple of hours trying to solve this so I'm not sure what counts any more.
Please feel free to ask for additional details if needed, I'm happy to help!
This Stackoverflow discussion and pointing UEStudio to the x86-version (used x64 so far) of the Subversion client binaries helped, it works now! Also tried UEStudio again and it works as well!! So the problem was I didn't offer a project at checkout, but the parent directory (the repository itself?), as well as offering the x64 binaries to UEStuido.
Thank you for pointing me in the right direction, Robert!! :)
I am trying out Github for Windows and I am getting the following error when I try to publish a newly created repository.
Authentication failed
Your credentials may be out of date. Please log out of the application and then log back in before retrying the operation.
Needless to say I've logged out and back in multiple times without success. I've also uninstalled and installed the latest version to no avail.
The repository is a new one I created within the application and contains only the .gitattributes, .git and README files.
I am a complete newbie to Github so it's quite possible I've messed something up during the setup process.
I was able to solve this by:
Press Settings - Open in GitShell.
git status
git push (or pull)
introduce credentials (here is the most important step, somehow git client messed up or forgot your credentials).
After giving correct credentials you can exit from git shell and use git client again.
It turns out that the problem was Github for Windows was having a problem with the password it had stored. Github support's instructions were as follows:
Log out of Github for Windows.
Change my password on github.com
Log back into Github for Windows.
I was then able to publish my changes.
Did you setup your ssh keys?
https://help.github.com/articles/generating-ssh-keys#platform-windows
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.