Category: Subversion

git

My thoughts on Git

I have been working with Git for a while now, and I have a few thoughts about it. I am used to the SVN model, where multiple developers check out of a central repository, make changes locally and then commit them back to the repo (and repair failed merges). While SVN is not perfect, at least I am comfortable with it and know what to expect from it. While some of my issues with Git may relate solely to my relative unfamiliarity with it, at least it seems like I am not the only one with issues.

In reading through the man pages and all the documentation I can find on line (including the Git – SVN Crash Course) I was totally unprepared for what actually happens. According to the Crash Course git commit -a does the same thing as svn commit, but that is not quite the case. After a commit the files still need to be moved to the repo. So as I am looking for the best way to do that I find git push. Well, it would seem to me that firing off a git push would mean that I want the files I have modified and committed to merge into the repo I checked them out of. But that isn’t quite what happens if there are any working directories checked out the repo (meaning the one you are working on). It seems that the only way to properly get the files back into the repo is to issue a git pull from the repo aimed at your working branch. Hans Fugal said it best in his post from last year: git-push is less than worthless.

What this means is that I am unable to easily move changes from my laptop to the server. Instead, in order to reduce the number of steps I need to take I check out the repo I am working on (git clone) in my home directory on the server and then use sshfs to mount that directory locally. I do my work there, and then ssh in to the working directory, fire off git commit -a and then cd to the repo to pull from the working directory. Of course this seriously hampers my ability to work offline (as in I can’t). While I am sure there are plenty of good things about Git I am not yet really seeing them. With the exception of git stash I have yet to be wowed by anything Git has to offer. In the interest of fairness, however, I have not been incredibly wowed by anything SVN has to offer either, I just find it easier to use.

Gentoo

Minor SVN hiccup

Anyone who tried to access SPDO via the subversion repo since Saturday may have run into a slight problem: namely a session that looked something like this:

ratatosk:svn sjan$ svn co http://www.evardsson.com/repos/projects/spdo/ spdo
svn: Could not open the requested SVN filesystem

I only became aware of it this morning, and I knew (almost) right away where the problem might lie. I was still able to access the repos via svn (in the internal network) and via file (from the server) but could not access them from http or https. I checked the svn version number and got this:

xxxx spdo # svn --version
svn, version 1.5.6 (r36142)
   compiled Mar 21 2009, 09:44:24

Copyright (C) 2000-2008 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

Ok, so this version built on Saturday when I did my latest updates. So, ra_svn works, ra_local works but ra_neon does not. I recalled that neon upgraded from 0.28.3 to 0.28.4 on the same day with the warning:

  * Neon has a policy of breaking API across minor versions, this means
 * that any package that links against neon may be broken after
 * updating. They will remain broken until they are ported to the
 * new API. You can downgrade neon to the previous version by doing:
 *
 *   emerge --oneshot '<net-misc/neon-0.28'
 *
 * You may also have to downgrade any package that has already been
 * ported to the new API.

That shouldn’t be needed (downgrading earlier than 0.28) since everything was working fine with 0.28.3 so, a quick

emerge --oneshot =net-misc/neon-0.28.3

and all is right with the world again.

OS X

SVN on OS X – /usr/bin or /usr/local/bin

I recently installed the openCollabNet OS X Universal binary for SVN 1.5.4 from Tigris and found something odd. I had installed the openCollabNet binary for 1.4.4 a while back, and don’t recall changing any install paths, but apparently something changed. After installing I ran svn –version and saw something that I shouldn’t have seen:

svn, version 1.4.4 (r25188)
compiled Sep 23 2007, 22:32:34

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

Strange, I should have seen the new 1.5.4 there. So I did a bit of digging. Everything I saw about the openCollabNet binary said it installed in /usr/local/bin, but when I ran which svn I saw /usr/bin/svn. So I looked in /usr/bin and /usr/local/bin. Sure enough, two installs in two different places. Not being one to do anything rash (like deleting svn from /usr/bin and then changing the path on all my tools that rely on it) I decided the best thing to do was fix it in a way that was reversible. So, I fired off a sudo ls (to get my password in scope in the shell) and then a simple

for i in `ls /usr/bin/svn*`; do mv /usr/bin/$i /usr/bin/$i.old && ln -sf /usr/local/bin/$i /usr/bin/$i; done

Once I had fired off that command another call to svn –version revealed the fix:

svn, version 1.5.4 (r33841)
compiled Oct 27 2008, 11:19:10

Copyright (C) 2000-2008 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

I am still a little confused as to how 1.4.4 ended up in /usr/bin while 1.5.4 went to /usr/local/bin (where it is expected to go from the openCollabNet binary installer). I wondered, did I change the install path at some point in the install? Somehow I doubt it, as that is not a change I would be likely to make. Just another little mystery for the unsolved cases file.

Subversion

WordPress Update headaches – resolved???

I had a few headaches updating to WordPress 2.3. Not surprising since the category related tables were removed to make room for native tagging, and I have been relying on the Category Tagging plug-in. Ah well, after some hand sql work I was able to populate the tags to match the categories.

Now it can only get better, right? I have moved to using subversion to pull the latest stable release, so that takes a big chunk of time out of the equation, and now my tagging will happen at the time of posting, rather than being a pseudo-tag solution pulled from post categories. Or will it? I wonder if the tags tab in ScribeFire will do the trick?

We shall see.

The 3.0 version of the Google Sitemap generator seems to not be working, however, but I may have b0rked something there myself, and I will try again later.

Oh, and those sql statements?

If I remember correctly (I didn’t keep notes like I should have):

INSERT INTO wp_term_taxonomy (term_id, taxonomy, count) SELECT term_id, ‘post_tag’, count FROM wp_term_taxonomy WHERE taxonomy=’category’;

INSERT INTO wp_term_relationships (object_id, term_taxonomy_id) SELECT rel.object_id, tax.term_taxonomy_id FROM wp_term_relationships AS rel, wp_term_taxonomy AS tax, wp_term_taxonomy AS ttx WHERE rel.term_taxonomy_id=ttx.term_taxonomy_id AND ttx.term_id = tax.term_id AND tax.taxonomy=’post_tag’;

I could have brought the descriptions across from the categories, too, but I didn’t think about it until just now.

Edit: I found the issue with the site-map generator. It required a tweak to the memory limits in my php.ini :/

evardsson.com: stuff that w0rks