Yeah, Git and Hg are the new hotness, but for some projects I’m still using subversion.
A also like keeping my project documentation in VoodooPad. By keeping a narrative of development in an ever-growing VP, I can go back and figure out where certain “design” “decisions” came from that are currently causing me problems. Not that it ever happens to me. *cough*.
Anyway, I’m moving into a new 13″ MacBookPro (sweet sweet little machine), and I’m taking the nuke-from-orbit approach: only installing software and data files on-demand. So now I need to be able to commit VoodooPad doc changes. This is complicated by VP docs being a bundle with files coming and going as the file is edited.
VooDooPad has nice Script Plugin support, including some sample LUA scripts. Oooh! “Commit changes to subversion”. Perfect!
Getting it set up correctly isn’t 100% obvious – here’s how I do it:
- Snarf the “Commit changes to subversion” code” and paste it into a new file living at.
~/Library/Application Support/VoodooPad/Script PlugIns/Svn Commit.lua
- Subversion now lives in
/usr/bin, so edit the/usr/local/binreferences accordingly. Here’s my version:--[[ VPLanguage = lua VPScriptMenuTitle = Subversion Commit VPEndConfig ]] -- we assume subversion is located in /usr/bin/svn posix.chdir(document:fileName()) -- add new files os.execute("/usr/bin/svn st | " .. "/usr/bin/grep '^\?' | " .. "/usr/bin/sed -e 's/\?[ ]*//g' | " .. "/usr/bin/xargs /usr/bin/svn add") -- clean up deleted pages os.execute("/usr/bin/svn st | " .. "/usr/bin/grep '^\!' | " .. "/usr/bin/sed -e 's/\![ ]*//g' | " .. "/usr/bin/xargs /usr/bin/svn rm") os.execute("/usr/bin/svn ci -m'auto commit'") os.execute("/usr/bin/svn st") vpconsole("Commit complete.") - Set up your favorite form of passwordless access. I’ve been using ssh’s authorized keys: passwordless access quickie.
- Restart VoodooPad to get the new menu item.
- Make changes, and no longer fear commitment.
Borkware Miniblog 
Useful! Thanks for sharing. I’ve been needing this.
Comment by Manton Reece — September 7, 2009 @ 7:46 pm
Thanks, Mark, this is great to know. Do you often have to merge changes? I’m wondering how well RTF files merge under svn. I’m guessing fairly well most of the time. (Or do you stick to plain text along with, say, Markdown?)
Comment by Andy Lee — September 26, 2009 @ 1:59 am
Hello Mark,
I hope this is an appropriate place to reach you with questions about your Apress Learning Obj-c book.
I came across a function signature on pg 285 of the book that has left me quite perplexed.
What does the asterisk in “Car *makeCar(…)” do? I thought it was a typo at first but the code compiles.
None of the C/Obj-c references I have show any functions defined this way. I’d be grateful if you could shed some light on this.
Cheers
Comment by Alf Garnett — October 24, 2009 @ 9:31 pm
Hi Alf,
That’s a standard C function declaration. The * means that it is returning a pointer to a Car. Remember that all objects in Objective-C are referenced by pointer.
Cheers,
++md
Comment by Mark Dalrymple — October 24, 2009 @ 11:58 pm
Thanks for your time Mark,
The more I learn, the more I realize what a sheltered life I’ve lived in Java/Ruby bubbleland.
These C streets can be mean sometimes :-)
First refcons, now this. I expected to see the return type rather than the function name decorated with the asterisk.
AG
Comment by Alf Garnett — October 25, 2009 @ 1:27 am
As far as C is concerned, it can go either way. I like having the * away from the type name, because of C’s precedence rules.
fer instance,
int *a, *b;
Two pointers to ints.
if you do int* a, b;
You now a pointer to an int (a), and a regular int (b), which probably isn’t what you wanted.
If you need a C refresher, Dave Mark’s companion volume (Learn C on the Mac) is excellent.
Comment by Mark Dalrymple — October 25, 2009 @ 12:17 pm
Git and Hg… really? I can’t help but wonder why: because they are really better(more functionality/more reliable) or because they are just something new.
New, shiny things good.
Comment by Jeff Szuhay — April 19, 2010 @ 12:59 pm
I’ve been reading up on hg for another project. It has the nice feature of being able to base a local repository off of someone else’s stuff, and then be able to commit to it before syncing up. That way you can work offline, do experimental forkage, or even make local mods to someone else’s code and not have to have permission to the remote repository to save changes.
Comment by Mark Dalrymple — April 19, 2010 @ 3:42 pm