How to delete build folder in xcode 4 in order to reduce the size of the application directory?
Its difficult to send entire workspcace in mails if its built in Xcode 4.
Any other practices for reducing the size of the xcode 4 workspace?
You could put all the build data for all your projects into one folder as per Xcode 4 - build output directory. This way you will not bloat your project folders with unnecessary compiled data. The you just zip your folders and sent the archives without having to delete the build folders.
On the other hand the best practice is to use an svn or git source tree to share your data with other developers. You never commit your binary data to the repo of course, just the code and optionally Xcode data.
Hope this helps.
You can delete the build folder in Finder without causing any problems.
As for other strategies to reduce size, I would just make sure there are no unused files still lurking in your folder (old images, classes, etc.)
Related
Is there any easy way to sync the group structure inside Xcode 4 and the actual folders structure in the filesystem?
I have read that some people create new folders on Finder and them drag-and-drop into Xcode, but that sounds like a hack to me. I wish there were a configuration/setting where I could set to make logical (groups in Xcode) and physical (files in filesystem) structures match so that I would not have images, my code, external code, plists, pch, lproj, etc. on the same messy folder.
I also tried changing the location on the Identity and Type panel in View -> Utilities -> View File Inspector and it just made me more confused.
Unfortunately not, the way you mention is what I do.
Its not great but it works.
Just place the file in the folder and then logically group it in XCode.
Automatic Folder Content Inclusion
For automatically inclusion of files and folders, add a folder reference.
You'll see this as a blue folder in your project and now anything you place in there is automatically added to the project.
Was looking for a bit of Light on a few questions we have on xCode 4. Up until now My team and I have been working on our Own projects on our own Drives. Though we are close to integrating our projects and wanted to know which Source Control we should be using to manage our Project. With xCode 4 it seems that Git is Preferred. I setup a repository on GitHub though I don't think its really what we are looking for as It does not seem that xCode knows if files from gitHub are checked in/out, only if they have changed from the last push/pull.
When Pushing my Project to GitHub I don't know why I was surprised that the Groups I created xCode didn't get converted to Folders in the Repository, but I was... In trying to put all of the code files in folders that were represented by my groups I'm running into all my includes not being found as they are in subfolders. Should I just not worry about it and put everything in groups and let xcode put 600 some odd files in the one Project folder, or is there a better way to manage the individual files and references to them?
Thanks!
Background: Trying to set up my dev. environment in new job. Have subversion installed ok in Flash Builder 4, and checked out the project folders I will be working on. Work to date was developed in FB3, I'm going to be using FB4.
The folders/files that get imported to the project also include .flexProperties, .actionScriptProperties, .project, html-template etc (basically everything).
I would have thought that just the src, libs, lib-rsl etc should be part of the svn?
UPDATE:
Here is a good link to setup details for sharing svn flex projects using 2 folders, one of which has the checkout code, the other of which has folders linked to the first (but without the project/setup files)
It depends on the the development group. If everyone is provided the exact same set of tools in the exact same environments it can be ok to include the IDE project files. But if there is any chance that anyone is going to use a different environment (this includes a rolling upgrade of tools) then it is a bad idea. I recommend against putting these files in source control.
I'm using git to track a project I'm developing in Flash Builder, and I'm wondering the best way to go about having it track it, especially regarding Flash Builder generated files, Compiler generated files, and source files that aren't necessarily flex files.
I had it set up to ignore all of the flash builder .project & debugging directories via .gitignore:
.actionScriptProperties
.flexProperties
.metadata
.project
.settings
bin-debug
and also treating any swf/swc files as binaries via .gitattributes
*.swf -crlf -diff -merge
*.swc -crlf -diff -merge
One issue with this setup is checking out this project and using
it in Flash Builder from scratch:
Flash Builder doesn't like it when
you have a project folder without
the .project files. Only way to
import the source into Flash Builder is to:
Create a new Flex Application
Smother the template files it
created (specifially APP_NAME.mxml)
with a git clone.
Where do I put libraries? From a git perspective, I'd like to have them in the lib folder of the repo so when someone clones the repo, everything just works, but from a local file system perspective I'd like to store all my libraries in a single location and use Flash Builder to reference them, as I may update the library or download a later version. Maybe I should put the libraries in their own repo and load them as a git module? This way I don't need to manually remember to update my Y library files in all X projects that are using them, edit: they will simply update when I update each projects' submodules.
And what about external swfs/flex modules? I've was sticking external swf files in the bin-debug folder for now so the SWFLoader class can find them, but because I'm .gitignoring the bin-debug folder, they don't come with the repo when it's cloned.
One final issue is where to keep the files for the server. Do I have them in a separate repo? I'm using php VOs' with AMFPHP so it's good to be able to edit the php files alongside my actionscript files in Flash Builder... but they don't belong in the project src folder.
The current solution I'm using is:
Creating a 'server' folder in the project root
Pointing an apache virtualhost at it
Setting the run/debug settings to http://APP_NAME.localhost
Then using the server folder as a replacement for bin-debug when the files get exported
The problem with this is I've got a big mess of compiler generated files, and non-AS source files in my server folder. It just doesn't seem like an elegant solution.
How do you set up git to work with flash builder smoothly? Could all this be resolved with multiple git repos/Flash Builder projects, or an ANT script or something?
Thanks.
I've found a good solution which avoids all of the horror of having untracked files and keeping a massive .ignore list:
CLEAN your projects before you git commit.
Simple as that.
Whether it be by Flash Builder or by ant, you should have the ability to clean anyway, so if you simply clean before you commit, the problem of generated files is solved. Duh.
In fact you could probably set it up as a git hook or something.
Typically for eclipse projects with any SCM, I initially check in everything including .projects, etc., but maybe except bin-debug in your case. Then just make sure that anybody who checks out the project never checks back in those .xxx files. For instance, when I use perforce, I first check out the .xxx files to a changelist that I never check in. Then check out the rest to a separate changelist.
Another tip is to use user defined library variables when working with build paths, etc.
background:Me and my coworkers are working on asp.net mvc project ... we have a computer that works as a server which is where the project will be stored on... each of us has a copy of the project and we got tortoise cvs set up.
questions:
when you want to commit something, what files exactly do you commit?.. asp.net reports many dll files, csproj files, cs and sln files that appear to be different from the server's.
Maybe my question is not the right one I should ask so I would appreciate some insight on whats the best approach for working in groups.
The basic csproj file should be committed whenever you add or remove things from the project, to ensure that the project has all the correct files. The solution (sln) is a good one to commit, for the same reason, although I've also seen it done without. You'd also want to commit any cs files, naturally, as they're the main focus of things.
DLL files should only be committed if they're outside references--internal dlls to your project can be ignored, as they'll be built by each computer in turn. You also want to avoid .user files as unnecessary. Ignore the 'bin' and 'obj' folders for each directory, when it comes to commits as well.
You really shouldn't check in anything that the project can generate itself. So no need to check in your bin or obj folders or anything like that, you also want to ignore any user preferences files.
This includes dlls, unless they are third party dlls, then you want to check them in to ensure everyone is working against the same version and this way you don't have to keep changing reference paths.
I don't work in asp.net, so I will respond generically.
We have a subversion code repository for our version system, cvs works well too. Developers retrieve all updated code from the repository, do work, make sure it's working correctly, do another get, re-compile, test, and then commit source code changes to the repository. On a regular basis you can have a tool or manually build the application from the repository, and deploy to a testing server. No compiled code should be placed in the repository.
-Jay
We use the following project structure in SVN (but this applies to CVS as well).
+ tags
+ branches
> trunk
+ build (build scripts)
+ lib (external libraries)
> src (source code)
>> Organization.App (solution name)
>> Organization.App.Core (code library)
+ Config
> Domain
> Model
> Persistence
> Queries
> Services
> Persistence
> Services
>> Organization.App.Web (mvc web app)
> Assets
+ Images
+ Scripts
+ Stylesheets
+ Controllers
+ Views
+ ViewModels
We put all our 3rd party dependencies into the lib folder. Including MVC, which can be bin deployed. See this article by Phil Haack. So when a new developer comes online all they have to do it check out the trunk, and they should have everything they need to get going. Using a CI server is a cinch because all of the projects dependencies are encapsulated by the lib folder and all of the visual studio projects make reference to those dll's in that lib folder.
Does that make sense?
Never mind the core folder and the web folder. That's just how we structure our projects within the solution. But that's a whole other conversation. :)
We keep everything except the BIN/OBJ folders in SVN. We have all third party Libraries in a seperate folder that they are referenced from.
Kindness,
Dan
If you are using a database change management tool, such as Tarantino, then you will also want to check in SQL change scripts and/or populate scripts. We have a folder in our 'Core' solution where we keep these, ie 'Core/Database/Updates'. We use SQL Compare to find changes in our database then we check in those SQL change scripts so that other developers can just run them locally. We have a nant task setup to call on Tarantino to sync up the other build environments (Dev, QA) and run any new change scripts.