Use compile errors like bookmarks....

I have started a new practice and it is really working out great!!!  I am using compiler errors as my means of knowing where I left off on a certain task.  For example, it is 4:45, and my wife is cooking a mean meal (by "mean", I am saying that if I don't get home on time, then she is going to be very mean to me for the rest of the night).  I don't have time to fix all of the compiler errors so I just check it in to version control.  That way, when I come back to work in the morning, or after the weekend, I know just where I need to start again.

The best part of this new process, is that none of my co-workers mind.  At all.  They don't care one bit.  They actually do not think that it impedes on our Test Driven Development practices or our Continuous Integration Builds......amazing, eh?

How am I getting away with this new process of mine?  If you haven't guessed it by now, it is because I am using Git.  My checkins that I do where things don't compile, are only checked in locally to a branch on my computer.  The rest of the team doesn't see these compiler errors, and therefore, they are never affected.

Just one more reason why you should look at distributed version control - no more "mean" dinners for me.

:)

Groovy / Grails Training

Today begins the second day of a four day Groovy / Grails training class that we are giving to Grand Valley State University. This is the second time that I have given this training and I couldn't have asked for a greater class.  The students are experienced, energetic and fun.  During the Object Oriented Analysis and Design portion of the class, they came up with solutions to the workshops that were very creative and interesting.

Today we will complete the Groovy portion of the training.  We are going to review:

• Collections
• Closures
• Groovy Sql
• Testing
• Meta Object Programming

The remainder of the week, we will be discussing Grails and the various technologies that make up the Grails framework.

If you or your team is interested in Groovy / Grails Training, feel free to contact us.

Git and Subversion :- New Subversion Branch Created

If you have read any of my previous blog posts before, you know that I am use Git in order to track Subversion repositories. Recently, I had another experience that I had to resolve and I wanted to make sure that I share it with you.

The team decided to cut a branch of the code that I have been tracking. After they did that, I ran git svn fetch. After doing this, Git realized that a new branch was created and it started to search through the subversion repository to pull back any history that it might not have.

This probably is a good idea, if I were tracking the entire Subversion history, but I am not. The result was Git was starting to pull back history that I didn't have in my Git repo, nor history that I wanted. It would have taken hours to pull in that amount of history, and as I mentioned, I was not interested in retaining the whole entire repository.

In order to resolve this, I performed the following command:

git svn fetch -r:HEAD --no-follow-parent

I think that the most important part of this command is the --no-follow-parent. This tells git not to look back in time at the history, and just pull in the information from the specified starting point.

I hope that this helps someone else out there....

Pay it forward.

Git Push :- Only Current Branch

Recently, when sharing a bare repository on my machine with one of the members on my team, we ran into a funny scenario. But first, it is probably worth mentioning the following information:

• We are currently using git to push to svn
• We have a master branch that is tracking the svn/trunk

I created a new bare repository that will allow us work together on a specific task. When using Git, you only want to push into a bare repository (a repo without a working directory), instead of the real one. He was able to pull the code just fine, but when he tried to push the changes into the bare repository, not only did it try to push the branch that we were currently working on, but it also tried to push the master branch as well. That is because the bare repository that I created, had a master branch, and so did his local, and therefore it was matching on that branches name. (Note: I was also experiencing this same behavior).

After Googling for an answer to the behavior and hoping to get the desired behavior of only pushing the changes from the branch that I am currently on, I found git push current branch, on StackOverflow. If you are like me, and want the desired behavior of only pushing the current branch that you are on to the remote repository, and not all of the branches, just run the following command in your git repository:

git config push.default tracking

There are other options besides 'tracking' but this is giving me the desired behavior that I was looking for...

Enjoy...

Git and Subversion :- Bringing others on board...

In the previous post, Pulling a Subversion Repository into Git Locally, I shared the process that I went through in order to pull Subversion into Git so that I can start using Git locally with Subversion as my remote repository. Since that time, I have been trying to figure out the best way to get Git to Subversion repositories set up for others on my team. I have gone through a lot of trial and error and now I believe that I have finally come up with an easy step-by-step solution.

Before I begin, let me first say that you probably want to follow these instructions for two main reasons:

Cloning a Subversion Repository is very time consuming
If you have never cloned a Subversion repository using Git, you will be amazed at how long this process can take (depending on how much history you want in Git). I typically chose 1000 revisions in the past, and that could take up to an hour or more. This is no fault of Git, instead, Subversion is to blame. With this process, only one person has to incur that time investment. Everyone else, can just reap the benefits without the hassle

Fetching too much data
This was the problem that has stumped me for months. While I was able to alleviate the first challenge of the time investment for everyone, I could not figure out why Git was trying to retrieve so much history from Subversion. This amount of history was even earlier than the 1000 revisions of the initial clone. Finally, I figured out that it has to do with a property called branches-maxRev. Through the use of this property, we can make sure that when you perform git svn fetch, that it will not attempt to retrieve any more history than necessary. So, let's get started

By this time, I am already assuming that you have followed the directions from Pulling a Subversion Repository into Git Locally, and you already have a Git repository with the amount of history from Subversion that you desire. From that point:

1. Navigate to your git repo. Not the .git folder, but the folder containing that folder
2. Open your browser to the git svn man page
3. Scroll to the bottom section titled Basic Examples, and look at the third example
4. Locally, start the git daemon server by typing: git daemon. This will start a git server on your local machine that will allow others to pull from you.
5. Follow the instructions from the Basic Example starting with mkdir all the way to the end. Please note that the line that section that says server:/pub/project must be replaced with a valid git url (for instance git://jdcarlflip.blogspot.com/path/to/git/repo)
6. Once you have finished those instructions, in your newly created repo, open the file .git/svn/.metadata
7. Inside of there, you want to put a line under the uuid similar to the following branches-maxRev = 11111 where 11111 is the revision number that you do not want to go past. If you don't know what to put in there, look back at your original repo that you cloned from, and use the same number.
8. After you have done this, type in git svn fetch, and it should not attempt to retrieve any revisions that are older than the ones you have already

If there are any questions, please let me know.....Enjoy.

Mobile Dev Day :- iOS Development

This past weekend, I had the wonderful experience of going to MobiDevDay Conference that was held in my hometown, downtown Detroit. It was an amazing conference, and a big thank you to all of the work and effort that went into making it such an excellent and wonderful experience.

Since I am familiar with the concepts of Android development, I decided to spend some time looking at what it takes in order to develop an iOS application. I have never, ever seen what Objective-C even looks like, before this conference, and I am glad that I made the decision to look at it.

....fast forward to yesterday....
I was having lunch with a friend of mine, who is a polygot programmer. He told me about a wonderful FREE series on iTunesU from Stanford University that really helped him learn how to develop Objective-C.

If you are interested, here is the iTunes link.

Enjoy....

Git feeling a little sluggish....?

So after working in my Git repository for the past couple of months, I started to notice that things are starting to run slower. I remember the days when I first started using Git, it was lightening fast. Now, it is still fast....but I have been missing the lightening.

That is until I was told about the command

git gc --aggressive

This command has brought the lightening back to fast in git.

Share and Enjoy.