Commit failed: .DS_Store ist not under version control - xcode

xCode is giving me trouble, and i've been unable to help myself so far.
When I commit my project, xCode reports:
The working copy "[projectName]" failed to commit files
svn: Commit failed (details follow);
svn: '/Users/[user dir]/[path to project]/[source dir]/.DS_Store' is not under versioning control.
Funny thing is, I'm not even trying to add or commit the .DS_Store. Anyway, I tried to resolve this error by deleting .DS_Store using finder (very futile, pops up again right after killing it), and the command line (less futile, but still no luck).
Then I followed this advise http://soledadpenades.com/2009/07/02/keeping-ds_store-files-at-bay/ to add .DS_Store to my ignore list, both in the project dir and all subdirectories using
svn propset svn:ignore .DS_Store .
However, I will admit, that I did not know exactly what I was doing there. I've been using SVN for a long time on Windows exclusively with the Tortoise UI, and feel an appropriate amount of shame for not owning sufficient svn command line skills.
After the ignore, the error looks like this:
The Woking copy "[projectName]" has failed to commit files
svn: Commit failed (details fllow):
svn: File or directory '.' is out of date; try updating
svn: resource out of date; try updating
I guess that happens if you follow advise from the internet blindly without a sufficient level of understanding (shame on me).
Performing an update, didn't do anything, all files were up to date.
Because I don't want to make things worse than they are right now, I'd humbly ask for some help from you awesome guys and gals.
Thanks,
Chris
Answer
Forcing a commit from terminal. After that, using source control in xCode worked fine again.

The Mac OS stores additional information in .DS_Store. This is why you can't delete the folder: The OS needs it.
What you need is to tell SVN to ignore the folder. That's what you did.
For some reason, editing svn:ignore has the side effect that the folder gets "out of sync" (whatever that means).
The solution here is to update the folder: svn up . from the terminal. After that, you can commit the new property.
After restarting Xcode, everything should be fine again.
Try to edit the ignore list from inside Xcode next time, it might do the necessary magic for you.

Related

Xcode Still Tracking Deleted Files (Pods) [duplicate]

Ever since upgrading to Xcode 8 using Swift 2.3
I have several missing files warnings. They are all related to pods that I am using.
The files that are missing are
*.xcscheme
*.cpp
*.xcuserstate
*.swift
The pods that are showing missing files are
Realm (~38 of 43)
TextFieldEffects (~3 of 43)
BEMCheckBox (2 of 43)
How do I fix this issue?
This is just an Xcode bug. If you delete or rename a file without then doing a commit, Xcode sees the discrepancy between the previous git commit and the current state of things and reports these warnings. They go away as soon as you do a git add that includes the file deletion / rename.
If you don't use Xcode source control but some other git client (like source tree or terminal), you can disable source control in Xcode and then the warnings will disappear.
Xcode > Preferences > Source control and uncheck "Enable source control"
I tried all of these (and many others) but none of them worked. After hours of trying various fixes, I found that the following procedure worked.
cd "project directory"
git add .
You will need to close XCode and reopen or future Commits may fail.
Hope this helps someone.
I solve the problem simply by this:
Add the culprit to the project
Remove the reference
This cleans the internal state of XCode and the message goes away.
How about commit in Source Control.
You may firstly have to show Packet Contents of "your project name".xcodeproj and show Packet Contents of project.xcworkspace and then delete the xcuserdata folder.
If you still cannot commit because of Couldn't communicate with a helper application problem then under your project directory try the following:
xcrun git config user.name "Your Name"
xcrun git config user.email YourEmailAddress
*Remember to reopen the project to see the effect.
You can resolve the issue by checking "Add and Remove files automatically" option in X-Code->Preferences->Source Control
Here is the screenshot of
Preferences
Xcode 8 seems to often miss git add the deleted/related files. To correct it, tap Commit... from Xcode's Source Control menu, make sure to check these files (which are followed by an exclamation mark !), then commit the changes. This should clear the warnings.
I've had this problem a few times now and finally I had it after doing ugly workarounds! I sat down and tracked it until I found the reason to it and were the references are stored!
As someone already proposed it has to do with version control, well yes and no,
in some cases, it definitely have to do with poking around with files directly using the finder or whatever (but not from XCode)
Here's a quick fix that saves a lot of trouble and swear words!
Delete this file:
./.xcworkspace/xcuserdata/.xcuserdatad/UserInterfaceState.xcuserstate
And the errors go away!
I had the same problem. In my case there was a .git directory in a parent directory of my project. By deleting that parent .git directory, the errors where gone.
In my case Pods where checked into the repository generating a couple hundred warnings for "missing files". Fixed it by removing Pods from the repo :
git filter-branch --index-filter 'git rm --cached --ignore-unmatch Pods/*' --tag-name-filter cat -- --all
I have resolved this issue by following steps:
Clear Derived Data
Discard Missing files while commit and then do commit.
Clean Build
Resolved..
Happy Coding.. :)
I have faced the same problem after adding custom CollectionView cell(CustomCollectionViewCell) in the project.Same error occurred as above.
No need to delete the file instead we can.
Rename Missing file for me it's "xCustomCollectionViewCell.xib" .
Now the error is gone.
Again rename the same file to original name "CustomCollectionViewCell.xib"
This fixed it for me:
git reset HEAD <path-to-deleted-file-that-was-causing-the-Xcode-warning>
I had this issue on Xcode 9.3
The solution that worked for me: Add a space in the file, save, then wait for the ! status to change to M, and delete the space, save.
Sadly, with nearly a 100 files to go through, I revisited this post, and this comment from #BennyTheNerd to an answer, helped!
For me, it was as easy as quickly disabling and then re-enabling source control under preferences. Xcode > Pref > Source Control > uncheck "enable source control" .... then re-enable it after. And poof! gone! – BennyTheNerd Jan 16 '17 at 7:29
Additionally though, I had quite Xcode and then open the same project, and then re-enable source control through preferences.
Hope this helps!

