Showing posts with label git. Show all posts
Showing posts with label git. Show all posts

Wednesday, November 23, 2011

Cygwin git-svn messed up

I upgraded my Cygwin from version 1.5 to 1.7 (finally), and found that git-svn command was broken

$ git svn rebase
Can't locate SVN/Core.pm in @INC (@INC contains:
/usr/lib/perl5/site_perl/5.10
/usr/lib/perl5/site_perl/5.14/i686-cygwin
/usr/lib/perl5/site_perl/5.14
/usr/lib/perl5/vendor_perl/5.14/i686-cygwin
/usr/lib/perl5/vendor_perl/5.14
/usr/lib/perl5/5.14/i686-cygwin
/usr/lib/perl5/5.14
/usr/lib/perl5/vendor_perl/5.10
/usr/lib/perl5/site_perl/5.8 .) at /usr/lib/git-core/git-svn line 42.

Usually this error indicates that subversion-perl package is not installed, but that was not the case as we can see it from cygcheck output:

$ cygcheck -c subversion-perl
Cygwin Package Information
Package Version Status
subversion-perl 1.7.1-1 OK

As it turned out, the problem was in the package dependency management. From the error above we saw that perl was looking for SVN/Core.pm in /usr/lib/perl5/vendor_perl/5.14/i686-cygwin directory. But the latest subversion-perl installed it in the different place

$ cygcheck -l subversion-perl
...
/usr/lib/perl5/vendor_perl/5.10/i686-cygwin/SVN/Core.pm
...

The problem was solved by downgrading perl from 5.14.x-x to 5.10.x-x.

If you have the same problem, check which version of perl package you have installed

$ cygcheck -f /usr/bin/perl
perl-5.10.1-5

It must be the same as the version used by subversion-perl.

Saturday, January 29, 2011

Counting modifications in Git repository

Recently Michael Feathers wrote a blog about Open-Closed Principle, where he described simple technique that measures the closure of code. I created a Groovy script which implements this technique for Git repositories. If you run it from the root of your Git project, it produces a CSV file with the statistics of how many times files have been modified. Feel free to use this script to find hot spots in your Git repository.

Monday, January 24, 2011

Git + Maven

When I first started working with Git in my Maven projects (three years ago), it was very awkward. Half of the release commands didn't work at all. Second half worked, but with ugly workaround via faked remote repository, which violated the entire Git philosophy.

Since then most of the issues have been resolved, including the following three which I mostly needed:

  • support for local Git repositories;
  • separation of git-commit and git-push commands in Maven release plugin;
  • critical bug fixes in Maven release and scm plugins.


I created a cheat sheet describing the way I typically set up and manage Git-Maven projects. Feel free to use it in your projects as well.

Thursday, November 26, 2009

Finding first broken build with git-bisect

With git it's so easy to find which commit broke the build. Suppose you know that commit with tag release-1.0 was good, i.e. all tests passed. The latest commit, however, is failing.


So the build was broken somewhere in between release-1.0 and master HEAD. To find the exact one you just need to run two git commands. First

$ git bisect start HEAD release-1.0

Here you specify which commit you know is broken, and which one you remember was successful. After running this command you can see that git marked two commits with good and bad labels, and put the search starting point at the revision in the middle.


The second command is git bisect run cmd, where cmd is the script used as a criterion of successful build. If you use Maven then your command would be:

$ git bisect run mvn clean test

After you hit Enter button in the terminal, git starts running your criterion script using binary search algorithm. It might take time to finish this task, which depends on the number of revisions and the execution time of the script. Eventually it stops and shows you which commit caused the build failure.

7933e4658ea852754120fbc8fec34b2b85932e48 is first bad commit
commit 7933e4658ea852754120fbc8fec34b2b85932e48
Author: Andrey Paramonov
Date: Wed Nov 25 21:07:30 2009 -0500

Changed method implementation

