We have been using svn with xcode for 2 weeks and bumping into many awkward problems, which is probably from misuse and inexperience. Our ios team is a composed of junior team members, since all senior programmers can not write objective-c.
So what is the preferable workflow for version-control under the mac?
You've mentioned a number of problems, several of which IMO have little to do with Xcode or Subversion. Let's take your numbered items:
Subversion can absolutely handle resource files, and you should use it to control those files. The designers can and should be taught to use svn to check files in and out at the command line, or should be given (and trained on) one of the GUI svn clients such as Versions .
It sounds like your junior developers should also be trained on Subversion. It is true that merging can cause problems, but nothing that should ever cause you to start from scratch in any respect. Many shops have a set of simple rules like: a) The main development branch should always build without errors or warnings; b) If you break the main dev branch while merging (or doing anything else), it's up to you to fix it ASAP. Developers can merge their changes and fix whatever problems crop up before they commit to the main branch, so there's little excuse for the main branch to ever be broken.
The conventional Subversion setup has trunk , branches , and tags directories. You don't have to do it this way, but people do because it works well. Please read (and have your team read) Version Control with Subversion for a thorough treatment of all these issues. Printed copies are available from O'Reilly -- buy several, at least. Exactly how you organize your repository isn't as important as getting the team to agree to (and stick to) some organization scheme.
I don't have an opinion on Hudson or continuous integration generally. However, I doubt that implementing CI is going to help much until you get the other issues sorted.
Other thoughts:
To address your actual question, a typical work flow is something like this, depending on local convention:
There's usually some informal communication between developers so that two people don't end up making major conflicting changes to the same part of the code at the same time. Some of this can be handled by the person assigning the tasks, but developers who are working well as a team usually have some idea of who is working on what. If that's not the case, or even if it is, you might need to implement some practices to improve communication, like periodic code reviews, going to lunch together, etc.
In general, I would say the first step to have a good basic understanding of how to use svn in a command-line environment. There are some basic operations (tagging, setting the "ignore" property) that are difficult (impossible?) to do within XCode (at least in XCode 3). For a developer who's comfortable with how to use svn in a generic Unix/Linux environment, there's really not much they have to learn that's specific to XCode - just exclude the build
directory and per-user XCode settings files (see below).
(1.) isn't correct. There's no reason your images etc. can't be included in svn. Normal XCode setup would be that your images (etc.) would be in a "Resources" folder in the source, and would get copied into the application image as part of the "Copy Bundle Resources" phase of the XCode build.
The entire XCode project folder should be included in svn, with the following exceptions:
You likely want to tell svn to ignore these directories by doing something like:
svn propedit svn:ignore .
(2.) There's no reason stuff should be happening "unexplainably". If nothing else, run a manual svn update
in a terminal window, and it will tell you exactly what files it updated.
(3.) Standard practice is to have "trunk", "tags", and "branches" directories in the root. The trunk is what you're normally working with, so the first step a new developer would take is to check out the latest "trunk" version
svn co svn+ssh://host.com/repository/AppName/trunk AppName
After making some changes, save them to the repository with svn commit
(or "Commit Changes..." within XCode's "SCM" menu). Pick up changes made by other developers with svn update
(or "Update To" within XCode).
To tag a release, copy trunk
to tagname
:
svn cp svn+ssh://host.com/repository/AppName/trunk svn+ssh://host.com/repository/AppName/tags/version1
(4.) I don't have experience with Hudson, so I can't comment on that, although "missing xcodeproject" sounds like maybe the AppName.xcodeproj directory might be missing from svn.
I generally agree with David Gelhar's answer.
In addition to item 1, you can actually commit everything in your project's source, including the resources, but there are some things that is better to leave out, like your .pbxuser file. This blog post is a good resource for it.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.