Tuesday, August 27, 2013

How to remove .svn folders recursively?


Validate the list of folders which will be removed:
$ find . -name .svn -exec ls {} \;

Run recursive remove:
$ find . -name .svn -exec rm -rf {} \;
This script is run from the current folder.  Be sure you've specified find -name properly.


References:

Wednesday, August 21, 2013

How to Install Git 1.8.3.4 on CentOS 6.4

  1. Check the CentOS version
  2. $ cat /etc/redhat-release
    CentOS release 6.4 (Final)
    
  3. Check git version
  4. $ git --version
    git version 1.7.1
    
  5. Enable/disable yum proxy settings (find/add "proxy" string with related proxy server)
    $ vim /etc/yum.conf
    
  6. Try to update git via yum package manager. But you will get the message that git is up to date
  7. $ sudo yum update git 
    
  8. Based on instruction from Getting Started Installing Git install git from sources:
  9. $ yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel gcc
    $ wget https://www.kernel.org/pub/software/scm/git/git-1.8.3.4.tar.gz
    $ tar xzvf git-1.8.3.4.tar.gz
    $ cd git-1.8.3.4
    $ sudo make prefix=/usr/local all
    $ sudo make prefix=/usr/local install
    
  10. Re-run bash shell and verify the current git version
  11. $ git --version
    git version 1.8.3.4
    
References:

Saturday, August 17, 2013

Git, Jenkins, Gerrit, Code Review and pre-tested commits


This post is a note to myself. There are bunch of tools on the market which can be successfully used in yours development process. But, I'm interested in gitJenkins only. Also, git/jenkins supports tons on different workflows, but here I'd like to talk about pre-tested commits.

So, what does it mean "pre-tested commit"? Initially this type of commits was introduced in TeamCity CI Server:
Typically, your team submits code to Version Control BEFORE verifying that it works, and risks breaking the build every single time — causing more problems than necessary. [2]

But, it's TeamCity and we need similar functionality in Jenkins.

There are several ways to get it:
  • Implement Jenkins plugin which can work with integration branches and simulate pre-tested workflow
  • Reuse existing tool like Gerrit
But you say Gerrit is a code review tool. And you are right. Fortunately, Gerrit support pre-tested commit in his code review workflows (see source [3]):

Gerrit Code Review represents a step-forward in the way the team work on the code and share idea and the ownership of the design and coding decisions.  (see [4])
 Tools required to support this workflow:

 To see all these in action I've added two videos which demonstrate this concept:


Also, it worth to review this slides. Here is nicely demonstrated why Gerrit is cool and why un-tested commit is bad.



References:
  1. Pretested commits – why does it matter to us?
  2. Pre-Tested Commit: No broken code in your version control. Ever.
  3. TeamForge Git /Gerrit Integration with Jenkins CI
  4. Jenkins CI and Gerrit Code Review dance together
  5. Jeknins - Designing pre-tested commit
  6. Open Stack - Gerrit Workflow
  7. Open Stack - Gerrit Jenkins Github

Tuesday, August 06, 2013

Typical .gitignore for Java Projects


I'm sure that every developer have some basic (skeleton) .gitignore file which is coping from project to project :-)

As a Java developer I'd like to talk about typical .gitignore file which can be added at the beginning the project (a la initial commit).

I've been using Github collection of useful .gitignore templates. It's very useful repo contains tons of standard .gitignores. General workflow is to assemble my .gitignore based on several templates:
But recently I've found very nice service gitignore.io which can generate nicely assembled .gitignore based on provided criteria:

Here is the generated file:
 
# Generated by http://gitignore.io

### Java ###
*.class

# Package Files #
*.jar
*.war
*.ear

### IntelliJ ###
*.iml
*.ipr
*.iws
.idea/

### Eclipse ###
*.pydevproject
.project
.metadata
bin/**
tmp/**
tmp/**/*
*.tmp
*.bak
*.swp
*~.nib
local.properties
.classpath
.settings/
.loadpath

# External tool builders
.externalToolBuilders/

# Locally stored "Eclipse launch configurations"
*.launch

# CDT-specific
.cproject

# PDT-specific
.buildpath

### Maven ###
target/

Very convenient. Have a try.