I wonder if there's a best practice when sharing Xcode4 project between multi-developer team. I keep getting problems with .xcodeproj files being corrupted and build problems after every git pull.
The best practice is this - when you get a conflict in project.pbxproj always take in changes from both sides. Then everyone who added or removed files is happy. 99% of the time this works.
If you are getting corrupted project files after a pull, that means that someone is not doing a build before a push. That's the root source of your problem, someone is not understanding what conflicts mean and that they need to be resolved. You need to find that person and show them how to resolve conflicts in files.
Related
Every time I change a package name or move some source code folder, I get "out of date" errors when trying to commit on SVN with Subclipse (plugin for Eclipse). It's amazingly annoying and I always have to spend additional 20 minutes trying to think of a solution how to solve that. Does anyone have similar problems? How do you solve them? Is there a way to force commit something (to say to commit and not pay attention to non-updated files)?
I have similar problem. Unfortunately I have not found out the reason.At first I thought this happens because of incorrect commit order for packages, subpackages and classes. It seems the problem occurs only for projects with more then one developer involved. I always do Update after deleting any package and before commit. This always helps me.
I have a problem!
We are working on an iPhone-app and are using git. The problem is that if someone changes something in the project(adds a file and so on..) and i try to pull that change, I have to merge it.
But the merge isn't painless, I often end up getting a corrupt project file and have to spend quite some time just to fix that.
Does anybody have a solution for this problem?
(Sorry for my crappy English)
Project files are notorious for conflicting. I would enable rerere (stands for "Reuse Recorded Resolution") so that if you have to redo conflict resolutions, you can at least have your decisions cached from the previous time you did them. An excellent write up on rerere is located here: http://progit.org/2010/03/08/rerere.html
If you have the inclination, the better thing to look at is an advanced topic of writing a custom merge driver. See "Defining a custom merge driver" in http://git-scm.com/docs/gitattributes
Hope this helps.
Three important steps:
Cause git to ignore everything in the project file except for the project.pbxproj under the .xcodeproj folder - use .gitignore for this.
before you pull a changed .pbxproj close your project. One of the biggest problems you face is that if you get a new version while Xcode has the project file open it can just save its "current" version over the changed one you want.
merges will sometimes result in spurious data like ">>>>YOURS" or ">>>>THEIRS" merge markers getting included in the project file. If you have to merge do it manually with a tool like filemerge where you can inspect each change and choose whether to include it or not.
If all this fails and you get a corrupted project file anyway
accept the version someone else submitted and redo your own changes, it's almost always easier and the link errors will remind you soon enough.
learn the value of frequent commits.
I've been working on an Xcode (iPhone) project with three different persons. We have the project on a Subversion repository, but we still don't completely understand some aspects of the Subversion + Xcode methodology:
1) Each time someone does a commit on a single file, it may appear or not in the project of the other developers. Even though the same person that creates the new files, it adds those files to the Repository and then it commits on those files. Why does that happens? Any suggestions?
2) Each person that is involved on the project can't do a "Commit entire project" without causing a considerable headache to the rest of the developers... any idea how this should be done?.
The working methodology that we are trying to implement is that only one developer (generally the leader of the project) can Commit the entire project but he must inform the rest of the team, so everybody can be prepared to receive a message asking him to discard his changes and read the new files from the repository.
I need suggestions or advice on how to handle a project with multiple developers using subversion.
We have read the Subversion handbook, and many other messages on StackOverflow but I still can't find any useful advice.
Thanks for any tip!
The reason the other guys are not seeing the changes is that they are not informed until they attempt to do an "update", "commit" or "diff" against the repository. SVN is a "pull" system, the repository doesn't inform the clients of anything without a command from them.
Communication is the key. If your developers are generally aware of what is going on in the project, or at least in their corner of the project if it's a large one, they'll minimize the risk of committing code that will upset the project.
Insisting that only one developer is allowed to commit to the repository is overkill IMHO and quite contrary to the whole idea of using version control. You might as well just have a single folder that only that developer can write to using a diffing tool each time.
Make sure your guys do an "Update", Compile, Test cycle before they "Commit". That way they are less likely to commit code that will break the build. If they're just a little careful, you'll all get the hang of it real quick, there really isn't that much to worry about. Good luck.
You are saying "The working methodology that we are trying to implement is that only one developer (generally the leader of the project) can Commit the entire project but he must inform the rest of the team, so everybody can be prepared to receive a message asking him to discard his changes and read the new files from the repository." Why is that needed? Are the other devs not able to checkin or not good enough to checkin code ? Sorry to say that in a drastic way: That's bull-shit. Every developer should be able to commit. If you like to separate the developers from each other you should use branches for this. And as already mentioned the communication is done by svn update/svn status -u etc.
Each time I do a commit in Xcode I notice that the AppName.xcodeproj file/bundle has been modified. The modifications are obviously important although I don't have enough experience with Xcode to understand them.
What strategy should I use for this? Do I simply commit these changes each time? It's no big deal, it's just that it will appear in SVN history. I'm assuming that I don't add an 'ignore' SVN proprty for this file/bundle, right?
That project folder contains the metadata for your project, so it certainly needs to be included in source control. There are a some user-specific files you can leave out, though. My .gitignore includes these two entries
*.mode2v3
*.pbxuser
But it won't hurt to leave them in, since they don't affect anything when other users open the project.
I have followed this article for every project and it helps me extremely well. You have to commit two files: .gitignore and .gitattibutes first in order for GitX to have effect.
You'd better to add build directory in order not to include temporary binaries into the repository.
Disclaimer: I'm stuck on TFS and I hate it.
My source control structure looks like this:
/dev
/releases
/branches
/experimental-upgrade
I branched from dev to experimental-upgrade and didn't touch it. I then did some more work in dev and merged to experimental-upgrade. Somehow TFS complained that I had changes in both source and target and I had to resolve them. I chose to "Copy item from source branch" for all 5 items.
I check out the experimental-upgrade to a local folder and try to open the main solution file in there. TFS prompts me:
"Projects have recently been added to this solution. Would you like to get them from source control?
If I say yes it does some stuff but ultimately comes back failing to load a handful of the projects. If I say no I get the same result.
Comparing my sln in both branches tells me that they are equal.
Can anyone let me know what I'm doing wrong? This should be a straightforward branch/merge operation...
TIA.
UPDATE:
I noticed that if I click "yes" on the above dialog, the projects are downloaded to the $/ root of source control... (i.e. out of the dev & branches folders)
If I open up the solution in the branch and remove the dead projects and try to re-add them (by right-clicking sln, add existing project, choose project located in the branch folder, it gives me the error...
Cannot load the project c:\sandbox\my_solution\proj1\proj1.csproj, the file has been removed or deleted. The project path I was trying to add is this: c:\sandbox\my_solution\branches\experimental-upgrade\proj1\proj1.csproj
What in the world is pointing these projects outside of their local root? The solution file is identical to the one in the dev branch, and those projects load just fine. I also looked at the vspscc and vssscc files but didn't find anything.
Ideas?
#Ben
You can actually do a full delete in TFS, but it is highly not recommended unless you know what you are doing. You have to do it from the command line with the command tf destroy
tf destroy [/keephistory] itemspec1 [;versionspec]
[itemspec2...itemspecN] [/stopat:versionspec] [/preview]
[/startcleanup] [/noprompt]
Versionspec:
Date/Time Dmm/dd/yyyy
or any .Net Framework-supported format
or any of the date formats of the local machine
Changeset number Cnnnnnn
Label Llabelname
Latest version T
Workspace Wworkspacename;workspaceowner
Just before you do this make sure you try it out with the /preview. Also everybody has their own methodology for branching. Mine is to branch releases, and do all development in the development or root folder. Also it sounded like branching worked fine for you, just the solution file was screwed up, which may be because of a binding issue and the vssss file.
#Nick: No changes have been made to this just yet. I may have to delete it and re-branch (however you really can't fully delete in TFS)
And I have to disagree... branching is absolutely a good practice for experimental changes. Shelving is just temporary storage that will get backed up if I don't want to check in yet. But this needs to be developed while we develop real features.
Without knowing more about your solution setup I can't be sure. But, if you have any project references that could explain it. Because you have the "experimental-upgrade" subfolder under "branches" your relative paths have changed.
This means when VS used to look for your referenced projects in ..\..\project\whatever it now has to look in ..\..\..\project\whatever. Note the extra ..\
To fix this you have to re-add your project references. I haven't found a better way. You can either remove them and re-add them, or go to the properties window and change the path to them, then reload them. Either way, you'll have to redo your references to them from any projects.
Also, check your working folders to make sure that it didn't download any of your projects into the wrong folders. This can happen sometimes...
A couple of things. Are the folder structures the same? Can you delete and readd the project references successfully?
If you create a solution and then manually add all of the projects, does that work. (That may not be feasable - we have solutions with over a hundred projects).
One other thing (and it may be silly) - after you did the branch, did you commit it? I'm wondering if you branched and didn't check it in, and then merged, and then when you tried to check-in then, TFS was mighty confused.
#Kevin:
This means when VS used to look for your referenced projects in ....\project\whatever it now has to look in ......\project\whatever. Note the extra ..\
You may be on to something here, however it doesn't explain why some projects load and others do not. I haven't found a correlation between them yet.
I think I'll try to re-add the projects and see if that works.
#Cory:
I think that's what I'm going to try... I have about 20 projects and 8 or so aren't loading. The folder structures are identical from root... ie: there aren't any references outside of DEV.