Need to Restore Desktop Files - Accidentally Deleted Desktop Directory Using Git Bash

I am new to Git and I did something silly.
I forked a repository from GitHub, then cloned it onto my computer using Git Bash. Long story short, I wanted the directory to be on my desktop but for some reason, I used rm -r Desktop and now all of my desktop files are gone.
I then cloned the repo to my Desktop and it's the only thing I have on there. I tried closing Git Bash since I did not commit any changes but my files are still gone and I am unsure of what to do.
How can I recover my Desktop files? I did not commit or push or do anything of that nature so I'd assume the changes are still local. Thanks in advance for the help!
TestDisk is a tool for recovering files which have been deleted.
Install testdisk
nter testisk into the command line, and the utility will start.
Select your partition to search in.
Select quick search or deeper search.
testdisk will output which files have been recovered and then you can decide to recover or not.
A tutorial on testdisk at the following link,
https://www.journaldev.com/36700/how-to-install-testdisk-on-linux-and-recover-deleted-files

Dreamweaver svn commit failed-out of date

I am using Dreamweaver CS5 and Apache Subversion. Until today, the setup had been error-free. However, when I attempted to check in a file I had revised, I got the following error message from Dreamweaver:
SVN: #160024, Commit failed (details follow): File or directory ‘about.html’ is out of date; try updating
resource out of date; try updating
Background: I am the only user. SVN is hosted on another Mac on my home network running OS X 10.7. I set it up this way because I could never get SVN working on my MacBook Pro, which is running Mavericks. I have tried getting the current version, re-editing, then checking back in, but I have the same problem. Reverting the file and re-editing also fails on check-in.
In Terminal on the Mac running svn, I tried svn cleanup (& sudo svn cleanup), both of which produced the following response: svn: '.' is not a working copy directory. SVN update produces but one message: Skipped '.'
I have used Dreamweaver regularly for over 15 years, but I just started using svn a couple of months ago. I am a svn novice and just followed some very great and detailed instructions on the Adobe website to get it up and running and connect Dreamweaver. Other than this one file, the check-in/out process works fine. When I right-click on the problem file in Dreamweaver's file list, go to version control, and select "Show Revisions," it is up to date; that is, it shows all revisions up to the last one I was able to successfully check in.
This particular file has few revisions to date, so if it is easier and quicker to somehow kick it out of svn altogether and just save the current version back, that would be fine. However, I do need to be able to save version changes of it going forward, as I anticipate significant changes in the future.
Any help would be appreciated!
I've had these errors before. select the file and get the latest version from the server. The commit should work fine again.
Don't know what causes it but this has worked for me several times.

