I'm using Xcode and CocoaPods, and Occasionally when I run pod deintegrate, followed by pod install, unrelated files in my workspace will be deleted. It happened a few times, and I thought it was due to my accidentally placing project files in the Pods directory, which is not under version control, but it recently happened again where this was for sure not the case. I'm quite stumped as to what is causing this, and I haven't been able to find any previous mentions of this problem online, nor have I been able to reproduce it systematically (though to be sure unsystematically, all too many times).
A guard against this is of course to git status and make sure that everything is git add-ed before ever deintegrating the workspace, which is good practice anyway, but for large commits it can be hard sometimes to remember exactly which files have been added, and at any rate git status will not catch files that for some reason have been dumped into untracked directories.
I realize this is quite vague, but has anyone else experienced something like this? Or has an idea of ways to address it?
EDIT: I think I've figured out the cause. Sometimes when I Cmd + n to make a new file, the interface will not put the new file in the right folder (on the Mac) even though it puts in the right group (in Xcode). Taking care to ensure that both the folder and the group match seems to solve it, along with double-checking that the file has an A on the Xcode interface to make sure it's been added to version control. The reason Cmd + n was behaving differently was that I was invoking it from different places. E.g., if I was invoking it while viewing a file in the Pods group/folder, even if I set the group to something else, it would still save in the Pods folder.
Related
I'm new to vscode... I accepted something for source control and then I believe all my files in android studio went red... not 100% sure that's why, I was also just starting to use firebase and firestore for the first time, so something may have gone wrong there... I tried changing the theme in android studio and that didn't work. And I'm not sure I should change file status colors... how can I revert back to normal?
Edit: followed this deleted answer by running git add . in the terminal, now my files are green(less frightening). Still don't really understand why...
This is a normal thing when you have files in a version controlled directory but the files are untracked. If this is a problem to you then try:
Add the files to the ignore file (.gitignore if you are using git)
Move the project out of repo in vcs.
When I apply:
sfdx force:source:push -f
(Sorry, orginally posted wrong command)
The deployment fails because the compiler throws errors regarding files that are no longer part of my local filesystem.
I cleared following files:
metadataTypeInfos.json
sourcePathInfos.json
To no avail.
Is there some cache anywhere that I need to clear?
I think something has gone wrong with the diffing mechanism.
Deleting files / folders and meanwhile clearing sourcePathInfos.json.
Anyhow, I deleted the import to the file that was no longer needed and the problem went away with it.
It doesn't really solve the problem as sfdx still thinks that the folder exists (the logs show unresolved imports in files that no longer exist) but I don't really care about it a I'm working scratch org).
It can just be fixed by creating a new scratch org too:
sfdx force:org:create -f config/project-scratch-def.json -a <scratch-name> -s
In a big old, Android project, this morning I added a new activity class and a new XML layout file. A little while later I started getting some weird build errors so I decided to shut down Eclipse to restart it (because that often fixes weird Eclipse problems). But Eclipse failed to shut down and hung saving the workspace. I had to kill javaw to get it to die. See Eclipse leaving stuff behind that I can't kill for details.
When I reopened it I discovered that my new files were no longer in the project! The files still existed on the disk. So I looked up how to save the workspace explicitly in the Eclipse wiki and it said . . .
Note that the most essential information in the workspacesuch as
newly created files and folders within Eclipseare always stored
on disk immediately. Saving the workspace simply involves storing away
metadata, such as markers, and its in-memory picture of the projects.
The workspace is designed so that if a user pulls the computer power
cord from the wall at any moment, the resource tree will still be in a
good state so that the workspace will be able to restart in a
consistent state with minimal loss of information.
... obviously this wasn't true this morning so how do I prevent a repeat of this problem?
The files are saved immediately but the metadata contains the information about which files are in the workspace. If the close fails this may be lost. The files are still there but Eclipse does not know about them.
Using 'File > Refresh' (with nothing selected) will refresh all the information about the files in the workspace.
I write Android stuff using Eclipse+the ADT plugin. For VCS I use SVN.
What I am trying to accomplish: have my program, in its 'About' screen, display the SVN revision number it was built from. Obviously, this better be automatic. We cannot assume the program will have network access when run so this info has to be known at compile time.
Today I've been researching this topic and seems like this seemingly common scenario is actually not so easy to do or I am missing something. Lets see:
1) first approach: write a 'pre-commit' SVN script that, on each commit, would update a little file, that would be named 'revision' and would be located in the root of my project. Then writing a function that would open this file, read the revision number and put it in the 'About' screen would be trivial.
This doesn't quite work as the file would be updated server-side. So imagine this scenario: I check out rev. 3708, modify, commit, pre-commit creates 'revision' with '3709' in it. I build - and my local 'revision' still contains '3708'. Not good.
2) I hear ( Getting SVN revision number into a program automatically ) that SVN has this clever feature that it is able to replace various magic strings in your files, one of then being 'Revision', if one sets appropriate SVN metadata on all files in a project under SVN control.
This does not quite work again, because of the problem mentioned by user 'Smashery' in the link above - namely, SVN will only replace the 'Revision' magic string in files that got changed during the last commit.
3) Write a 'pre-build' Eclipse script, and have it run 'svnversion /path/to/your/project' and save output of this in /path/to/your/project/revision.
This does not quite work again - I mean, I have tried and writing such script is actually surprisingly easy. If I were working on a single computer, it would have worked for me - but unfortunately I work on two computers, one Linux machine in home and another Windows machine at work. I keep switching machines every day (during the day Windows, in the evenings Linux at home).
The problem here is with Eclipse: as soon as you add a 'pre-build' script, it creates a new hidden directory in your project folder ( .externalToolBuilders ) , which, among other things, contains the absolute path to the script to run (obviously). This path cannot be the same on both of my machines (being Linux and Windows). In order for things to be automatic, I need to check this in to SVN, and as soon as I do, things will work only on one of my machines unless I keep manually correcting the path every day!
Any ideas?
Third way (slightly polished) can be and will be The Right Way, if you'll grok some things
Workplace specific settings must not be shared and stored in repository: ignore .externalToolBuilders on both locations but configure Eclipse differently according to your needs and settings
Except identical for all OSes svnversion (and don't forget ignore also /path/to/your/project/revision, because build-artifacts must not be part of repository) you may want to use more powerful somehow subwcrev (on Win-box) and svnrev (on Linux-box) in pre-build event - svnrev also contain some useful reading
Can someone explain how Eclipse's local history works?
I accidentally overwrote a file in a project but need to revert to an earlier version.
Is there a chance that Eclipse has the older file cached somewhere?
To complete CurtainDog's answer: from eclipse FAQ
Every time you modify a file in Eclipse, a copy of the old contents is kept in the local history. At any time, you can compare or replace a file with any older version from the history.
Although this is no replacement for a real code repository, it can help you out when you change or delete a file by accident.
Local history also has an advantage that it wasn’t really designed for: The history can also help you out when your workspace has a catastrophic problem or if you get disk errors that corrupt your workspace files.
As a last resort, you can manually browse the local history folder to find copies of the files you lost, which is a bit like using Google’s cache to browse Web pages that no longer exist.
Each file revision is stored in a separate file with a random file name inside the history folder. The path of the history folder inside your workspace is
.metadata/.plugins/org.eclipse.core.resources/.history/
You can use your operating system’s search tool to locate the files you are looking for.
Note, if your need to import your local history into a new workspace, you will need both:
.metadata/.plugins/org.eclipse.core.resources/.history
.metadata/.plugins/org.eclipse.core.resources/.project
to have a functional local history in that new workspace.
Try right-clicking on the file in eclipse, and choose Replace With->Local History.
If there's history available, it'll show up as a list of edit times.
But more importantly, as pointed out in other answers, be sure to put your files in version control! SVN is pretty easy to set up (you don't need a server; it can just use the file system); use it even if you aren't sharing with others.
A tip: whenever you hear yourself say "yes!", check in all of your code. 10 minutes later, you'll be saying "how did I mess that up?"
If you have lost a full package structure due to accidental deletion or svn/cvs override, select the project> right click> Restore from local history => select the files.
VonC's answer has all the information you need for finding the location of your code backups. I would simply add that if you are on a Mac or Linux, you can do something like this:
$ cd [WORKSPACE]/.metadata/.plugins/org.eclipse.core.resources/.history/
$ grep -rl "class Foo" . | xargs ls -lt
This will find all the versions of a file that contains a particular string (ie. "class Foo"), and sort them by date/time to easily find the most recent version.
You can use the link http://wiki.eclipse.org/FAQ_Where_is_the_workspace_local_history_stored%3F is very helpfull
Open the CVS view and you should see a filter for local history. You should then be able to right-click on the correct version and Get Contents or do a manual compare and merge. I'm not sure what the eclipse defaults are for keeping local history but there is a decent chance you'll be able to get your stuff back if you act quickly.