Open Source Portal Project Honored as Catalyst

Campustech did a short piece on JA-SIG uPortal winning EDUCAUSE’s Catalyst Award, where they mentioned the award, and then quoted some bits from Jim H…

Jim Helwig, the project manager of the uPortal project at the University of Wisconsin at Madison’s Department of Information Technology, said the project represented the cooperative spirit of higher education.

“It is great to be a part of this,” he said. “This is a great example of higher education institutions working well together and accomplishing a lot…. We should feel proud.”

and Jonathan Markow…

Jonathan Markow, chairman of JA-SIG, said the award “is particularly meaningful because it reflects the robust health and size of our community, as well as the maturity of the uPortal platform.”

Fuel for Thought: Financial Page: The New Yorker:

In calling for a law requiring better gas mileage in our cars, then, voters are really saying that they’re unhappy with the collective result of the choices they make as buyers.

This is a neat quote, summing up how competitive pressures can cause every individual to become pressured into pursuing a course of action which we all agree adds up to undesirable conditions — in this case higher gas consumption. Instead of a “rising tide lifting all boats” our main motivation seems to be making sure that any changes in the tide don’t push our neighbors up higher than ourselves.

Much a non-governmental intervention thinker as I am, it does seem like modern political/economic bodies already make enough wide-ranging, stage-setting policy that this is a good candidate for more of the same.

Chris’s new favorite before going to bed, or sitting on the couch thinking line

> “Hey, Daddy… I don’t like you, I love you!”

Well, Chris did for the first time yesterday, anyway. I find this exciting whether the rest of the world thinks it’s TMI.

Soo… yesterday I completed my 2.3.1 Sakai vendor branch merge, and it’s now up on a Rutgers test server. It’s been sanity tested, and is ready for further banging. Speaking of banging… it did take quite a few steps to get to this stage…

Note: 2.3.1 is a small merge, I think it was only about 15-20 affected files. Having said that, it took almost 3-days to get this working right, and do the merge using SVN’s tools, both because of my relative inexperience with SVN and the way Rutgers initially setup our repository. Having said that, I do believe that going through this pain will make the next larger merge (2.4? 2.5?) easier, as well as being good experience to ease migrating to Samigo, Melete, and JForum 2.4.

Notes

• I used Glenn’s .subversion/config for things like auto-props and eol conventions. SVN sets a lot of commit preferences on the client side, so I’ll commit this as well, and we should try to sync up on a common configuration
• Keyword substitution had to be turned on in our repository (svn:keywords) in order to get svn diff and svn merge to work as promised and omit spurious conflicts caused by keyword substitutions — this especially hurts if your files use the $URL$ keyword and come off of a SVN tag…
• I had to do a clean import of 2.3.0 into our vendor tree in order to get clean diffs when I pulled in 2.3.1, since keywords had to be substituted for both imports
• I had to use the trunk version of svn_load_dirs.pl and patch it — see Bug 2789 — to get the vendor branch to work
• /sakai/trunk in our SVN has been updated to point to the new code, through externals mappings, though given my experience with SVN merging we will likely move to a fully realized trunk in the not too distant future.
• /vendor/sakai/current is an exact replica of 2.3.1 minus 5 files that SVN would not import correctly (1 croation js calendar localization and 4 docbook XML files)
• Then I ended up merging changes from 2.3.0 -> 2.3.1 module by module into our local Sakai repository

That was it!

So… working on doing a relatively small SVN vendor branch upgrade, and so far finding things much more difficult than it seems like they should be.

Problem 1: This was my fault — I checked in a vendor drop using svn_load_dirs.pl which had different line endings from my existing SVN tree. Of course, that resulted in a lot of diffs showing up. Fixed that by reimporting after setting the .svn/config file to also use native line endings, to hopefully resolve things. Which leads to:

Problem 2: Keywords – $Id$, $URL$ don’t seem to be ignored by svn merge or svn diff. This results in the same problem I had with CVS — lots of single line conflicts because I imported from a different tag in the upstream repository, which of course changed all the URL values. Setting svn:keywords on the various files, and then rechecking them out seems to result in them being recognized and substituted in the checkout — but the svn merge still seems to be picking them up as conflicts… not sure where to go from here.

I want to like the SVN provided tools — svn merge in theory sounds like exactly what I want, but getting things to work right has certainly been frustrating.