TimShadel.com

I started to realize how cool git is when I saw this:

Read more…

I don’t know how many years I’ve used the following command chain to add all my unknown files to Subversion:

svn st | grep ? | sed -e "s/? *//" | xargs svn add

Inevitably I occasionally end up using that string on some directory where I have a space in the pathname, and everything bombs. So I finally got around to adding it to my ~/.bash_aliases file today, with the additional -e "s/^\(.*\)$/\"\1\"/". Simple, really (just make sure that something sources that file):

alias svnaddall='svn st | grep ? | sed -e "s/? *//" -e "s/^\\(.*\\)$/\\"\\1\\"/" | xargs svn add'

I may still play with the actual alias name to see what sticks in my every day practice. Maybe I totally missed a way simpler way to do this. Seems like I’ve done something like this since back when I started using Subversion at release 0.18 or 0.19. Maybe I haven’t kept up, so I’d be happy to be enlightened.

Do you have anything tiny hanging around that should be automated right now?

Tonight we’ll be deploying the first beta of a major new feature of our product that my team’s been working on since September. Don’t get me wrong, we’ve release updates to our product every two weeks. Our branching strategy is such that we have one month cycles on /trunk that branch on release, and are followed up by a second release two weeks later with some new functionality, but no major restructuring. That keeps us building along happily every two weeks with a way to take on bigger work on the four week branch.

Pieces of it have been growing in the app for some time, but tonight we flip on the central piece for a few small groups. We had a hectic day yesterday, and ultimately discovered a networking problem two teams away that prevented us from hitting our well-publicized deadline last night (always make sure to setup your QA environment as closely as possible to your production environment). All that should be resolved today. Everything’s done.

Now there’s nothing more to do for this release but sit and wait to see which way the wind blows.

A megajar or uberjar is one jar file where all the contents of all dependent jars have been unpacked, and then everything has been re-jared up together again.

This is normally a very Bad Thing.

However, there are occasional one-off uses for such a thing. I’ve made a habit of following the advice given by the Pragmatic Programmers (here and here) by always creating a tools or util directory off the trunk of my project. I find that there are occasionally little things I do from the command-line to mass-update the source (for a package refactoring, perhaps), or there are small tools needed for one-time data conversions when a release is rolled out. I put those things in version control instead of losing them. I like to put the JIRA issue key in their name (e.g. PRJ-12-migrate-start-times), since this emphasizes the problem the tool is solving as well as its use only for the nonce.

For one such tool we did lately, we needed only one dependency — the database driver jar file. Since we don’t run these things in production, it was important to make this thing as simple to use as possible. Hence, we decided that bundling the driver for this one-off tool was simpler than a lengthy set of instructions for the Release Team.

The command I used was

mvn assembly:assembly -DdescriptorId=jar-with-dependencies

You can find more information around the web. I found the Maven2 Assembly Plugin docs fairly helpful. I also added this snippet to my pom.xml:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-assembly-plugin</artifactId>
  <configuration>
    <archive>
      <manifest>
        <mainClass>my.package.to.my.MainClass</mainClass>
      </manifest>
    </archive>
  </configuration>
</plugin>

So that the entire thing can be run with a simple Java command:

java -jar target/PRJ-12-migrate-start-times-1.0.0-jar-with-dependencies.jar

Got any tips for using the tools directory in your project?

Ruby has been a growing blip on my radar for a while. In this show I describe my first real production Ruby application at work — and it’s small enough to talk about a few details. I cover how we use Ruby to automate some interactions with Subversion and Maven. I’ve done some Rails stuff too, but that’s a whole different topic. Conclusion: Ruby should be something you use to complement Java. If you want a Ruby vs. Java fight, you won’t find it here.

Some great resources metioned in the pocast are Programming Ruby and Agile Web Development with Rails.

Download Ruby Infiltration.

Listen now with the Flash player.

Just wanted to jot down a quick Subversion recipe. I’m doing a merge today, and I wanted to know which of the 25 folders on my branch actually changed. Here’s what I used to figure it out.

svn diff -r 4649:HEAD http://myserver/svn/branches/mybranch | grep "Index:" | sed -e "s/Index: \([^\/]*\)\/.*/\1/" | sort -u

Downsides: If I’ve got a folder that has only directory structure changes, I won’t see them there.

Listen now with the Flash player.

This week is version control. Today’s show is simple: Subversion Rocks. Check out why.

Download Why Subversion Rocks.

Show Notes

Check out Subversion for the command-line and the server installation. TortoiseSVN is an excellent Windows client that plugs into Windows Explorer. We use the Apache SSPI authentication module and apply it to our Subversion repositories. We’ve got the ViewCVS version pulled right from the CVS source to get Subversion support. It’s stable, and well worth the quick install.

Listen now with the Flash player.

Download Version Control Attributes.

This week is focused on version control.

Show Notes

Today’s show covered a few basic attributes important to using version control successfully with Java. The principles covered in Software Configuration Management Patterns are excellent. The two books from the Pragmatic Programmer Bookshelf, on Subversion and CVS, are excellent references to the tools that tightly weave excellent principles into the book. There’s also great free book for Subversion – it’s mainly a tool reference, but excellent.

In some ways I wish that Subversion branches were metadata instead of engrained in the directory structure and “human use” of the tools.

I’ve been excited about the idea of an Eclipse plugin for Subversion ever since I saw the initial announcements about Subclipse. I recently installed version 0.9.7 via the update site (http://www.loonsoft.com/updates), but was not impressed.

Subclipse seems slow! I’m not sure if it’s just the JNI component, or if there’s something else affecting it, but it’s slow to load when Eclipse opens a Subversion project. It’s also incredibly slow the first you right click on a project and choose Team -> Share, and choose SVN. It takes forever for the Finish button to be enabled!

What I want is a clean replacement for the CVS plugin, including Team Synchronizing. I suppose I should just shutup and code some help for the project, but I’m becoming increasingly discouraged by the difficulty of having patches accepted for the code I use frequently (Note: I’ve never submitted a patch to the Subclipse project), and so I’m becoming more content to wait for the updates to be done by those closer to the project, even if it takes a bit longer.

I’ve played with Furl.net’s Site Integration and I’ve begun to wonder if there’s other content that’s useful in a sidebar. For example, could I take an RSS feed like CodeHaus issues submitted by me and turn it into a sidebar? Could I merge that with JIRA issues I’ve submitted and others to get a full watch list across several distributed systems? If so, I’m sure I could also do the same for open issues assigned to me. What about Confluence posts, and perhaps Subversion or CVS commits? Would it be beneficial? Interesting questions.

This piece —

Alternatively, if you’re taking a laptop, you can have Pebble up and running on Tomcat in 5 minutes.

From Simon Brown’s JavaOne tips got me thinking. I could use Pebble to edit my blog anywhere, and use Subversion to keep it syncrhonized. I think it would work. All the config and data files for Pebble are text (XML), and they all live in one directory hierarchy. I can use a local installation of Pebble on my laptop, at work, and at home. I can use Subversion to keep them in sync, and ultimately decide when a group of edits goes to my public blog site. Perhaps I’ll try it.

It seems like Dave and Andy do this, but they edit the source files directly. I know that bloxsom supposedly supoports using Subversion, but I never got it to work. Blosxom uses files as well, but Pebble vs. blosxom is meat for another post.