What is the best practice / process for sharing code using git between developers working on an iPhone application.
Everytime I follow the normal git-fetch, git-rebase origin/master, method from the command line I get conflicts in the .xcodeproj, .xib, and Storyboard files.
The .xib isn't so bad because its ussually easy to fix, however the .xcodeproj consistently corrupts and I haven't found an easy way to consistently fix it.
What's the best workflow to share project files and resolve conflicts with git?
Conflicts in project files are always a pain. The same thing happens in .NET development and Visual Studio. The best way to handle this is to not have too many changes to merge at once. You do this by merging in each other's changes on an integration branch. To keep branches clean, you don't merge that branch or the other person's back to yours. You rely on rerere to remember all your conflicts along the way. This is the workflow I use:
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
If you really get stuck, you would likely look at what changes were done on the other side (what you're merging in), checkout your version of the project file, manually do what the other branch did to the project file, and then use that as the solution to the conflict.
The issue is that the IDE is doing it's own thing when you update your project. So sometimes, you need to manually use the IDE to simulate adding all the stuff yourself and using that file as the conflict resolution.
This is the dark side of using heavy IDEs for development.
Related
My team is using GitHub with Xcode. We use the GitHub application for OS X to commit, branch and sync. The problem is that when two or more developers add files to the project, conflicts occur in the 'project.pbxproj' file. Recently I realized there is a commit/push/pull option in Xcode.
If I stop using the GitHub application and use Xcode's commit, push, pull and merge, would those conflicts in 'project.pbxproj' file stop occurring?
You can still have conflicts.
If somebody makes a change to the project file and you make a change to the project file and you try to commit it at the same time as (or soon after) the other person, there's a good chance you'll see conflicts.
Thankfully, the "project.pbxproj" project file is text which can you can open with your favorite editor (vi or emacs or whatever) and you can resolve the conflicts rather easily.
I have a VST plug-in project that I am developing that has just reached a beta stage. I am supporting both OS X and Windows, and the way I organized this up until now was to store all the C++ source code in Dropbox, but have each project and platorm-specific files stored locally. That way I kept all the C++ source files synched and could easily jump back and forth between Xcode and Visual C++.
Now I need to start source control on the project (using Git) and I'm wondering how to keep the same sort of functionality/organization. My initial thought would be to store the source code in the master branch and then having the Xcode and Visual C++ projects in separate branches. Then I would check out the project on whatever platform I'm working on. But would this keep the source code synched?
Repositories are a bit new to me, so I'm just trying to wrap my head around it and make sure I don't make a disaster in trying to keep this and future cross-platform projects organized. Thanks for any assistance and advice!
You can put the shared code in it's own repository and add it as a submodule in the platform specific repositories.
Details here.
Repositories are a bit new to me, so I'm just trying to wrap my head
around it and make sure I don't make a disaster in trying to keep this
and future cross-platform projects organized.
Git definitely has a steep learning curve, but it's very flexible and you can easily change you mind later if you decide to organize your code in another way. It's also very hard to delete something and not be able to restore it. Actually you have to try really hard to get rid of something completely ;)
Is there are means whereby if files are altered outside of Xcode, that a warning in can be shown to ask if you want to refresh the file? This feature is available in Visual Studio, for example.
As a temporary solution, were working on source files in a Dropbox folder.
Although growl notifies us that some files has changed, Xcode doesn't know about these changes.
No, Xcode won't do that, and since there's no support for plugins you're pretty much stuck with that behavior. Some suggestions:
Create a local git repository (Xcode can do this for you when you create the project, I don't know if you can do it once it is created.
Use another IDE, like AppCode (this isn't even a solution, just came to me and I decided to add it).
With a version control system you can see the little 'M' on edited files, browse changes, etc. But since you wrote that this is a temporary solution I bet you already know this.
I'll try to make this as straight forward as possible.
Currently our team has a VSS database where our projects are stored.
Developers grab the code and place on their localhost machine and develop locally.
Designated developer grabs latest version and pushes to development server.
The problem is, when a file is removed from the project (by deleting it in VS2008) then the next time another developer (not the one who deleted it) checks in, it prompts them to check in those deleted files because they still have a copy on their local machine.
Is there a way around this? To have VSS instruct the client machine to remove these files and not prompt them to check back in? What is the preferred approach for this?
Edit Note(s):
I agree SVN is better than VSS
I agree Web Application project is better than Web Site project
Problem: This same thing happens with files which are removed from class libraries.
You number one way around this is to stop using web site projects. Web Site Projects cause visual studio to automatically add anything it finds in the project path to the project.
Instead, move to Web Application Projects which don't have this behavior problem.
Web Site projects are good for single person developments.
UPDATE:
VB shops from the days gone past had similiar issues in that whatever they had installed affected the build process. You might take a page from their playbook and have a "clean" build machine. Prior to doing a deployment you would delete all of the project folders, then do a get latest. This way you would be sure that the only thing deployed is what you have in source control.
Incidentally, this is also how the TFS Build server works. It deletes the workspace, then creates a new one and downloads the necessary project files.
Further, you might consider using something like Cruise Control to handle builds.
Maybe the dev should take care to only check in or add things that they have been working on. Its kind of sloppy if they are adding things that they were not even using.
Your best solution would be to switch to a better version control system, like SVN.
At my job we recently acquired a project from an outsourcing company who did use VSS as their version control. We were able to import all of the change history into SVN from VSS, and get up and running pretty quickly with SVN at that point.
And with SVN, you can set up ignores for files and folders, so the files in your web projects dont get put into SVN and the ignore attributes are checked out onto each developer's machine
I believe we used VSSMigrate to do the migration to SVN http://www.poweradmin.com/sourcecode/vssmigrate.aspx
VSS is an awful versioning system and you should switch to SVN but that's got nothing to do with the crux of the problem. The project file contains references to what files are actually part of the project. If the visual studio project isn't checked in along with the changes to it, theres no way for any other developer to be fully updated hence queries to delete files when they grab the latest from VSS. From there you've got multiple choices...
Make the vbproj part of the repository. Any project level changes will be part of the commit and other developers can be notified. Problem here is it's also going to be on the dev server. Ideally you could use near the same process to deploy to dev as you would to deploy as release. This leads into the other way...
SVN gives you hooks for almost all major events, where hooks are literally just a properly named batch file / exe. For your purposes, you could use a post-commit hook to push the appropriate files, say via ftp, to the server on every commit. File problems solved, and more importantly closer towards the concept of continuous integration.
Something you may want to consider doing:
Get Latest (Recursive)
Check In ...
Its a manual process, but it may give you the desired result, plus if VS talks about deleted files, you know they should be deleted from the local machine in step 1.
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.