Versions and svn merge

We had a project that included extern links to many subprojects. (They were subprojects because we use them across several projects.) The subjects had a iPhone 3.0 branch created for them, and developed against the new SDK. Out of laziness, we redirected the extern links to the 3.0 branch when it was desired.

In reality, we should have created a 2.x branch, and forced existing apps to change what they were looking at or use the new 3.0 code. But we didn’t.

Now, it was time to merge the 3.0 branch back into the trunk of our development. Version provides a realy nice GUI to most of your day-to-day svn needs. But a major merge is not an everyday need, and needs some human interaction. (Though I do think they could supply a “merge repository branch X into workarea branch Y, and let me handle it from there”.)

The first thing to do is change the external settings to where you want them to be pointing when you’re done, trunk in our case.  You can do this from Versions in the externals part of the inspector.  Then re synchronize the project.  At this point it likely won’t build.  We need to move the code from the branch repository into our trunk work area.

One trick before merging is determining at what point the branch split from the trunk or was last copied from the trunk.  I have a work area with the entire subproject branching structure sync’ed to it and you can select each of the two and show their history, and compare the commits.  The last common commit is what you are interested in.  Mine was 158.

so, you’ve changed directory to the trunk work area, the money command is:

svn merge -r 158:HEAD <branch-workarea-path> --username <remoteuserid>

it will ask your password more than once, keep giving it,

it may ask you a merge question, i always postpone, it provides standard in-file diffs you need to handle,

Select: (p) postpone, (df) diff-full, (e) edit,
(h) help for more options: p

After handling the diffs, check it in.

SQLitePersistentObjects

I was on another iPhone project that had several thousand simple data objects that I would need to keep and search through. SQLite again. I’ve seen Jeff Lamarche mention his open source project, SQLitePersistenObjects a few times, so I decided to give it a whirl.

You can get the code at it’s google source site. There’s not too much documentation available, but it seems simple enough (as any SQLite wrapper should aim to be). There is a ReadMe.txt with a brief introduction, and some sample code (which I haven’t yet looked at).

I went about including it a different way than the “drop the zip file in” method it suggests. My project is in SVN and I’m using Versions, so I just added an svn:extern statement and now have a subdirectory with the source in it.

In Xcode I created a new group, then edited it’s information to point to the subdirectory naturally, then added all the files in there to the group. Then right-click on frameworks, add existing framework, and dig through the /Developer/Platforms et al. until you get to the sqlite dynamic library to link against.

It built and compiled fine for me. Now off to put it through its paces.