Tips for using Subversion and XCode in a team project

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开发者_JAVA技巧 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.