Bzr is nice to use. It is tailored for the masses (of which I am a member). It has the usual UNIX support, but it has first-class Windows support, too. It has a nice UI if you want it. The community is great, too.
A few days ago I installed it on OS X and found that there was no UI support via Qt. Fortunately there are directions for setting it up here. Here are the steps that I followed:
- Installed bzr 1.14.1
- Installed Qt for Mac OS X Cocoa, qt-mac-cocoa-opensource-4.5.1.dmg, to the default location
- Verified its installation by running ’qtdemo’
- Installed sip, sip-4.7.9.tar.gz
- Installed PyQt, PyQt-mac-gpl-4.4.4.tar.gz (build took a relatively long time)
- Tried out qlog and qdiff and they worked fine
Now I am wondering if I should have just installed this using MacPorts.
Addendum: 06/21/09
Here are the directions that I followed from that link:
In order to install PyQt, you need to have SIP installed. 1) download and install QT4.x 2) get SIP from http://www.riverbankcomputing.co.uk/sip/download.php $> python configure.py -d /Library/Python/2.5/site-packages $> make $> sudo make install 3) get PyQT from http://www.riverbankcomputing.co.uk/pyqt/download.php $> python configure.py -q /bin/qmake -d /Library/Python/2.5/site-packages $> make $> sudo make install Hope this helps to get qbzr working
BZR as of today works with Python 2.4 or greater. Leopard comes with both 2.3 and 2.5 installed; but defaults to 2.5.
I didn’t know where qmake was installed; and typing ’type -a qmake’ seemed to be the quickest way to find it.
I wish I knew about the tradeoff between installing with MacPorts and not. I know I ended up with a standalone darcs because my early attempts with MacPorts involved my poor laptop spending oodles of time trying to build ghc (the Haskell compiler), and then failing, leaving me with no darcs and a lot of time down the drain.
And don’t get me started on what it’s like to build gnucash with its enormous dependency train.
OTOH, it’s obviously nice if MacPorts knows what libraries are installed…
Robert:
I am leaning towards MacPorts as the best way to manage apps. It tracks dependencies for you, it has a ton of applications, and on top of that it lets you activate/deactivate different versions. It beats building things myself; and I can leverage the lessons that everyone else using the port has already learned and hopefully notified the port maintainer.
I guess my feeling is “that’s all true, until you find a port that doesn’t work.” When I tried to install darcs, the ghc port was known to have bugs.
Yes, it beats building things yourself, but that’s not really the choice here. Does it beat finding a standalone version of the same software, ported to the Mac?
The darcs case is a good one. I really had no desire whatsoever to have a haskell compiler on my mac. I just wanted to be able to sync up with some Common Lisp package or other that was made available as a darcs repo. Why would I want or need to build my own copy, especially if that involved unresolved bugs in the ghc port?
I think there is a good answer to this, but it’s not a simple one. I think the answer is: “if it’s infrastructure, you want the port. If it’s not, maybe not.”
So, for darcs, I’m perfectly happy having a standalone Mac OSX version of darcs and never getting the Haskell compiler.
But for something like gnuplot, probably I want the mac port, because I’m likely to find other tools that want to use gnuplot, and MacPorts’ dependency management is valuable enough to go to the trouble of building from source.
My experiences building gnucash have been scarring enough, though, that I’m not at all sure I wouldn’t prefer rpms that would spare me the trouble of compiling.
Cheers
Robert:
I haven’t been scarred yet by MacPorts; but have experienced what you describe on other systems. I an appreciate your pain.
Most probably, I will proceed with whatever seems to be the most reliable and well-maintained. That is the best I can do.