Comments on: Switching from SVN to Git: A Startup’s Perspective http://gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/ Eye Tracking For Everyone - Usability Services & Software Sat, 10 Mar 2012 06:40:21 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Tools Of The Trade : Brian Krausz from GazeHawk http://gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/#comment-859 Tools Of The Trade : Brian Krausz from GazeHawk Sat, 15 Jan 2011 02:10:53 +0000 http://www.gazehawk.com/blog/?p=77#comment-859 [...] great comfort knowing our code is stored completely outside of our infrastructure. We wrote a blog post about switching AWS: We have a lot of strange pieces of our infrastructure. Being able to spin up new dev servers [...] [...] great comfort knowing our code is stored completely outside of our infrastructure. We wrote a blog post about switching AWS: We have a lot of strange pieces of our infrastructure. Being able to spin up new dev servers [...]

]]> By: Santhan http://gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/#comment-389 Santhan Mon, 22 Nov 2010 19:39:56 +0000 http://www.gazehawk.com/blog/?p=77#comment-389 We're a team of three who commit code hourly to our SVN repo. We use WEBSVN and pull feeds from WEBSVN into OpenAtrium so that they display in each projects dashboard. We don't find ourselves having to branch and merge often. Our repo is on our development/staging server which is backed up daily. One of us has been pushing for a change to GIT for ages and I've been reluctant or not interested. From my understanding GIT is a system that would suit projects that have a large number of people committing code with each of these people being loosely connected ie: little communication. GIT appears to suit individuals that randomly contribute to a project and SVN seems more geared for (small) teams who work closely together with open communication channels. SVN can be clunky. I found a solution to it's clunkiness is getting to understand the most common commands well. We also have a few useful bash aliases setup to make the ride less bumpy. I'll post them should they be of service to anyone. <code> ## SVN TOOLBOX #checkout a project from our repo without typing the entire url #provide project path from root of repo and destination directory #example: svnco ourproject/trunk/5x local.ourproject.com svnco () { svn co svn+ssh://67.54.23.22/home/repos/$1 $2; } #remove all .svn folders. The project will no longer be under version control removesvn () { find . -name .svn -print0 | xargs -0 rm -rf; } # bash function to add all new files and directories in a working copy to repo # this funtion is used when you have many ? when running svn stat svnadd () { svn stat | grep "^?" | awk '{print $2}' | xargs svn add; } # the reverse of the previous command. usually used to get rid of old svn log files svndelete () { svn stat | grep "^!" | awk '{print $2}' | xargs svn delete; } # svn diff with color - in Ubuntu run: sudo apt-get install colordiff svndiff () { svn diff "${@}" | colordiff; } </code> We’re a team of three who commit code hourly to our SVN repo. We use WEBSVN and pull feeds from WEBSVN into OpenAtrium so that they display in each projects dashboard. We don’t find ourselves having to branch and merge often. Our repo is on our development/staging server which is backed up daily.

One of us has been pushing for a change to GIT for ages and I’ve been reluctant or not interested. From my understanding GIT is a system that would suit projects that have a large number of people committing code with each of these people being loosely connected ie: little communication. GIT appears to suit individuals that randomly contribute to a project and SVN seems more geared for (small) teams who work closely together with open communication channels.

SVN can be clunky. I found a solution to it’s clunkiness is getting to understand the most common commands well. We also have a few useful bash aliases setup to make the ride less bumpy. I’ll post them should they be of service to anyone.


## SVN TOOLBOX
#checkout a project from our repo without typing the entire url
#provide project path from root of repo and destination directory
#example: svnco ourproject/trunk/5x local.ourproject.com
svnco () { svn co svn+ssh://67.54.23.22/home/repos/$1 $2; }

#remove all .svn folders. The project will no longer be under version control
removesvn () { find . -name .svn -print0 | xargs -0 rm -rf; }

# bash function to add all new files and directories in a working copy to repo
# this funtion is used when you have many ? when running svn stat
svnadd () { svn stat | grep "^?" | awk '{print $2}' | xargs svn add; }

# the reverse of the previous command. usually used to get rid of old svn log files
svndelete () { svn stat | grep "^!" | awk '{print $2}' | xargs svn delete; }

# svn diff with color - in Ubuntu run: sudo apt-get install colordiff
svndiff () { svn diff "${@}" | colordiff; }

]]> By: Switching from SVN to GIT | Free practice test , mock test, driving test, interview questions http://gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/#comment-327 Switching from SVN to GIT | Free practice test , mock test, driving test, interview questions Tue, 09 Nov 2010 01:03:54 +0000 http://www.gazehawk.com/blog/?p=77#comment-327 [...] Switching from SVN to git [...] [...] Switching from SVN to git [...]

]]> By: Robert Cowham http://gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/#comment-324 Robert Cowham Mon, 08 Nov 2010 16:08:54 +0000 http://www.gazehawk.com/blog/?p=77#comment-324 BCS CMSG has a free event on experiences with Git in the Enterprise on 25 Nov 2010 in London if anyone is interested: http://www.bcs-cmsg.org.uk/events/2010-11-25.html Dan North (originator of BDD among other things) will be presenting experiences from his new company DRW in migrating SVN to Git. BCS CMSG has a free event on experiences with Git in the Enterprise on 25 Nov 2010 in London if anyone is interested:

