I tried to find the proper way to work with storyboards when there are many devs on the same project and can't find anything useful.
Before storyboards, we would lock the nib while using it to make sure others would not make modifications at the same time. This way, merge conflicts with nibs were quite rare.
But now, with storyboards, I can't see having a dev lock the whole thing for an hour before another one can work on its part! And sure enough, if two of them modify the storyboard, there is a merge conflict. Xcode XML files aren't nice to merge and often enough, the merge causes problem and will in fact corrupt the file so we would prefer to avoid those conflicts.
I wanted to know how other peoples are dealing with this problem? What workflow does other team use?
Thanks!
The storyboard file format is very different from previous XIB formats, so you might give it a try. If you have real examples of changes that cause merge conflicts which you can't easily resolve, your best bet is to file bugs with Apple at http://bugreporter.apple.com.
In storyboards, items tend to be placed in different areas of the file based on where they're located on the canvas, so once you have a larger storyboard conflicts may become less common.
If I have a merge conflict I just open the file with the "Open As" and "Source Code" and take either the mine>>>> section or the section of the other collaborator.
Related
A very quick question.
I've created 2 storyboards main.storyboard and item.storyboard.
I'd originally thought keeping them separated made more sense in terms of organisation however I'm starting to think they'd be better as a single file.
I'm wondering if there's a preferred way to merge item.storyboard into main.storyboard from the xcode tool. I was looking into using filemerge initially but there might be a better way.
In Xcode 3.x I could do Edit > Sort > By Name. I cannot find this functionality in the new version of Xcode. How do I accomplish this?
This is a missing feature (a major one, IMO) from Xcode 4.
EDIT: As of 4.2 it's back in!!!
It IS there in Xcode 4.2 (not sure about earlier versions though.)
y http://f.cl.ly/items/1m0r0y190y0D2w2t3t1D/Screen%20Shot%202555-01-04%20at%2012.16.31%20.png
From my previous answer :
This was, sadly, left out of Xcode4 -- I loved that feature. You can fix it though. Here's how:
First, jump over to Apple's Bug Reporter and file a feature request. Seriously, go ahead. I'll wait until you are back.
Back? Great! We are one step closer to getting that feature. Nice job!
Now for the poor man's substitute until Apple fixes it: Re-organize your project so most of your files sit in sub-directories (real ones, not Xcode logical "group" folders). Typically I have my files arranged in Classes, Controllers, Resources, Images, Foundation, and Supporting files. This covers about 95% of all my files. Whenever you need to reorder the files in Xcode, simply remove a folder reference and add it back -- the files in that folder will once again be in alphabetical order.
Admittedly, not as nice as in Xcode3, but once you have your project folder structure organized, it just takes a moment to re-alphabetize things without too much effort.
It's a missing feature, if you want to sort permanently. However, there is a feature to view items sorted temporarily, namely in the jump bar:
Tip: Hold down the Command key when selecting a level in the path menu to view its items alphabetically.
http://developer.apple.com/library/mac/#recipes/xcode_help-jump_bar/Recipe.html
Quit your project
Backup your project.pbxproj just in case
find the "children" session of your most annoying directory
sort it somehow (I used linux sort -k3)
Open your project.
Worked for me :P
I'm working in a team that's developing iPhone application (about 7 people). We use SVN for source code control of iPhone code, we keep running into conflict issues with xcode project file and iPhone nib file. I think there has been a question asked about this problem : How to merge conflicts (file project.pbxproj) in Xcode use svn?. I want to ask if anyone has ever come up with a satisfactory solution to this. Since our team is fairly decent in size (7 people), manually resolving conflict in xcode project file everytime someone changes code, or adding new object into nib file is a huge productivity waste. Has Apple engineers ever thought about this issues when they wrote their own iPhone apps ? I have been looking for a satisfactory solution using Google and Bing, not yet found one.
Thanks,
This is definitely a HUGE flaw with xcode. I'm on a team of similar size and here's what I do to make the process as painless as possible:
SVN update (ALWAYS do this before a checkin as well):
quit Xcode. The quickest way to do this is to use Alfred and type "forcequit xcode"
"svn up" in the project folder from command line
If you have any merge conflicts with the project file, hit "edit" to open in emacs or whatever
search for "======" to find merge conflicts; delete that line as well as the "<<<< mine" and ">>>>" lines
save & exit. hit "r" to mark project as resolved.
re-open project - "open MyProject.xcodeproj/"
With a bit of practice you can get this process down to under a minute (I do this several times a day).
for NIB files, DO NOT work on while someone else is working on it. There's no real way to merge them. Make your changes quickly and check in right away (there aren't many cases where 2 people need to work on a NIB file at the same time anyway). For less complicated views, just lay them out programmatically.
Try installing SourceGear DiffMerge. This is a merge tool that should make it a lot easier to merge the changes. Also see this blog post about configure XCode to use DiffMerge
There is a similar question at Best practice for managing project variants in Git? but the context is different and I suspect the answer might be too.
I have a Cocoa product "First" managed with Xcode and versioned using git. "First" is still evolving, and is currently at its third version.
Then a customer comes and ask for a variant of First, called Second. The changes from First to Second affect many, but not all, files. The changes affect source code but also resources (graphics elements, nib files, property lists...).
Now the two products are alive and share a number of common files. However, some changes such as bug fixes might apply to both products. Possibly, a new feature might be added to both products.
What would be the best way to manage such a scenario:
with Xcode
with git
I have two ideas, which are mutually exclusive:
Idea 1: git branch "First" into "Second", and apply any applicable change from one project back to the other one. This leads to two totally separate Xcode directories and projects.
Idea 2: Add a target named "Second" to the Xcode project. Now the same Xcode project has two targets and is used to develop and build both products. But this makes it difficult to manage releases for First and Second in git (releases have no reason to be synchronized).
Idea 2 makes the parallel development process very easy. Code is always in sync. Divergences can be handled through compile-time variables and a single source file OR through different source files. It makes version management more obscure though.
Idea 1 is perhaps cleaner, but then, what's the best practice to manage whatever stays common between the two projects? Can you do a "partial merge" between two git branches? On what basis? Or must that be handled manually?
It might be possible to encapsulate and extract some common part into a module or library, but not always. For example I don't think that's possible for the common document icons. Also refactoring "First" so that all common items are extracted away in a build-able manner is a major undertaking that I'd rather do a bit at a time.
I realize there may not be a perfect solution. I am looking for ideas and suggestion.
As a relatively recent git adopter I also realize that this may be an RTFM question. Then simply point me to the FM to R.
My preference is idea2. I currently do this as a way of writing a plug-in for the Main App, and then client apps that go on all the nodes of a cluster. The Plug-in and clients share 90% of the same code, so this makes it super-easy to maintain and debug the where/how of what's going on.
We use Subversion as our source control system and store the VisualStudio project files (vcproj) in the source control system as is normal I think. With Subversion we don't use any form of file locking, so if two developers are working on the same project at the same time and both add files to the project, or change settings, the second one to commit has to merge the changes.
How do you merge these changes?
The vcproj files are just text files so it is possible to edit them by hand but they are not very amenable to hand editing, especially by junior developers.
The ways I can think of are
Get the latest version from svn and re-add all local changes manually
Edit the file by hand to resolve any conflicts from an automatic merge
Implement some form of locking scheme to prevent simultaneous changes
Have an agreement between developers so they do not make simultaneous changes
Currently we are using the first option of re-adding all changes manually but this is time consuming and I was wondering if there is a better way.
With source files the automatic merge feature works most of the time and we don't get many conflicts.
I've found that option 2 (edit the files by hand) generally works fairly well, as long as you're using a good diff tool (I use WinMerge). The main problem I've run into is that Visual Studio will sometimes reorder the file. But, if you have a good diff/merge tool then it should be able to differentiate between changed content and moved content. That can help a lot.
You might find Project: Merge or Tools for SLN file useful
This is a tough problem and I think a weakness in the Visual Studio architecture. The way we found round it was to not have the proj files in source control at all and to have a build script that handled the configuration settings.
The alternative was very messy and we could not guarantee consistent builds or environments between developers. This led to a huge number of downstream integration problems and eventually we took the draconian step of removing the project files from source control.
The developers environments could still become misaligned but it showed up when they tried to build things themselves.
Using TFS here, but I don't think it makes a difference.
We also don't lock, and sometimes have to deal with merging project files. I've never found it to be that complex or much of an issue. Rarely do we ever experience issues that can't be merged automatically, and the manual merge process is pretty much trivial.
There's only one caveat to this: Check in often! If you make major changes to the project structure and don't check them in immediately those changes can start compounding the complexity of later merges. If I make a major change to the structure of a project, I usually give everybody a heads up. I'll ask them all to check in their current work, and then take care of the merge myself.
I found this recently: http://www.codeproject.com/KB/macros/vcproj_formatter.aspx
If you run this tool on a vcproj file and on a modified version of it then you can merge them together easily with your favorite text merge tool, and in addition the result is a more compact pretty vcproj file.
Options 1 and 2 are not mutually exclusive - if the developer is junior level, let them use option 1 (re-get the project file and re-do the changes) if that's more comfortable for them. For more senior developers, option 2 (merge using a merge tool) is perfectly fine.
I think this is a situation that currently has no magic bullet - sometimes merging is a pain.
We use a diff tool (WinMerge) to merge changes. The project files are (for the most part) really straight-forward XML. The key here, though, is that there never should be any surprises when merging, because good communication is part of the bed-rock of effective source control.
Simultaneous changes to the project are perfectly fine as long as people communicate.