So, last time I detailed using git to work with your svn trunk. But many of you asked, “But Ralph, my svn repo has many branches and many tags because developers love branches and tags! How can I work with that?” Well, since no one reads this blog and no one actually asked me that, also misspelling my name in the process, let’s just pretend that what I write is relevant.
So you want to work with multiple svn branches (not to be confused with git branches). What you have to do is clone the svn repository in a different way, like this:
$ git svn clone https://somesvnrepo/svn/project -T trunk -b branches -t tags
This should work in most cases. The arguments to the -T, -b, and -t switches are the paths that the trunk, branches, and tags are in respectively. Typically, your branches and tags should be what I put above, but just in case it is different in your case, there you go.
Working with your shiny repo
After a short time in which humans achieve interstellar travel, git finishes cloning, and you have access to the entire svn repository. Now, let’s say you wanted to start working on trunk. Like before, you should checkout a branch, but this time it’s going to use trunk as it’s parent:
$ git checkout -b BranchOfTrunk trunk
But Lo! You have the entire repo, so you can checkout that branch from whatever branch you have in subversion.
$ git checkout -b BranchOfSubversionBranch subversion-branch
Now, you can switch between BranchOfTrunk and BranchOfSubversionBranch, and you’ll get all the code associated with trunk and subversion-branch respectively. No more checkout of a branch ever again, wasting precious keystrokes you could use to post to Facebook.
If a new svn branch is created on the server, make sure to run the following command to see it:
$ git svn fetch . (updating blah blah) . . $ git branch -a
The last command will show you all the branches, local (your own branches) and remote (every dumb svn branch), for this repository.
NOTE: git svn fetch and git svn rebase are almost exactly the same. fetch will update the entire git repository with anything not received from svn. rebase is concerned only with the parent of the branch you have checked out. If you recall last time, git svn rebase was equivalent to svn update. Now you can work with the same workflow as I mentioned before, working, committing locally, rebasing, etc.
Merging from subversion branch to trunk? BALDERDASH!
Now, let’s say that you want to commit a series of changes into a subversion branch, but you also want to commit the same changes in trunk also. What I’m going to show you is the workflow that I go through most of the time. I think it’s the most effective way to accomplish it in git.
First, you can run a fake dcommit.
$ git svn dcommit --dry-run Committing to https://svnserver/svn/project/branches/subversion-branch ... diff-tree b64fdc9250bbe04b3246214ade509e0b0d9d912d~1 b64fdc9250bbe04b3246214ade509e0b0d9d912d
The “–dry-run” is key here, for two reasons. First, you’ll be able to see what branch you are actually committing to in subversion. Not a bad idea, since you’re working in a git repo that has all your subversion branches.
Second, you’ll see a diff tree with some of the commit hashes, one corresponding to each time you did a commit locally, in order. You will want to keep the values of the hash around, because next we are going to “cherry-pick” them into trunk:
$ git checkout BranchOfTrunk Switched to branch "BranchOfTrunk" $ git cherry-pick b64fdc9 Finished one cherry-pick. Created commit e4a7971: Your commit comments here 12 files changed, 58 insertions(+), 66 deletions(-)
You’ll notice I only used the first 7 digits of the hash (b64fdc9) to do the cherry-pick. That’s all you need to use…git will pick out the revision from just those seven characters. What this does is pulls the change from the other branch into this branch. If you have more than one commit, you should do this multiple times, in the order of the commits. But then you have the things you did on the branch ready to be checked into trunk!
This is the way I usually work. You may decide that doing a subversion merge is easier for what you are trying to do (I sometimes do also). I’d also like to know if there is an easier way to do this. This doesn’t seem the easiest way, but was the easiest way I could find so far. And I googled for like…20 minutes.
Hopefully this helps…someone. One person, at least.
Script-fu: cat directly to X clipboard
Have you ever wanted to ‘cat’ a file directly to the clipboard? OF COURSE, why else would you be reading this sentence?
Simply install ‘xclip’, which is simple also, if you are on ubuntu:
sudo apt-get install xclip
Anything that you pipe to it goes to the X11 clipboard. Once there, you can just hit the middle mouse button to paste it where you want, just as if you had highlighted it. So you can do things like this:
$ cat some.file | xclip $ nslookup somehost | xclip $ ./runsomeawesomescriptthatyouwanttheoutputintheclipboard.sh | xclip
maven-jmeter-plugin release
A better JMeter Maven plugin
UPDATE: You can find the information about the JMeter Maven plugin here
Recently my co-worker James suggested we automate our tests on our project using JMeter and gave me his webpage about the trials and tribulations he went through to get it set up. It linked to a wiki page, in which someone had created a JMeter plugin for Maven.
Well awesome, it shouldn’t be too hard to set up. And it wasn’t, I had the JMeter tests up and running in a short amount of time. But one of the problems was that I wanted to set it up in a more generic way so that we could define different parameters on each of the CI environments we ran.
For this task, I first tried using filtering in maven, which I got working. But what you end up with is a JMX file that is basically unusable by default in JMeter. If you ever wanted to run it again standalone in JMeter, you’d have to modify the variables in the JMX file to work correctly. Vice versa, if you set up your test using JMeter, you have to remember to modify it so that the maven variables you need are in the places you need them.
JMeter already has a system in it where you can define variables in the JMX files (and give them defaults, fancy la la!). For example, say you want to define a variable for a host name. Inside your JMeter JMX file, you can do something like this:
<stringProp name="HTTPSampler.domain">${__P(someVariableName, localhost)}</stringProp>
Now, you have defined someVariableName to be a variable within your JMX file. The second value, in this case localhost, is the default if no variable override has been given.
The way to override these variables is with the -J option on the command, in this form:
-JsomeVariableName=yourhost.comand all the variables called someVariableName will have the value yourhost.com.
Now, with the minor modifications I have made to the JMeter Maven plugin, you can now define the values for these variables inside of your pom.xml, like so:
<jmeterUserProperties> <someVariableName>yourhost.com</someVariableName> </jmeterUserProperties>
and it is just the same as using -J on the JMeter command line.
The way we’re actually going to use it is to combine it with maven variables, like so:
<jmeterUserProperties> <someVariableName>${ourhostname}</someVariableName> </jmeterUserProperties>
So now, we can just do:
mvn -Dourhostname=ourspecialhost ...and be able to run site specific JMeter tests with only changing the arguments on the command-line.
I will be putting together a page in the next day or so with all the libraries needed to set this up, similar to the wiki page.