http://www.bcs-cmsg.org.uk/events/2010-11-25.html

Dan North (originator of BDD among other things) will be presenting experiences from his new company DRW in migrating SVN to Git.

]]> By: Favorite Articles of the Week | MediaLeaf Blog http://gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/#comment-316 Favorite Articles of the Week | MediaLeaf Blog Sat, 06 Nov 2010 13:54:23 +0000 http://www.gazehawk.com/blog/?p=77#comment-316 [...] Switching from SVN to GIT: A Startup’s Perspective – GazeHawk [...] [...] Switching from SVN to GIT: A Startup’s Perspective – GazeHawk [...]

]]> By: Najaf Ali http://gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/#comment-309 Najaf Ali Fri, 05 Nov 2010 13:35:37 +0000 http://www.gazehawk.com/blog/?p=77#comment-309 "Merging remains to be seen..." This is technically not true. If you push/pull to/from a remote repository, you're merging branches (most likely your local master with remote master). It doesn't remain to be seen, you're already doing it! “Merging remains to be seen…”

This is technically not true. If you push/pull to/from a remote repository, you’re merging branches (most likely your local master with remote master). It doesn’t remain to be seen, you’re already doing it!

]]> By: links for 2010-11-04 — Business Developer Talk http://gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/#comment-308 links for 2010-11-04 — Business Developer Talk Fri, 05 Nov 2010 05:02:40 +0000 http://www.gazehawk.com/blog/?p=77#comment-308 [...] faster, automatically — try mod_pagespeed for ApacheDreamHost already has it installed….Switching from SVN to Git: A Startup’s Perspective | GazeHawk BlogHow to Switch From SVN to GitHub for Small TeamsShould Web Designers Know HTML and CSS?Multiple [...] [...] faster, automatically — try mod_pagespeed for ApacheDreamHost already has it installed….Switching from SVN to Git: A Startup’s Perspective | GazeHawk BlogHow to Switch From SVN to GitHub for Small TeamsShould Web Designers Know HTML and CSS?Multiple [...]

]]> By: kl http://gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/#comment-298 kl Thu, 04 Nov 2010 11:35:07 +0000 http://www.gazehawk.com/blog/?p=77#comment-298 GitX.app and speed are my reasons to use Git. However, don't believe that Git makes merging magically work. If you have conflicts, you will have to resolve them, no matter what system you use. I did have fetal-position merges even with Git. GitX.app and speed are my reasons to use Git.

However, don’t believe that Git makes merging magically work. If you have conflicts, you will have to resolve them, no matter what system you use.

I did have fetal-position merges even with Git.

]]> By: Soli http://gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/#comment-294 Soli Thu, 04 Nov 2010 08:28:29 +0000 http://www.gazehawk.com/blog/?p=77#comment-294 And bitbucket's issue tracker being slightly more complete than github's one might even help you get rid of github-trac... And bitbucket’s issue tracker being slightly more complete than github’s one might even help you get rid of github-trac…

]]> By: Eric Fode http://gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/#comment-293 Eric Fode Thu, 04 Nov 2010 07:41:06 +0000 http://www.gazehawk.com/blog/?p=77#comment-293 push -f will force a push to the server, it can cause loss of commits... so sometimes it will screw up your version history or you may break someone else's push because there is no version history left intact for git to use to figure out how to merge... if you have read through the book git pro you can ignore the rest of this comment A little on the merging, git will if it can always merge in the simplest way possible, for example if you have a local repo of your code and you branch it once and never touch the main brach and you merge it will simply "rewind" your changes back to the point that the repo was at when you branched the "fast-forward" your changes back onto the repo. If you make changes to your main branch (like a hotfix) git will rewind both branches then fast-forward them both assuming there are no problems that it is not able to resolve if there are problems like that it will simply mark them and ask you to use what ever diff tool to fix them that you have told it to use. All that said the reason that push -f could cause problems is that git does not have the history available so that it can rewind during merges good luck, eric push -f will force a push to the server, it can cause loss of commits… so sometimes it will screw up your version history or you may break someone else’s push because there is no version history left intact for git to use to figure out how to merge…

if you have read through the book git pro you can ignore the rest of this comment
A little on the merging, git will if it can always merge in the simplest way possible, for example if you have a local repo of your code and you branch it once and never touch the main brach and you merge it will simply “rewind” your changes back to the point that the repo was at when you branched the “fast-forward” your changes back onto the repo. If you make changes to your main branch (like a hotfix) git will rewind both branches then fast-forward them both assuming there are no problems that it is not able to resolve if there are problems like that it will simply mark them and ask you to use what ever diff tool to fix them that you have told it to use.

All that said the reason that push -f could cause problems is that git does not have the history available so that it can rewind during merges

good luck,
eric

]]>