2718.us blog » svn http://2718.us/blog Miscellaneous Technological Geekery Tue, 18 May 2010 02:42:55 +0000 en hourly 1 http://wordpress.org/?v=3.0.4 Integrating Version Control Revisions in Mac App Version Numbers http://2718.us/blog/2010/03/22/integrating-version-control-revisions-in-mac-app-version-numbers/ http://2718.us/blog/2010/03/22/integrating-version-control-revisions-in-mac-app-version-numbers/#comments Mon, 22 Mar 2010 13:57:26 +0000 2718.us http://2718.us/blog/?p=238 When I was using Subversion for version control in working on my Mac apps in Xcode, I had come to use a build script phase to tack on the subversion revision number as the last part to the version number:

# tack the subversion revision number onto the CFBundleVersion
  1. REV=`svnversion -n "${PROJECT_DIR}"`
  2. REV=${REV/#[0-9]*:/}
  3. REV=${REV//[^0-9]/}
  4. BASE=`/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" "${PROJECT_DIR}/Info.plist"`
  5. /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $BASE.$REV" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"

This takes the CFBundleVersion from the project’s Info.plist, adds a period and the subversion revision number, and injects that into the Info.plist of the built product.

When I made the move to Mercurial, I couldn’t quite do this anymore.  While subversion revision numbers are monotone increasing and consistent everywhere (they are the unique identifiers of a particular version), Mercurial’s “revision numbers” are local to a particular instance of the repository and may not match up from one instance to another.  Mercurial uses a hash as the unique identifier of a particular version, and these hexadecimal hashes are not monotone, making them unsuitable for use in CFBundleVersion.

Though it took some time, I’ve finally come to a system with Mercurial that I think is workable:

# use the number of minutes between the tip and the most recent tagged commit
  1. HG_LAST_TAG_TIMESTAMP=$(/usr/local/bin/hg log -r "$(/usr/local/bin/hg log -r '.' –template '{latesttag}' –repository "${PROJECT_DIR}|>")" –template "{date|hgdate}\n" –repository "${PROJECT_DIR}" | cut -f1 -d' ')
  2. HG_TIP_TIMESTAMP=$(/usr/local/bin/hg log -r '.' –template "{date|hgdate}\n" –repository "${PROJECT_DIR}" | cut -f1 -d' ')
  3. REV=$(( ($HG_TIP_TIMESTAMP$HG_LAST_TAG_TIMESTAMP) / 60 ))
  4. BASE=`/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" "${PROJECT_DIR}/Info.plist"`
  5. /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $BASE.$REV" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"

This calculates the number of minutes between the most recent tagged ancestor of the tip and the tip itself and adds that to the CFBundleVersion.  Because it’s time-based, it is guaranteed to be monotone increasing, consistent, and unique (well, provided multiple commits don’t happen within a 1-minute span, which is safe for me).

]]>
http://2718.us/blog/2010/03/22/integrating-version-control-revisions-in-mac-app-version-numbers/feed/ 0
Converting a Google Code Project from Subversion to Mercurial http://2718.us/blog/2010/03/21/converting-a-google-code-project-from-subversion-to-mercurial/ http://2718.us/blog/2010/03/21/converting-a-google-code-project-from-subversion-to-mercurial/#comments Sun, 21 Mar 2010 15:01:33 +0000 2718.us http://2718.us/blog/?p=234 The Google Code support wiki article ConvertingSvnToHg is quite easy to follow, but there is one thing worth noting that is kind of buried in the comments.  Assuming you’re doing full history conversion, it is very useful to know that running hg convert locally is much much faster than running it on a remote SVN repository, so it is well worth using svnsync to make a local mirror of the SVN repository and then run hg convert on that.

]]>
http://2718.us/blog/2010/03/21/converting-a-google-code-project-from-subversion-to-mercurial/feed/ 0
Subversions is (on its way) Out, Mercurial is In http://2718.us/blog/2010/03/20/subversions-is-on-its-way-out-mercurial-is-in/ http://2718.us/blog/2010/03/20/subversions-is-on-its-way-out-mercurial-is-in/#comments Sat, 20 Mar 2010 14:33:24 +0000 2718.us http://2718.us/blog/?p=232 I have very happily been using Subversion since 2008.  I was quite clearly late to the version control system (VCS) party and I wish I’d known about VCS much earlier.  About 5-6 months ago, I finally gave in and tried Mercurial and hated it.  While I could kind of get my head around why I should like a distributed VCS (DVCS), I just couldn’t make the paradigm work for me.  I was pretty sure that with all the people talking about how great DVCS was, I must be doing something wrong, but that didn’t stop me from putting Mercurial back on the shelf.

A little over a month ago, I went back and played with Mercurial some more, and it just clicked.  I think it had something to do with reading the Mercurial guide, but I couldn’t really put my finger on it.  That is, until a few days ago, when I read Distributed Version Control is here to stay, baby.  Joel’s explanation of his transition to DVCS really hit on the shift in thinking that took place for me in moving to Mercurial.  Plus, it has one of the best lines I’ve ever read in a blog post:

If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. We have better technology now.

]]>
http://2718.us/blog/2010/03/20/subversions-is-on-its-way-out-mercurial-is-in/feed/ 0
svnX is out, Versions is in http://2718.us/blog/2008/06/27/svnx-is-out-versions-is-in/ http://2718.us/blog/2008/06/27/svnx-is-out-versions-is-in/#comments Fri, 27 Jun 2008 21:43:52 +0000 2718.us http://2718.us/blog/?p=46 While I’d been really happy using svnX, it didn’t deal with svn properties at all, which meant having to go to the CLI and set properties manually.  This got annoying fast when I kept forgetting the syntax to set svn:keywords so that I would get those nice automatic tags filled in at the top of my source files.  This prompted me to go looking for a Mac svn GUI that did handle setting properties.  What I found was Versions and now, about ten minutes into using Versions, svnX is out my dock and Versions is in.  My only worry is that beta 2 expires in 3 days…

