Working in teams on Flex projects requires some discipline, something we at CIM are learning fast as our projects grow beyond individual developers. We have always used version control but traditionally, we have worked with open libraries that all developers had access to. Anyone could commit to the repositories and everyone checked out the latest code the first thing when they began work in the morning. As more and more developers checked code into our core library, the chances of it being in flux escalated. One idea I am now implementing is the concept of release management. Working with patches is one part of this. This idea is being used, for example, in the LogBook open source application that we released earlier last month (and was blogged about by Ryan Stewart as well).
So here is the situation: At no time should we allow untested code to enter LogBook. However, individual projects have features that they need to be built into LogBook. These features need to be committed back into the LogBook repository. Right now, to maintain code quality, I am the only developer that has commit access to LogBook. Developers can write their extensions to LogBook, usually after a conversation we have about the best way to implement this (the conversations all happen on the cimlogbook google group to maintain transparency). Once they have code working, they send me a patch file which I ensure works and doesn’t include hacks for the sake of a feature. Once the patch is confirmed to be good, I commit the patch to the repository.
Working with patches is a new thing for me and I just wanted to blog about this quick. Working within Flex Builder 3 and with the Subclipse plugin installed, creating patches is as easy as right clicking on the source project and selecting Team > Create Patch … .This creates a patch file that basically documents the difference between the committed project and the user’s local files. The developer then sends me the patch file.
There is a bug in Subclipse that puts absolute paths to local files rather than relative paths and since a developers local file paths may not be the same as mine, we cannot use Subclipse’s apply patch feature out of the box. To apply the patch, making sure I have no local changes in the project, I navigate to the project within my filesystem using the terminal. Once there, I apply the patch by typing
patch -pNumber-of-directories-to-get-to-project < path-to-patch-file
the -pNumber-of-directories-to-get-to-project parameter is basically to remove the folder references to the project directory in the patch file. So for example, if you open a patch file and the first line references the project root as
/Users/comcast/Documents/workspace/cimlogbook/src/LogBook.mxml
you would use -p6 . This removes the /Users/comcast/Documents/workspace/ reference. Once the patch is applied, refresh your project within Flex Builder and you will get the uncommitted changes icon on the changed files/folders. You can synchronize with the repository to see what changed, build the application to make sure it compiles, and then if everything looks good, commit the code to the version control system.
Special thanks to Mat Schaffer for getting me working with patches. I really like this way of committing code since it makes me feel a lot more confident around the libraries I am supposed to be responsible for.
UPDATE:
Another useful tip: Use SVN to generate change logs that can then be published, example:
svn log --revision 217:239 -v
Code Zen 
One thought on “Flex development within teams: Using patches to update projects”