Posts tagged as "*nix":

The Lesson About /usr

Lately I have taken it upon myself to upgrade certain unix friendly applications which ship by default with Mac OS X Leopard. I can not say for sure what started this but I’m fairly certain it began with MacFuse and and my desire to find various things which would allow me to make use of this awesome bit of technology. The first one I found was sshfs which is available as from the MacFuse developers. Soon after I read something about the mystically difficult to find ftpfs. For reasons I can no longer recall I decided I simply had to find and install it. The one I found was curlftpfs and when I attempted to compile it I quickly discovered my version of curl was not up to snuff.

Having been shamed once by an installer I quickly reached out in search of the latest version of curl’s source. After all I’ve done the configure; make; make install routine plenty of times before. Sadly it took me far too long to realized the vast majority of time I’ve done the configure; make; make install routine it was to install new software not upgrade existing packages. So I went through the process the first time and couldn’t get curlftpfs to compile still; curl had not been compiled to the correct location because the old version of curl was still being found in the path. Running blithely ahead I recompiled with the ‘correct’ prefix of /usr. Now this install location should have been my second clue signifying I should stop what I was doing. Instead I moved right along compiling and installing into the /usr directories. I finished compile attempt number two for curlftpfs having learned it had not been compiled with some necessary option enabled and so it was time to compile curl again this time with the option enabled. Of course here the configure fails because I am missing the necessary libraries.

Naturally forging ahead I go and get the missing libraries compile and install them and try curl again. I have forgotten the reason but I know I was doomed for a couple more failures before I attempted to do what I should have done in the first place which is use my already installed MacPorts and just upgrade. Which is what I eventually try. However, it would appear the port command provided by MacPorts also relies on curl so this is a total bust. At this point I’ve forgotten all about getting curlftpfs to work and just want curl and port working again. By this time my frustration must have been palpable because I have no recollection of what I did to get those two things correctly compiled and running again.

The lesson I have learned from this is pretty simple. Don’t mess with the /usr directory without a backup/restore plan.

January 22, 2009

Working With git-svn; a Workflow

As I wrote earlier I’ve been using git at work via git-svn with a Subversion repository. At first I thought this was brilliant and would solve my continuous branching and merging ails. As it turns out I wasn’t entirely correct1.

See, while I like git and how easy it makes branching and merging git-svn doesn’t play quite as nicely2 with branches and merges and rebases as I hoped. Maybe part of my problem is that I needed to keep some of the git branches (which didn’t originate as SVN branches) in sync across a couple computers. In order to do this I set up my server3 to store the git repository related to my work’s SVN repository. The problem with this is every time I fetched and merged from the repository hosted on my server and then did a git svn rebase I wound up having to go through and ‘resolve’ all the conflicts coming from a the svn commits pulled in from the rebase on another computer. Not only was this incredibly annoying but it also meant there was the distinct possibility of winding up with double commits when I next did a git svn dcommit.

I’m not too ashamed to admit I had this problem a couple of times before I figured out I needed to use one branch to keep everything synced up with SVN (site_trunk in my case) and another, or several others as the case may be, to do the development work in. This way I use git svn rebase and git svn dcommit from only the place which is following the SVN branch and do merges as necessary to keep other branches up to date with work which has been done. As a result the ’svn branch’ is only used to contact and deal with the SVN repository all other work is done elsewhere. Since I adopted this process I have had no problems with rebasing or double commits.

  1. It seems I only blog about things I get wrong. I guess that’s good cataloging my mistakes in order to learn from them but it still seems odd to me. 

  2. In my experience. 

  3. The one that host’s this site. 

August 31, 2008

A Public Note About Git Manpages

If you need to install all the software to compile the git manpages check out wincent.com: Setting up the Git documentation build chain on Mac OS X Leopard.

If the only concern is recompiling the man pages…

make prefix=/usr/local doc
sudo make prefix=/usr/local install-doc

August 27, 2008