Pulling SVN with Git on OSX

24 06 2008

I meant to do this a while back, document git setup on OSX.

  • Install SVN 1.4.3 from the DMG at Tigris http://www.collab.net/downloads/community/
  • Make certain you have a gcc compiler, probably from xcode on the OSX install disks
  • Build Git 1.5.5 form source with a ./configure; sudo make install
  • Symbolic link the subersion perl libraries into the perl build library

    ln -s /opt/subversion/lib/svn-perl/SVN /System/Library/Perl/Extras/5.8.6/SVN
    ln -s /opt/subversion/lib/svn-perl/auto/SVN /System/Library/Perl/Extras/5.8.6/auto/SVN

Thats Git installed, now to sync the repo you are after using git-svn, now go an read Git for SVN Users

Having done that to mirror an SVN repo do

git-svn clone http://svn.foo.org/project/trunk
cd trunk

And start working. git commit . will commit locally, git svn dcommit will commit all changes to the remote SVN and rebase your local gir repo to the remote svn

There are man pages on all of this and more … worth reading

Sakai Realm Relationships

17 06 2008

While writing some new queries I once again found myself looking for an entity diagram of the core relationships in Sakai Realm. I couldn’t find one, so I did a quick sketch, here for reference.

Reasons to support Safari

15 06 2008

With the excelence of Firefox many developers leave out Safari from their list of primary targeted browsers. I think this is beginning to be a mistake.

  • The standards compliance of Safari is good, and gives devlopers a second browser platform with good compliance
  • You thought Safari had got fast in v3.0, but it just got faster again, SquirelFish the core Javascript engine of WebKit just got 1.6 times faster than the version in v3.0 of Safari. see http://webkit.org/blog/189/announcing-squirrelfish/
  • iPhone and Google Android is using WebKit behind the browser, so if it works on Safari it will more than likely work on iPhone, iTouch and any other mobile running Google Android in the future

Three reasons to support Safari

How To Design a Good API and Why it matters

15 06 2008

A great talk on API design, 1h long but worth listening to. Especially the advice,

“Don’t send 6 experts into a room for 6 months to write a spec for an API, start with spec on 1 sheet of paper.”

Moving Git patch streams between repos.

10 06 2008

I have 2 Git repositories mirroring SVN repositories, and I want to use git to replay all the patches I made in one of the repositories to the other. The added complication is one of the SVN repos that I am mirroring uses externals, the other does not. So my source is a single repo, with no externals, and the target has externals. Fortunately I want to make all my changes in one of the modules.

So I can use the patch generations capabilities of git to generate a stream of patches.
cd sdata; git log . tells me the stream of commits in the subdir.
Having located the commit I want to start from
git-format-patch -o patches --relative d649f550a43d8f94cbe91a7c735a4a68cab4ba14 .
generates a number sequence of patch emails in a directory gitrepobase/patches. The --relative is vital since it makes the patch set relative to working directory. Unfortunately there is a bug in the next git command that means you must have the correct path for the patch to work -p4 used to strip path elements from a patch in git-am does not work for new files.

Once the patch set is created, I dont need to email it, I can just run the patch set against the target repo from files on disk. git-am -i ../camtools-trunk/patches/*.patch will interactively apply patches to the target repo, asking me for each patch.

Once the patch operation is complete a git svn dcommit commits the changes back to the target svn repo

With a bit of scripting, it should be possible to build a complete patch set with moves and transfer it between detached repos, just as if the modifications where made to the target repo by hand.