Xcode missing file warnings after removing Git manually

I while ago I removed the .git folders manually from my Xcode (5) project and switched to svn. Ever since I have about 400 missing file warnings like
file:.../.git/objects/f2/4f16e85d07b97f2953a15b302a626806530431: warning: Missing file:
.../4f16e85d07b97f2953a15b302a626806530431 is missing from working copy
Strange thing is, Xcode sees the project as a svn repository, I can view the revisions.
I think that those files are still somewhere in my project.pbxproj file.
Is there some way to remove these references automatically without destroying my svn repository? I am afraid that disabling version control from preferences will disable subversion and not fix my problem.
It is not a huge problem, but it's kind of annoying.
It's complaining about files in your ".git" folder.
Go to Terminal and "cd" followed by the path of the folder where your source code lives.
For example, something like: "cd /Users/whateveryournameis/Desktop/YourAppLivesInHere".
Then type in "ls -al .git". If you see one listed, you can remove the whole folder via "rm -rf .git".
Well turns out it was a svn problem. I had deleted the .git files, but they where still in the svn repository. Did an update, then an svn delete on the .git folder, recommitted.
The files where still reported missing for me in Xcode, so I created an empty .git directory, added it, deleted it with svn delete and restarted Xcode, the warnings are gone :)

svn: E155016: The file 'xxxxx' has no checksum

I got error when execute 'svn upgrade'.
I had used svn 1.6 in Mac OS Lion. And i updated to Mac OS Mountain Lion few days ago.
so i have to upgrade svn.
I usually use Terminal application and execute svn command in CUI.
when i execute 'svn update'
$ svn update svn:
E155036: Please see the 'svn upgrade' command svn: E155036: Working
copy 'xxxxx' is too old
(format 10, created by Subversion 1.6)
when i execute 'svn upgrade'
$ svn upgrade
...
Upgraded
'aaaaa'
Upgraded
'bbbbb'
Upgraded
'ccccc'
Upgraded
'ddddd'
svn: E155016: This working copy is corrupt and cannot be upgraded.
Please check out a new working copy. svn: E155016: The file
'eeeee'
has no checksum
BY the way, the error file has Japanese Character in file name.
Maybe this is cause.
So How should i resolve this problem?
Thanks.
Looks like you've switched from 1.6 to 1.7 or 1.8. You don't mention where you got your copy of svn 1.6 you're using but it's possible you were using one that was patched with the fix for the unicode composition issue. Specifically there is a patch that's floating around that's in common usage but hasn't been applied to the project as a whole since it is not a complete solution. I'm not sure if Japanese would run into these problems since I don't know much about Japanese but it seems plausible.
I'd suggest that you create a new checkout from the working copy with your new Subversion client. I'm not sure if there is a good way to recover from this situation. In particular I'm not sure if the patch is capable of ensuring that svn upgrade executes properly.
On the other hand this might have nothing to do with the unicode issues on OS X and your working copy might just have been corrupted in a way that didn't turn up until recently. The upgrade command needs to touch everything in order to convert from the old flat file system to sqlite. So it often turns up corrupted working copies. It's usually not worth the effort to try to debug the corruption when you can do a new checkout.
If you have uncommitted changes you want to preserve in your working copy I'd suggest that you checkout the same revision(s) of the contents of your working copy with the new version. You ought to be able to figure out the version with an old 1.6 svnversion command or by manual inspection of the .svn/entries files. Once you've done that, rsync the contents of the old working copy over the new working copy while ignoring the .svn directories. Then run an svn update. If you don't get the versions of the working copy checkout exactly right you might have some additional issues when you run update. But hopefully you don't have too many uncommitted changes to clean up.
Alternatively you can try installing a 1.6 copy of Subversion and seeing if you can diff your changes out and determine the correct versions. But I'm not sure what the state of the working copy databases will be during an interrupted upgrade. This might be the best way to go since I believe we're really careful about not botching things.

Resources