If the price is even remotely reasonable when the final version is available, I think I’ll be sticking with it.

]]>
http://2718.us/blog/2008/06/27/svnx-is-out-versions-is-in/feed/ 0
Why Didn’t Someone Tell Me About Subversion Sooner? http://2718.us/blog/2008/06/06/why-didnt-someone-tell-me-about-subversion-sooner/ http://2718.us/blog/2008/06/06/why-didnt-someone-tell-me-about-subversion-sooner/#comments Sat, 07 Jun 2008 02:26:09 +0000 2718.us http://2718.us/blog/?p=43 I’d gotten very used to editing some of my sites on the live running copy or editing a testbed server, then rsyncing it to the live server.  I really had the WinSCP+TextPad thing down, then moved to Transmit+KomodoEdit when I went Mac-only for programming.  It wasn’t bad at all, though every once in a while I really wished I could do one of those “search every file” actions from the editors, but that’s just not possible when editing one file at a time as a temporary copy via SFTP.

At the moment, I’m just starting to dig into one of the larger web projects I’ve done, migrating a large, data-driven site from PHP4 to PHP5, moving it from a commercial host to my own hosting, and rewriting large swaths of code—all at once.  The previous webmaster, who wrote the original code, said he’d used subversion to deal with making revisions and having the ability to roll back when things broke, so I decided to look into subversion.

While most of the documentation made it seem really complex, once I’d settled on https access (apache mod_dav_svn), in the context of an existing SSL site I had, things were very easy–just a few svnadmin commands to set up the directories and a few lines of tweaking in an apache config file.  About 10 minutes into playing with the repository, having imported the existing site and set up a working copy on my local machine, I wondered if there weren’t some nice GUI way to deal with checkout/checkin/status/etc.  Enter svnX.

Now I’ve got working copies on my desktop and laptop as well as a copy checked out to the new production server and I can easily edit locally, even searching all files (that makes it a lot easier to fix all the instances of some incompatibility with PHP5 or some assumption about the directory structure or other oddity).  Once I’ve edited, I can easily check what’s been revised (status) and save the changes to the repository (checkin/commit) using svnX.  A quick “svn up” on the server and everything’s live.

This setup is so wonderfully easy that I’m annoyed I didn’t know to do it sooner.

]]>
http://2718.us/blog/2008/06/06/why-didnt-someone-tell-me-about-subversion-sooner/feed/ 1
WordPress 2.5.1 http://2718.us/blog/2008/04/25/wordpress-251/ http://2718.us/blog/2008/04/25/wordpress-251/#comments Fri, 25 Apr 2008 18:16:45 +0000 2718.us http://2718.us/blog/?p=29 The .1 update that many people said they were waiting for is here. (And there are reminders all over every admin page on my blog, too.)

Version 2.5.1 of WordPress is now available. It includes a number of bug fixes, performance enhancements, and one very important security fix. We recommend everyone update immediately, particularly if your blog has open registration. The vulnerability is not public but it will be shortly.

The notice also mentioned the SECRET_KEY thing that I talked about yesterday and gave a link to auto-generate the line for wp-config.php:

Since 2.5 your wp-config.php file allows a new constant called SECRET_KEY which basically is meant to introduce a little permanent randomness into the cryptographic functions used for cookies in WordPress. You can visit this link we set up to get a unique secret key for your config file. (It’s unique and random on every page load.) Having this line in your config file helps secure your blog.

Upgrading took me about 15 seconds (as usual), mostly to find the svn command in the codex again and then a few seconds to run it and a few seconds in hitting the “database upgrade” page on the site before things were all done.

]]>
http://2718.us/blog/2008/04/25/wordpress-251/feed/ 0
Can You Really Upgrade WordPress in 5 Minutes? http://2718.us/blog/2008/04/14/can-you-really-upgrade-wordpress-in-5-minutes/ http://2718.us/blog/2008/04/14/can-you-really-upgrade-wordpress-in-5-minutes/#comments Mon, 14 Apr 2008 19:59:02 +0000 2718.us http://2718.us/blog/?p=20 5 minutes is a long time for upgrading WP, as far as I’m concerned.  I think it might have taken 5 minutes total to upgrade all three of my current WP installs and check/fix plugin issues.  Mind you, I use the subversion method of upgrading.  If you have shell access and can run subversion, it is so incredibly easy to upgrade WP with it that I don’t ever want to go back to the download-unzip-upload stuff I used to do.  In a post I referenced earlier, Matt said:

Upgrade your blog to the latest WP. This shouldn’t be hard. There are plugins for it, if you’re techy use Subversion, there is the standard FTP method, and finally Media Temple, Dreamhost, and Bluehost (through SimpleScripts) all have been pretty good about having their one-click upgrade systems ready with new versions within a day or two of a release.

I’m techy, sure, but I don’t know much about subversion other than it seems to have replaced CVS and I didn’t know much of anything about CVS other than that people working on big OSS projects seemed to use it.  (Okay, I know a little more about what subversion and CVS are supposed to do, but I’ve never actually used a check-in/check-out/versioning system.)  I literally just installed subversion with the package manager on my system, then used the commands given in the WP Codex.  Not very techy-like.  Done.

]]>
http://2718.us/blog/2008/04/14/can-you-really-upgrade-wordpress-in-5-minutes/feed/ 0