We developing a iOS app that uses CoreData. To keep ourselves from going crazy and having to delete the app every time we make a change to the models, we have been using lightweight migrations. At this point we have about 30 or so migrations and are getting ready to submit for review.
Looking at the .ipa file it looks like all of these migrations exist in there as separate files. I was wondering if there is any easy way to collapse all of these migrations into a single model file now that we are done with development and ready to ship 1.0.
A colleague of mine figured it out so I thought I would share it here.
Open the project and right click on the .xcdatamodeld, and delete it (just the references) from the project
Open the finder and find the .xcdatamodel, right click on it and show contents of package
Delete all of the migrations that you don't need
Go back into Xcode and add in the root .xcdatamodeld into your project
Test
Commit your changes
Done.
Anyone doing this I would highly recommend making a backup (or using version control such as git) to protect yourself against inadvertent mistakes.
I am sure glad not to have to ship 30 odd dev migrations to our 1.0 customer!!!
Related
Im not sure this is the right place for this but I need an answer - in the past I have always saved backups (so I can revert back if I break something) of my Xcode projects by copy-pasting the project folder with the project tests/files inside (image below) and naming it a new version (i,e Project 1, project 2, so on):
This has worked well and in the past Ive been able to simply delete a screwed up version and open a past one and the code will be as I left it.
I have now started incorporating pods into my project so I am using the workspace instead of the Xcode project. This now brings in the issue of build "schemes" which appear in the upper left corner.
Not always, but sometimes after copy-pasting I will go back to a previous version and the code has "carried over" from the latest version/scheme. I don't really understand what a scheme is or if this is the problem but it has caused major problems at times.
When using the workspace, how does one properly save backups/new versions to go back to?
It sounds like you need a source control tool, the most used Source Control Management tool is called git. It's what a lot of people use, and you may have heard of GitHub - which is centered around git.
I'd recommend starting by going through this website: https://try.github.io/
As others have mentioned, you should definitely get acquainted with git. And the good news is that about a year after this question was asked, with the release of Xcode 9 (and with all subsequent versions since then), git is built right into Xcode. When you create a project, on the screen where you select the folder you would like to save the project to, you will see a check box, as in this screenshot:
Always enable this (i.e., check the box), and you will never again need to manually save versions of your project to separate folders, as you outlined.
Cheers!
I am working with ASP.NET C# MVC 5.
.mdf/.ldf files in App_Data do not appear on Pending Changes in team explorer. Therefore I can't check them into TFS(visual studio online). I've tried recreating the project a few times and none worked. What might be the cause for this?
Go to Team Explorer and locate Excluded Changes and you should find it excluded. Right click the App_Data folder and include it.
But you might want to reconsider including the database files. As you're developing and testing, every little database interaction will trigger a change and most of those are trivial. Also, if someone else is working on this project, they may not want your database file to overwrite theirs when they Get Latest Version.
If you're using Entity Framework Code-First, the database is automatically generated when you build the project I believe, otherwise you just run the Update-Database command to do it. This lets everyone collaborating have their own local database file to work with. You can also utilize migrations to make updates to the database structure. If you want the database to be generated with pre-populated data, you should utilize the Seed method.
This is a general question. As already answered by 'Ty Morrow' in above comment there is an initial Seed Method in Entity Framework which ensures that all values are inserted. However there are many scenarios that you also need to work with the latest added / removed DB entries not present in the seed method.
Please perform the following steps to ensure that your data directory file is included in the source control.
Click App_Data folder and on encircled toolbar click on Show All Files as shown below in the snapshot
Right Click on your MDF (Data Source) File and click on Include in Project
Right Click again on your MDF File and click on Include in Source Control
Simply Check in the file by Right Clicking on root project folder link and file show be now part of Source Control
We had performed the migration of our whole repository from TFS to VSTS using OpsHub. It seemed to go ok except for some projects that it just couldn't handle. Everything looked ok, until developers were going into projects and find all the files that had been deleted from the projects. This has left all the projects and folders a mess. If you look in the history of those projects you can see the actual deletes in the changesets reflected by the file being displayed with a strike-through going over name. But looking in the folders the files are there. If this was an existing issue, was it part of some disclaimer that we missed?
Is there any way to cause those deletes to occur? We don't want to have to migrate everything again because it took weeks to get everything migrated before. I just need to find out if there are any other options.
I'm working on my first iOS app and have decided to stop being irresponsible and do a good job with version control. My project has been migrated over to a new repository that I established with the DP of Xcode 5. There are a number of images that I've created with Paint Code and Pixelmator that most certainly deserve the same attention to version control as the source code for the app. I love having git hidden behind the UI of xcode - Is there a clean way to include other random files (like Pixelmator files for example) in the same repository as my iOS project and have it all maintained together? Presumably this would not happen in xcode. Don't want any files left out of the party.
I would recommend to use SourceTree or the command line for this. Every other git tool should work fine too.
You don't have to (and honestly, you should not) add your assets (.psd, .ai, .pxm, etc) to Xcode. Just commit them without Xcode.
I do exactly this since a couple of years. All my "raw" files go into an "assets" folder in the root folder of my project. Those files are not added to Xcode, I manage them with SourceTree.
Actually I manage the whole project with SourceTree. I don't use Xcodes Source Control features at all. The git support in Xcode is really basic if you compare it to SourceTree.
Once you've used "Stage Selected Lines" and "Stage Hunk" in SourceTree you can't go back to Xcode.
I put my graphic work files in a folder alongside Resources, but i exclude it and all its content from the target(s). Works for me (using Git).
Can't talk about Xcode 5 here since it's NDA - check out the developer forums for more info (once they get unborked from the hack attempt).
In every recent project I've worked on, we have just included the files in the git repository. Git handles binary files like images just fine, so Xcode should pickup the fact that they're modified and you'll be able to commit them. I personally use the command line 90% of the time, and the other 10% of the time I use SourceTree (for merging / conflict resolution).
I have seen a number of demos from 'respectable' individuals demonstrating the merits of the code first feature for Entity Framework. All of which looks like mouth watering toys!! but one thing strikes me...
Other than in development when would a code first scenario benefit my project?
Having the framework build the database for me seems awesome in a development and testing (portability!!!!) stage of the project but when I update the live project I would not want any of this to occur.
Knowing when the framework is about to overwrite my database and inserting my static data back in seems like a reasonable idea (for test scenarios) but all the demos I have seem put the code to construct this in the EF assembly.
EF Migrations is going to make this clear??? Maybe. Anyone have views on why I should be using this code first?
In my opinion automatic database generation is only for development and testing. Once you move your application to a production environment you should make sure that this feature is turned off. This is especially important once you decide to deploy new version of your application.
EF Migration will perhaps change it by I'm sceptic. I would never let some automatic black box touching my production data. We already had very bad experience with VS Database tools so we never let them working with real data directly - we only let them generate script for us, we precisely test these script and manually execute these scripts on the production. Sometimes it even requires adding some additional migration scripts with temporary tables. That is exactly the approach which should be in my opinion used with EF as well. Let code first crate a new database in your dev environment, use a tool to create difference script for you against the old database, test it and deploy it.
But most importantly: Any upgrade or change on production database should start by backup so if tool fails you can always go back.
Choosing code first / database first / model first is based on the way how you like to develop application and on other requirements you have.