Posts Tagged ‘subversion’

Writing a hg to subversion gate

Using a decentralized version control system (DVCS) like Mercurial (hg) or Git as a client for Subversion is very common. With the unique features of a DVCS a developer can have both the features of offline development and local branching while still being able to push to a subversion server. This approach is often used in environments in which subversion is the given version control system. While the approach of using this bi-directional push and pull mechanism, provided by git-svn or hgsubversion, works perfectly for one developer, it has limitations working in a team using the usual DVCS push and pull concepts.

The following article will outline the current limitations of bi-directional dvcs to subversion bridges and shows a simple approach to implement a solution for a certain instance of the problem.


GIT vs. SVN: 2:0

Again, git vs. SVN. Last time, it was big win for git. And guess what, git will strike again.

I mean nobody is perfect (expect Linus, but there is just one – as he mentioned once), so we actually fail writing bugfree code. Therefore we end up sitting in front of a huge code base trying to figure out what’s wrong. Thanks to our agile development process we usually end up fixing code we are not into.

So the facts:

  • We don’t know the code
  • We don’t have a clue where to search
  • We are lazy

Okay, if we drop 1. and 2. we still have to find out what went wrong. So as we tend to get our evening beer fast and don’t want to waste time, we use git bisect to find out when the problem was introduced.

Assume following commit history:

a –> a’ (bug introduced) –> b –> a” –> c

When we bisect the problem, we will end up doing a quick search on the commits, marking buggy commits/trees bad and those that work fine good. This means, we mark c as good, then git will take us to a. We mark that commit as good, which will git move to b. If we mark b bad, git knows that a’ must introduce the bug. Than just view the diff and you might know where to find the bad code and how to fix it.

Well, as long nobody trashed the history with their ‘fixed a hundred bugs’ commits, containing like thousends of unrelated changes. In those cases, just bisect your collegue. git vs. SVN: 2:0

take it with humour

GIT vs. SVN: 1 : 0

I used git for the last 6 month in a big project. The project itself is not maintained
in git but in subversion as this is what developers know and what project leaders like to use
for several reasons.

In fact it’s not a bad idea to actually use subversion as version control system, particularly if
the developer are used to it. Well, I don’t care about that. Thanks to git-svn I could use
git as my subversion frontend. For sure, the distributed architecture of git didn’t help me that much when it comes to exchanging changes as I was the only developer using git.

But thanks to the repository format and git rich featureset, I found myself using git in a
much more productive way than people could use subversion.

What I really love is pickaxe. You can use that feature by passing -S to git log causing the log
to search for the string in the commit history and display all the commits that contain these changes.
Actually one of our developers had a problem with a blur event in the java script code, causing
all forms in the script to lose their focus all the time. He was just searching for the point all the
time as going through the commit messages was obviously too much time consuming (with about 100 commits per day). To make a long story short: I’m really a Javascript dumbass, but I just picked the
latest commits having a blur in their name with git log -Sblur and I found 2 promising commits. Showing him the commits actually solved the problem. He just missed one point in the thousands lines
of Javascript containing the blur event that caused the problems. Okay so here are the statistics for that event: Subversion with incremental search, but Javascript knowledge: 3hours. Git without any knowledige and a lazy person using it: 10mins. GIT vs. SVN: 1:0