:040000 040000 c0f3f9ef13d7daa4671205b9518c168a9ac10fe3 5a1cf3d6fb28d6f815c172319630b5d55ce4dc10 M src
bisect run success

If you look at the visual tool, you will spot the first bad commit by the label bisect/bad.


Resources

• git-bisect manual page

Thursday, August 13, 2009

Git on Cygwin

Here are the steps I perform to use Git on Cygwin:

• Install necessary packages: git, gitk, subversion, subversion-perl. That's because I use Subversion via Git bridge.

• Amend C:\cygwin\lib\perl5\vendor_perl\5.xx\Git.pm file using this patch. That's to fix small bug causing "Permission denied: Can't open '/cygdrive/c/DOCUME~1/myself/LOCALS~1/Temp/report.tmp'" error.

• Configure white spaces using this command to fix trailing spaces warnings.

Friday, July 03, 2009

Collaborating Using git-svn

I like Git, and I'm using it everywhere. It gives you so much power that once you taste it, you won't want to come back to traditional source control systems. One of the Git benefits is collaboration friendliness. Git encourages collaboration, ideas exchange, and code review. If your team is using Git then you know how easy it is to share your code with your co-workers. But sometimes you are the only person in the team who uses Git, and everybody else is on Subversion. Don't worry, you still can share your ideas by means of git-svn tool, and here I want to show you how. The process is not as simple as native Git (via pull/push or patch/apply) but it's better than nothing.

Suppose you have an idea and you are eager to try it. You don't want to create a branch in Subversion because you don't know if your idea will work out, and committing all your crazy stuff in Subversion can easily pollute it. So you create a local Git branch and start working.

$ git checkout -b topic/great-idea

You code, test, git-add, git-commit, code, test, etc. At some point you see that your idea was great indeed and it's time to show the amazing results to your teammates. Now you need to "push" your Git branch to Subversion. To do this you have to create Subversion brunch first

$ svn copy http://svn.repo.path/project-name/trunk \
http://svn.repo.path/project-name/branches/great-idea \
-m "Created branch for my cool stuff"

Next step is to add this Subversion branch as a remote branch to Git configuration. Open .git/config file with a text editor. You should see something like this

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = http://svn.repo.path
fetch = project-name/trunk:refs/remotes/trunk

If you built your Git repository by cloning Subversion repository (which you most likely did), you will have one or more svn-remote sections in this configuration file. You need to add another one for new Subversion branch.

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = http://svn.repo.path
fetch = project-name/trunk:refs/remotes/trunk
[svn-remote "svn-great-idea"]
url = http://svn.repo.path
fetch = project-name/branches/great-idea:refs/remotes/great-idea

Next step is to fetch Subversion branch, but first you need to know revision number when this branch was created. Run this command

$ svn log --stop-on-copy http://svn.repo.path/project-name/branches/great-idea

You should get something like this:

------------------------------------------------------------------------
r2165 | andy | 2009-07-03 14:36:59 -0400 (Fri, 03 Jul 2009) | 1 line

Created branch for my cool stuff
------------------------------------------------------------------------

The first number of the output is what we are looking for:

$ git svn fetch svn-great-idea -r2165

Now you have the Subversion branch in you Git. If you run git branch -a command you will see "great-idea" branch in the list.

 master
* topic/great-idea
great-idea
trunk

You shouldn't work on remote branch, so let's create local one:

$ git branch svn-branch/great-idea remotes/great-idea

I put it in svn-branch namespace just to make it visually clear that this branch is in synch with Subversion. The next set of commands is a standard way to bring your work from one local branch to another. In our case: from initial topic/great-idea to svn-branch/great-idea

$ git rebase svn-branch/great-idea
$ git checkout svn-branch/great-idea
$ git rebase topic/great-idea

That's it. Now you are ready to commit your code to Subversion:

$ git svn dcommit

Done. As an option, you can delete initial branch because you have a Subversion backed copy of it:

$ git branch -D topic/great-idea

Resources

• Ian Boston's post explaining how to add Subversion branches to Git.