Here is my setup -
Xcode 3.2.5
Cornerstone 2.0
SVN server 1.6
I am using cornerstone for version
control and nothing setting anything
in xcode.
Now here is the scenario -
I am working in a team (We all decided to use SVN for our new project) of 5 programmers.
Now when I add a new view controller (i.e. LoginViewController.m) on my system the .xcodeproj file gets changed immediately on my system.
Mean while another programmer also add one more view controller (SignupViewController.m). His .xcodeproj file also gets changed.
Now when I complete my code of LoginViewController I commit it. After some time the second programmer finish the SignupViewController and commits his work.
Now using the above procedure the .xcodeproj file gets corrupt and xcode won't open that project again.
Now my question is When should we commit our work when developing iPhone apps under xcode when using a third party svn client. Can someone please elaborate the process of when should we commit in cornerstone.
Should we commit the project just after when we add something in project (like files, images, music)?
It will be great if you can also provide me a tutorial on using xcode + cornerstone in real world.
One way to do this:
Whenever you want to change something to the project structure (add a class for example), you first update your working copy, make the change, and commit right away. Of course that means you'll check in an empty class, but that's no big issue in most cases.
If everyone follows that rule, you shouldn't have any problems.
Remember this:
Always update before you commit.
Related
I currently have a public repository – my most popular one on GitHub by far – that I want to keep as the new active repository. About a month ago, I brought over the public code to a private repository in the hopes of releasing a different version of the project with some extra (non-essential) features, as well as a revamped UI.
Unfortunately (and I hate myself for this), I've made so many bug fixes and updates to the code of the private repository (including a structural overhaul of the main-focus feature), that I want it to be the new public repository and stick with that as the single release for now on.
Most of the filenames are still the same, with some minor caveats. There's a graphical UI component to it (Interface Builder Storyboards) that is mostly managed by the IDE (Xcode) – this file I will probably have to replace entirely with the new file version, but that's not a huge issue as Apple discourages users from going in and editing that code directly anyway.
If you're familiar with Xcode and Swift, you'll recognize the IDE below. If not, the project files are listed in the most-left column of each window, with the UI (Storyboard) elements being to the right of that column. Regardless, this is what I'm working with:
As you can see, the Project name is also different (Old: Ultra for Apple Music → New: Themes for Music).
What would be the best way to bring over the new project? I was thinking of:
Creating a new branch on the public repo (not sure what to name it)
Copy and pasting most of the code by hand (of the private repo to the public repo)
Add the additional Swift files, delete the existing Swift files that are no longer in use on the new version
Replace the Storyboard file entirely and reconnect all of the objects in IB manually
Merge the new branch with Master
Is there a better way to go about this? Maybe I should just commit directly to Master instead (I know branches are only used for changes on a much smaller-scale). I don't want the project changes on GitHub to appear as if I deleted everything and re-added everything if I don't have to.
Again, I'd rather not have to replace the already-public project page as its already my most popular project on GitHub by far.
Something bad happened to my sprite kit project. I was working on my first ios game, and I've got most of it done. But then today, I somehow see that my game scene swift file was gone. There is no way that I can open or have the file back on the project again. The file marked in red in the picture is the missing file.
Screen Shot of Xcode project
Some one Please Help!
Time Machine
Use Time Machine (use Spotlight Search) to go back in time to when it wasn't deleted.
Source Control
If created, go into your source control provider (XCode, BitBucket, GitHub, etc) and make a pull request from a previous commit.
Snapshots
If you snapshotted the project, go back through them to find when it wasn't deleted.
Finder
Check all the files inside of where you saved the file. It is possible you only removed the reference of the file and not deleted it. Use spotlight search if necessary. Check the Trash bin on Mac.
Tips For Future Projects
Use source control, such as ButBucket or GitHub. XCode has a built in one as well. You can also use Time Machine, a built-in app that captures everything on your mac every couple of hours so you can go back in time and pull anything you need back (even trashed items).
I made some changes to my project tonight and messed some stuff up. Is there a way I can go back to how the project was when I opened it? I added/deleted some files but I don't see a way to go back. My last time machine backup was from a few days ago also.
It won't help with the immediate problem, but you need to start using source code control.
This is exactly the sort of problem that source control solves. In Xcode 4 Apple make it particularly easy to start using source code control, as whenever you create a project it offers to create a Git repository for you.
Even for the smallest personal projects, source control is well worth the effort.
There is a possibility to roll back changes if you use XCode's snapshots feature. XCode 4 suggests making a project snapshot before refactoring, for example.
If you don't have the habit to commit or stash changes often (or happen not to use source control at all), snapshots are a nice tool to use before making any major changes that may break the project.
In your current situation though, you're out of luck. Sorry.
I have an app in the iPhone app store and have released several minor updates to it. I want to begin work on some major feature additions and reorganization, but don't want to lose the source code of my most recent version in case everything goes horribly wrong.
Should I start a new Xcode project from scratch and copy my existing source in? If I do this will I be able to submit the build from this new project as an update or will Apple complain that the build comes from a different Xcode project?
I've seen (but not used) Xcode's "Snapshots" and "Source Control" features - are these what I'm looking for?
Any help or direction greatly appreciated.
I would suggest getting your project into some kind of Source Control. The popular ones these days are Subversion (Xcode has built-in support for it, but the support is pretty crappy), git, and Mercurial, all of which run great on the Mac.
You would add your project to a git/svn/hg/etc repository, and then "tag" the repository with something meaningful ("Shipping Version 1.3" or something) (alternatively you could just branch your project at its current state and give that a meaningful name). Then you can do your developments, add and commit the changes to your repository. If you need to revert back to your old shipping version, that's quite simple because you tagged it before you started work (think of a tag like a snapshot).
The other option is to start a fresh Xcode project and copy things over. I have personally done this and shipped just fine to the App Store (just make sure things like your app's bundle id "com.whatever.app" matches with the original one, and make sure you codesign properly) and you're good to go.
Having said that, unless you have a really great reason to start with a fresh project, you're probably better off using source control management with one of the aforementioned tools (git is my preference).
You are using some form of source control right? If not, stop what you are doing and make sure to set up an svn repository. Svn is bundled with your mac and integrates with Xcode.
You also may want to start thinking about doing backups...
I highly recommend you check out Git. There is great Git support built into XCode 4, and you can use Git just fine with XCode 3 as well.
One great thing about Git is that you do not need a server to take advantage of the source code management features. It is a lot easier for a solo developer to work with than SVN once you get your head wrapped around it.
I also highly recommend GitX - a free graphical UI for Git that is absolutely amazing.
One other recommendation it GitBox - a simple tool that allows using a Dropbox as a Git master repository. This is great for sharing code between multiple machines without needing to have or pay for Git hosting at GitHub or elsewhere.
You can either do what the people said before, and use svn git or the like, OR if you don't want to mess around with any of that you can simply create your own version control by copying and pasting the folder and name it "project name x.x" and modify the version without the version number on it
snapshots are the first step. when you are comfortable with them you can hook up to an SVN server for your offsite backup
just make a snapshot after your distribution build and label with the version number
The quickest, easiest, short-term solution is to select the Xcode project folder, and duplicate it. This will create a duplicate of everything in the project. Apple won't care that it comes from a duplicate project.
For the long term, look into setting up an SVN. This will help you save your previous versions every time you make changes.
Since you are new to source control management so might I suggest using Subversion.
Subversion has less features than Git, but you don't have the confusion between pushing and committing (locally vs remotely) and you will find there is more software that supports Subversion than Git or Mercurial.
If you need a quick backup, you can always zip the current working folder for your Xcode project, then name it something like:
MyApplication-Version-1.00.zip
This may be somewhat obscure but I've been happily using Eclipse + Perfoce/P4WSAD for over a year now and have thus far been unable to figure this out myself. I often start a build and let it run in the background while I continue to edit source files. The problem occurs when I try to edit a file that is not checked out from perforce. In this case, eclipse pops up a modal dialog box that forces me to choose between either canceling the build or canceling the check-out operation. So usually I just cancel the build, check out the file, and start the build up again, but this is very time consuming. Is it possible to get eclipse to allow check-outs during builds?
I don't know, but you may want to check with Perforce on this (as this might be something specific to their plugin rather than something in the team su8pport), I never have this problem with SVN or CVS (though maybe my builds are not big enough). Also from what I understand the first generation Perforce plugin had major problems, but they have a new one that's much better. You should make sure you are on the new one.
A simple solution (although it can be disk-space consuming) is to have a building branch on which you merge any of your recently committed development (simple merges with no conflicts: you overwrite what is on the build branch).
Another eclipse project references that build branch sources and builds it whenever you want, while you edit the sources of your first original project.