git How-To WebApps

Getting Around the Politics of Subversion with git

This is the nightmare scenario. You are working with a coder who overwrites your changes in subversion. You’ve told this coder once, twice, three times, “Hey, please don’t do that. Hey, let’s talk about your changes before you commit them.”

But this coder for some reason thinks that he or she is the gift of the gods when it comes to coding, and continues to overwrite your changes.

This is where git comes in. If I had learned about this feature of git and the idea of accepting or rejecting changes in git sooner, I would have avoided the whole nightmare of re-comitting code and lengthy merge debates.

Most projects you work won’t involve the worst case above. Most of the time, there will be a great developing rule that says never commit bugs into subversion. But whenever you have to re-factor code and commit each line, branching and then later merging can be an issue in subversion, and it’s slow too.

On a project that I’m working on now the client wants only good code in svn which is great, and so I’m using git with svn. I got this idea thanks to Jakob Heuser. Thanks, Jakob!!!!

This is where git comes in. Here’s a quick cheat sheet and it assumes you are using GitHub:

mkdir newlispoauth
cd newlispoauth/
git init
touch README
git add README
git commit -m ‘first commit’
git remote add origin
git push origin master

Now we have to pull in changes from subversion:

mate .git/config

In the config file add something that looks like this:

[svn-remote “newlispoauth/trunk”]
  url =
  fetch = :refs/remotes/newlispoauth/trunk

Now we’re gonna fetch the subversion repo:

git-svn fetch newlispoauth/trunk
git checkout -b local-svn/trunk newlispoauth/trunk
git svn rebase
git checkout master
git merge local-svn/trunk
git mergetool # if there are conflicts with the README file above
git add README # if you had to make changes with the mergetool
git commit
git push origin master

Now you are working with “master” and “local-svn/trunk”.

“master” is for your changes to share with your team on git-hub
“local-svn/trunk” is for you and where you push changes to subversion.

You basically pull in changes from newlispoauth/trunk and do your work in local-svn/trunk.

Let’s put the changes in master into “newlispoauth/trunk” and commit those changes to subversion:

git checkout local-svn/trunk # you did commit your changes in origin right?
git merge master
git-svn dcommit
TechBiz WebApps

How Do You Avoid Presentation Disaster?

It’s been a rough few days at work. We got hacked. I had to cancel a lunch with some pals at the Reverie. @alicetiara and @walnotes were gonna be there and everything was set for a pretty convivial conversation and some fun debate.

But the code used for my presentation didn’t work because the machine it was working on wasn’t configured correctly. There might have been an issue with someone overwriting my code, too.

How do you avoid presentation disaster?

For my part, I’m creating a tool called Noobwatcher that:

  • checks the repo for changes every N seconds — because of a high noobage level, I’m gonna check every second
  • the moment that there is an update send the diff to me via IM, email, twitter. Take your pick.
  • check the server configuration files important to my code every N seconds
  • the moment a configuration file changes send the diff to me via IM, email, twitter — might as well use pownce, too.

Have you had to set something like this up? If so, what solution did you use?