I have set up my Github account in Xcode 9 once, two or three days ago. It works as I would expect.
Checking this morning, it now appears in the list of accounts 12 times!
Does anyone know how this is linked into the Keychain so I can check if I have duplicate entries there?
I was going to delete the duplicates but the following warning is displayed: "Do you want to remove the password for the repository “ad-johnson” from the keychain? This operation cannot be undone".
What I don't want to do is delete them and screw something up. I'm already having other problems with Xcode 9.
I had the same problem. I fixed it by shift-clicking to select all but one of the duplicate accounts and then deleting. If you do this, you will see a confirmation dialog for each account before it is deleted. In my case, I had about twenty duplicates for a project that was only a couple of days old. After I deleted the last duplicate (leaving one account, as expected), my app successfully deployed to my phone.
I had the thought that perhaps something was causing the account to be duplicated with each deploy, but after performing the fix described above, I deployed several more times and only saw the same one original account.
Related
This is a question that I posted, and then after much digging finally resolved myself. There is actually quite a bit on this subject both on this forum and elsewhere, but it usually requires some familiarity with Terminal. I am going to describe the problem I faced and then describe step-by-step in detail (at a beginner's level) how to resolve the issue in Terminal.
In short, I checked out a previously committed version of my app in Xcode, which - because it was a version from several weeks prior - did not contain my most recent commits. In other words, I had no access to any of the commits that contained my most recent work. They had all disappeared.
My commits and pushes had not stored in GitHub because presumably some time before this I had accidentally selected my main folder as the destination for my commits, rather than one of the two branches I created. So I had absolutely no access to my work. By all appearances I pretty much had to start from scratch.
After much hand wringing, teeth gnashing, and hours of scouring the webs, I finally uncovered the solution. But it takes a bit of understanding about Terminal to make it work. So after several more hours of learning Terminal, I finally successfully restored all of my work.
For any of you who are new to coding (as I am), and who have no experience with Terminal, I will provide detailed instructions on how to resolve this issue if you encounter it in the answer below.
Open Terminal to prompt to your Xcode project. The easiest way to do this is to find your project in Finder, which will have a .xcodeproj extension, and then right click it.
Select New Terminal at Folder.
At this point, a terminal window will pop up. From here, enter the following: git reflog
Press Enter
This will populate a list of all the commits stored in your Xcode project. Each commit is identified by an alphanumeric code (the one I restored was 1a7ea33, for example).
Note the alphanumeric code of the commit you wish to restore.
After this, enter the following: git checkout -b NewBranch 1a1a1a1 (where "NewBranch" is whatever name you decide to name your new branch, and "1a1a1a1" is your alphanumeric code from steps 5 and 6).
Press Enter.
That's it. Close Terminal and open your Xcode project as normal. You will notice the restored commit in the folder you just named in Terminal.
Hopefully no one will ever need this, but if by chance someone does I hope it helps.
I uploaded a binary update to the new iTunesConnect, but had not submitted. I found a bug, and tried to remove the existing binary - could not find a way to do that. I then submitted for review but immediately rejected it. Still can't see a way to delete it and upload a new one. How do I upload my new version? OR how do I cancel my update and start a new one?
You don't need to reject Binaries anymore, just change the BUILD number to something higher 1.1 or something like that. Leave the version number the same.
Then it will let you upload it and you can select it from the list to add to your submission.
It took me a while to figure out but it's actually a much better solution than all the rejecting nonsense.
You can't delete binaries that are uploaded. I had to developer reject couple of times and I had 6 of these binaries there. I selected one and then submittted for approval. There is no way to remove "non-needed" ones from this list
A couple of people have asked a similar question, the last one a year ago, with no solution (Here and here), so I thought I'd try it again.
I've created snapshots in Xcode 5.1 on a few occasions before making significant code changes. When I go to restore them, I've seen a couple of different behaviors:
There's one file that changed. Xcode shows me the before and after diffs, and I say OK, and click on Restore. The result, nothing's changed.
Same as one, except in this case there are multiple files that have changed. It shows me one, and it looks good. So I click Restore. It doesn't show me any of the other files diffs that have changed, and it doesn't prompt me to be sure I don't want to look at them. After the fact, I've surmised that I need to click on each changed files in order to accept the changes. But still, there's only one Restore button, which dismissed the window. In any case, none of the files have been restored to their former state. If I try to restore from that same snapshot again (naively thinking I could try to retrieve the other changed files), it tells me that the current state and the snapshot are the same.
If I export the changes to another directory, then I do get the reverted files. It's when I do a File->Restore Snapshot where I get no results.
I've taken to manually creating zip archives of the source so I can recover the files manually.
I don't have any Source Control in use in Xcode so far. It seems I should do that if only to do periodic commits on my own.
Do other people use snapshots successfully? Has anyone else experienced this behavior in Xcode 5?
Thanks much for your help. I've yet to get any response on the Apple Developers Forum on the topic :(
-Eric
In Redmine, is there a way to "temporarily close" a ticket so that it doesn't show up in most reports, but then have it re-open after awhile?
We have a status called "On Hold" which means it's still a valid issue, but we have no immediate plans to address it. It would be great if an "On Hold" issue could be closed for a specified period of time, say from 2-8 weeks.
I've made a feature request on the Redmine site, but I'm posting here because I'm interested in finding out if there's a way to do this already.
There isn't a way (using a standard install, anyway) to make those issues appear Closed without actually enabling the Issue Closed flag for that status, but a nice way to get them out of the way when viewing issue lists is to create a Custom Query from a search that excludes the ones you don't want, and then make that query public.
For example, I have a public custom query called "Not paused or complete" that excludes issues with a status of On Hold, Resolved, Closed, Declined. Any user can then apply this filter when viewing the issue list for a project, and it will show only active issues. Unfortunately, this won't affect reports such as roadmap reports - the issues will be shown the same as all other Open issues in these areas.
Question: Today I worked with MS Visual Sourcesafe, that is to say Microsoft's Sourcecode destruction system, which has never ever saved anything, but already destroyed much.
Today I had one more of those nasty destructive episodes:
I was working on a reporting service report (*.rdl xml files).
I was modifiying a report, so I created a copy and modified it.
The original being named FILENAME.rdl
My modified copy being named FILENAME2.rdl
I finished, saved. Checked in.
It was all correct.
I switched offline, continued to work.
Later on, I deleted filename.rdl, and renamed filename2.rdl to filename.rdl
I continued working for the rest of the day offline.
In the evening I checked in, and filename2.rdl reappeared.
I thought it had copied the old version back, so I deleted filename.rdl (from local computer and sourcesafe, via the delete keyboard button in the visual studio treeview) and wanted to rename filename2.rdl again to filename.rdl.
When I tried, I realized that filename2.rdl was just an entry that appeared in the treevieww, but not on disk... It was in that very momement that I realized that I now have a problem...
I looked in the recycle bin, but nothing there.
I tried 5 different undelete programms, and shadow copy explorer [to find out that non C drive data - such as the data partition e - is not backed up by the shadow copy service automatically...], but no luck. The file is gone.
Is it possible to still retrieve the file from sourcesafe, or does it get permanently removed when one presses the delete button in VisualStudio treeview and clicks OK on deleting it from file & sourcesafe ?
So far I found this one:
http://support.microsoft.com/?scid=kb;en-us;244019&x=11&y=7
but from that it is unclear whether the file is gone.
The problem is if it isn't there, I should redo the about one hour work this evening, because tomorrow will be a busy day.
There are 2 levels of Delete in SourceSafe. When you delete the file, if you check the "Destroy permanently" option, the file will not be recoverable. Otherwise, you can go to the Properties of its parent project and recover it later.
If it's not stored under some different version or branch of your code, I think you're out of luck.
Regardless, however: you estimate this is one hour's worth of work. You already (presumably) spend some amount of time (probably an hour or two) trying to get the file back. Are you not now at the point where, even if VSS has a way to get your file back for you, you'd be better served just rebuilding it?
Short answer - definitely NO!
It can't! I tried.
But it overwrote the recreated report with a completely wrong recovered version...
Fortunately, I've forseen this, and made a backup copy of the recreated report for this case.
So I didn't spend that one hour of recreating the report in vain.
This program should be forbidden, with noncompliance to this prohibition being subject to the death penalty.