Whether you want to build the software, run it, grow the community or just learn more about it, there will be content, workshops and design sessions for you to attend at the OpenStack Summit, Oct 15-18 in San Diego. Stick around Friday for the first OpenStack service day, a 1/2 day beach cleanup.
Register now! openstacksummitfall2012.eventbrite.com
Schedule
Speakers
Attendees
Share on twitter
Share on facebook
Tuesday, October 16
2:40pm
Surviving your first check-in: An engineers guide to contributing to OpenStack
Let me tell you a dirty little secret. While OpenStack is a great project, it is extremely complicated for and indivdual with an engineering/operations focus vs a programming focus to get to their first code contribution.
My name is Colin, I am and engineer. Although I initially got involved with OpenStack in the context of operations, I quickly was drawn into actually contributing code to the project. What I found is that many of the tools and workflows used to contribute to OpenStack are completely foreign to those (like me) with an operations focus.
In this session I will go over the biggest challenges that I faced as an engineer contributing. And review the tools and techniques to that I used to get past them. This information will be presented with the goal of arming engineers just getting involved with the knowledge tools necessary to get to their first successful contribution and beyond.
Learning objectives
1. The importance of community - Leveraging the power of the meeting
2. Talking your employeer into supporting OpenStack and the CLA
3. Setting up your dev environments - getting beyond Devstack
4. Getting git, using the git repository for those that don't code for a living
5. Testing your code - what do you mean it doesn't build?
6. How to give back, and get other people involved in the community.
1. Surviving your first check-in: An engineers guide
to contributing to OpenStack
Colin McNamara – Director, DC Practice Nexus IS
CCIE #18233
@COLINMCNAMARA
10/16//2012
1 www.Nexusis.com 877.286.3987
2. Agenda
How this all started – “a simple experiment”
The importance of community - Leveraging the power of the meetup
Talking your employer into supporting OpenStack and the CLA
Setting up your Dev environments - getting beyond Devstack
“Getting” git, using the git repository for those that don't code for a
living
Testing your code - what do you mean it doesn't build?
How to give back, and get other people involved in the community
2 www.Nexusis.com 877.286.3987
4. My Perspective
Network Engineer first
Systems/Storage Second
IEEE, IETF, T11
Linux user since 98
Creator of “Sausage Code”
NOT A PROGRAMMER
4 www.Nexusis.com 877.286.3987
8. Meetup.com – Community is your friend
Join a Meetup.com group
http://www.meetup.com/openst
ack/
If there is none in your area–
Start One
Many eyes help in
overcoming challenges
8 www.Nexusis.com 877.286.3987
9. Talking to your employer about contributing
10 www.Nexusis.com 877.286.3987
10. Talking to your employer about contributing
Notify your manager. If you don’t have a
policy you have a chance to set one.
In Ca, you are only protected if your
company isn’t in the line of biz your project
is.
If you are contributing on behalf of a
company, an authorized representative of
your company should also sign a Corporate
Contributor License Agreement.
11 www.Nexusis.com 877.286.3987
11. Next steps – Executing your CLA
Create your launchpad account
*** don’t change your username after ***
Join the OpenStack team on launchpad
Sign the CLA electronically
Update the Contributors Wiki
Request openstack-cla membership on
launchpad
Wait (or ping an op on #openstack-dev)
12 www.Nexusis.com 877.286.3987
12. Setting up your Dev environment
13 www.Nexusis.com 877.286.3987
13. 10 minutes to Devstack
Best run on Ubuntu 12.04
Log in as a USER (not root)
Sudo apt-get install git
git clone https://github.com/openstack-
dev/devstack.git
cd devstack && ./stack.sh
14 www.Nexusis.com 877.286.3987
14. Getting beyond Default Devstack
I like to run in a VMware environment
Spin up new instances easily
Quickly compare versions
Default install pushes QEMU
15 www.Nexusis.com 877.286.3987
16. Getting beyond Default Devstack - Stackrc
~/devstack/stackrc updated to point to working development
branch
Refs/changes/50/5050/1 is the review ID
17 www.Nexusis.com 877.286.3987
17. You’ve made a change, Now What?
./rejoin_stack.sh will attach you the screen with all the
terminals for the various apps. There could be as many as 14
screens depending on how many services are enabled
“ctrl-c” and “ctrl-d” on each window to kill the process. “ctrl-a
n” takes you to next terminal. Restart the process by using up-
arrow key and entering return
Another easier way to kill all and restart is to do “screen -ls”
and kill the process. Restart by ./rejoin_stack.sh
18 www.Nexusis.com 877.286.3987
19. What is Git ?
Repository created for Linux Kernel Dev
Solves centralization problems – you can
code at the lake, or in your isolated lab
Can be complex (multiple ways of doing
things)
20 www.Nexusis.com 877.286.3987
20. Setting things up – Installing Git
Install Git
Install DevStack
Configure git
Install git-review
Clone a project
Verify gerrit works
21 www.Nexusis.com 877.286.3987
21. Setting things up – Installing DevStack
Install Git
Install DevStack
Configure git
Install git-review
Clone a project
Verify gerrit works
22 www.Nexusis.com 877.286.3987
22. Setting things up – Configuring Git
Install Git
Install DevStack
Configure git
Install git-review
Clone a project
Verify gerrit works
23 www.Nexusis.com 877.286.3987
23. Setting things up – Configuring git-review
Install Git
Install DevStack Git review redirects a commit into a review and test
process
Configure git
Install git-review
Clone a project
Verify gerrit works
24 www.Nexusis.com 877.286.3987
24. Setting things up – Cloning a project
Install Git
Install DevStack
Configure git
Install git-review
Clone a project
Verify gerrit works
25 www.Nexusis.com 877.286.3987
25. Setting things up – Testing Gerrit
Install Git
Install DevStack
This error held us up for 2 weeks…
Configure git
Install git-review
Clone a project
Verify gerrit works
26 www.Nexusis.com 877.286.3987
26. Setting things up – Generate your public key
Install Git
Install DevStack
Configure git
Install git-review
Clone a project
Verify gerrit works
27 www.Nexusis.com 877.286.3987
27. Setting things up – Add your key to review.openstack.org
Install Git
Install DevStack
Configure git
Install git-review
Clone a project
Verify gerrit works
28 www.Nexusis.com 877.286.3987
28. Setting things up – Add your key to review.openstack.org
Install Git
Doesn’t Work -
Install DevStack
Configure git
Install git-review
Clone a project Works -
Verify gerrit works
29 www.Nexusis.com 877.286.3987
30. Pro Git – Well worth the price
I didn’t write it, but this
book is great
It is on Safari Books
Online
31 www.Nexusis.com 877.286.3987
31. Setting things up
Create a topic branch
Change code
Test Code
Commit Changes
Submit them for review
Monitor the review process
32 www.Nexusis.com 877.286.3987
32. Edited v1_1 api to describe phys as well as virt CPU
Create a topic branch
Change code
Test Code
Commit Changes
Submit them for review
Monitor the review process
33 www.Nexusis.com 877.286.3987
33. ./Run_tests.sh in each project
Create a topic branch
Change code
Test Code
Commit Changes
Submit them for review
Monitor the review process
34 www.Nexusis.com 877.286.3987
34. Commit your code
Create a topic branch
Change code
Test Code
Be verbose, and be sure to call out whether a feature is
Commit Changes blueprinted or a bugfix
Submit them for review
Monitor the review process
35 www.Nexusis.com 877.286.3987
35. Submit it for review!!
Create a topic branch
Change code
Test Code
Commit Changes
Submit them for review
Monitor the review process
36 www.Nexusis.com 877.286.3987
36. Track the reviews progress
Create a topic branch
Change code
Test Code
Commit Changes
Submit them for review
Monitor the review process
37 www.Nexusis.com 877.286.3987
37. Giving back Engaging the community
38 www.Nexusis.com 877.286.3987
38. Giving back
Start a meetup.com group in your area
Attend Sean Roberts session on building
community
Present to your peers
Share your experience with the world
39 www.Nexusis.com 877.286.3987
This PowerPoint Template includes a series of slide masters with predefined layouts and color schemes for formatting slides Slide Masters are displayed when you right click on a slide and select Layout from menu
Contributors License AgreementThere are some steps you need to go through before we can accept your contributions: If you are contributing on behalf of a company or organization, someone at your company or organization needs to sign the Corporate Contributor License Agreement providing a list of people authorized to commit code to OpenStack. Check also How to update the CCLA to provide changes to such list. A list of current companies and organizations with an existing Corporate CLA is available for your review. Employees of the the U.S. Government do not sign the Individual CLA. Instead, someone with authority to sign on behalf of your agency should sign the U.S. government Contributor License. Please contact us to initiate the process. Sign the CLA: Every developer needs to sign the Individual Contributor License agreement. Add yourself to the contributors wiki: On the Contributors page, include your Launchpad ID, your CLA Echosign Transaction Number and your Corporate Affiliation. The information provided will be used by authorized members to approve your request (see next step). Use your Launchpad ID as your username for the wiki. Request membership in the openstack-cla group on Launchpad: Visit https://launchpad.net/~openstack-cla/+join to join this group. Membership in this group is required in order to submit code changes.
Development environmentLaptop capable of virtualizationmake sure that the HOST_IP_IFACE points to wlan0 (if you have wireless access) or eth0 (if you are wired) in your localrcor better yet set it to “lo” interface for a single node installInstalling devstackInstall dev stackgit clone git://github.com/openstack-dev/devstack.gitRe-starting openstackQuick way to restart openstack./rejoin_stack.sh will attach you the screen with all the terminals for the various apps. There could be as many as 14 screens depending on how many services are enabled“ctrl-c” and “ctrl-d” on each window to kill the process. “ctrl-a n” takes you to next terminal. Restart the process by using up-arrow key and entering returnAnother easier way to kill all and restart is to do “screen -ls” and kill the process. Restart by ./rejoin_stack.shHorizon developmentcd /opt/stack/horizonrun ./run_tests.sh (this creates the virtualenv and also tests everything is okay)python manage.py runserver 0.0.0.0:8000 (horizon server)Structure of Horizon code/opt/stack/horizon has all the generic libraries/opt/stack/horizon/horizon/dashboards has all the dashboard specific stuff/opt/stack/horizon/openstac_dashboard is the sample Django projectSetting up the development environment/home/vinay/DiskQoS - github local repos (forked from the openstack repo)Create a topic branch “DiskQoS”. Make changes here. Dont put your changes into the master branch as it will run into merge conflicts when you pull from origin/masterCode, review and run unit testsCommit to your local topic branchSend for Gerritt reviewAdditional commits should be amendedModify localrc to override the repos and the branches from stackrc to point to your repos (DiskQoS)stackrc invokes localrc so any settings in localrc will overidestackrc settingsgood place to set your repos and branchesYou can always switch back to your devstack by commenting your repos in localrcAll my changes are at github.com/vbannaiYou will need to pull at a minimum nova, horizon and python-novaclient to get all the changesPython build and coding setupDownload the python goodies for emacs (python-mode.el, python-pep8.el)Setup up cscope and tags (you will need this to wade through code)install ctags-exburant for emacs tags (instead of etags) as ctags does not handle pythoninstall cscopefind all the python files in the projectfind . -name “.venv” -prune -o \\( -name “*.py” \\) > cscope.files(you want to skip virtual env directories or your cscope.out is goign to be huge and with duplicates)cscope -b (build the cross reference)Eclispe setup for python developmentInstall emacs+http://www.mulgasoft.com/emacsplus/update-siteSet key bindings in preferences to emacs modesetup pydevhttp://pydev.org/updatesDisk QoS Attribute to Flavor TypesGeneral Descriptionlibvirt has a new feature called blkiotune that specifies a weight to a VM. Based on the weight the Disk I/O controller schedules the blkio operations for the VM. This is one method of providing guaranteed disk io operations when multiple VM’s are running on the same physical host/hypervisorWeight is from 100 to 1000Design ApproachOn horizon add a new flavor type that allows us to specify an attirbute “Disk QoS”The flavors are stored in the nova db in a table “instance_types”. Recently another table has been added “instance_types_extra_specs”. The intent of this table is to store additional information about the flavors without having to modify the schema. The “Instance_type_extra_specs” table stores key/values pairs based on the flavor id. There can be as many key/value pairs for a flavor id.We will use a key/value pair of “disk_qos:[100 to 1000]” to store the disk_qos attribute for a given flavorThe feature should support addition of Disk_QoS attribute to new flavor types, edit existing flavor types to add this attribute and also delete a flavor type in the “instance_types” table along with cleaning up the entries in the “instance_type_extra_specs” table for the particular flavor id.Requires changes to the horizon default dashboard syspanels to add this supportHorizon changesAdd a new field in the create/edit flavor table with the caption “Extra Specs”The entry should be “key: value”. Example “disk_qos: 200”Multiple key/values can be specified in the entry. Example “disk_qos:200, rxtx: 2” etcThe key/value pair is case insensitiveMake changes in /opt/stack/horizon/horizon/dashboards/syspanel/flavors/forms.py /opt/stack/horizon/horizon/dashboards/syspanel/flavors/tables.py /opt/stack/horizon/horizon/api/nova.py ….. (more to come for the unit tests to pass)The horizon back-end needs to make two calls to add a new flavor type:one call to add the flavor in the “instance_type” nova db tableone call to add the key/value pair to the “instance_type_extra_specs” nova db tableAlso need changes in nova api to support the additional attribute in the http POSTNeed changes in schema for instance_type to support “disk_qos”We will use the “instance_type_extra_specs” to add the disk_qos key/value pair for the associated flavor id. This table allows us to store key/value attributes for flavor types without needing a schema change in nova dbbin/nova-managerun ./nova-manage flavor create -h to create a flavor on nova dbusiing cli….nova/api/...Need to make changes to python-novaclient (v1_1) to support additional attributes to flavor_createchanges …tbdTestingIdeally it would better to put the changes in a backward compatible way in novaThe make changes to python-novaclient in a backward compatible way (using default values for the disk_qos)Finally put the changes in horizonWill need three separate Gerritt review and unit testsDevelopment EnvironmentGithubThe github repos for the DiskQoS feature are at http://github.com/vbannaiGit setup on your pc for developmentClone from the github.com/openstackCreate a topic branchgit checkout -b DiskQoSDo your work on DiskQoS branch (not on the master)Git commit to your branchSubmit Gerritt ReviewDetails to come later…...
Development environmentLaptop capable of virtualizationmake sure that the HOST_IP_IFACE points to wlan0 (if you have wireless access) or eth0 (if you are wired) in your localrcor better yet set it to “lo” interface for a single node installInstalling devstackInstall dev stackgit clone git://github.com/openstack-dev/devstack.gitRe-starting openstackQuick way to restart openstack./rejoin_stack.sh will attach you the screen with all the terminals for the various apps. There could be as many as 14 screens depending on how many services are enabled“ctrl-c” and “ctrl-d” on each window to kill the process. “ctrl-a n” takes you to next terminal. Restart the process by using up-arrow key and entering returnAnother easier way to kill all and restart is to do “screen -ls” and kill the process. Restart by ./rejoin_stack.shHorizon developmentcd /opt/stack/horizonrun ./run_tests.sh (this creates the virtualenv and also tests everything is okay)python manage.py runserver 0.0.0.0:8000 (horizon server)Structure of Horizon code/opt/stack/horizon has all the generic libraries/opt/stack/horizon/horizon/dashboards has all the dashboard specific stuff/opt/stack/horizon/openstac_dashboard is the sample Django projectSetting up the development environment/home/vinay/DiskQoS - github local repos (forked from the openstack repo)Create a topic branch “DiskQoS”. Make changes here. Dont put your changes into the master branch as it will run into merge conflicts when you pull from origin/masterCode, review and run unit testsCommit to your local topic branchSend for Gerritt reviewAdditional commits should be amendedModify localrc to override the repos and the branches from stackrc to point to your repos (DiskQoS)stackrc invokes localrc so any settings in localrc will overidestackrc settingsgood place to set your repos and branchesYou can always switch back to your devstack by commenting your repos in localrcAll my changes are at github.com/vbannaiYou will need to pull at a minimum nova, horizon and python-novaclient to get all the changesPython build and coding setupDownload the python goodies for emacs (python-mode.el, python-pep8.el)Setup up cscope and tags (you will need this to wade through code)install ctags-exburant for emacs tags (instead of etags) as ctags does not handle pythoninstall cscopefind all the python files in the projectfind . -name “.venv” -prune -o \\( -name “*.py” \\) > cscope.files(you want to skip virtual env directories or your cscope.out is goign to be huge and with duplicates)cscope -b (build the cross reference)Eclispe setup for python developmentInstall emacs+http://www.mulgasoft.com/emacsplus/update-siteSet key bindings in preferences to emacs modesetup pydevhttp://pydev.org/updatesDisk QoS Attribute to Flavor TypesGeneral Descriptionlibvirt has a new feature called blkiotune that specifies a weight to a VM. Based on the weight the Disk I/O controller schedules the blkio operations for the VM. This is one method of providing guaranteed disk io operations when multiple VM’s are running on the same physical host/hypervisorWeight is from 100 to 1000Design ApproachOn horizon add a new flavor type that allows us to specify an attirbute “Disk QoS”The flavors are stored in the nova db in a table “instance_types”. Recently another table has been added “instance_types_extra_specs”. The intent of this table is to store additional information about the flavors without having to modify the schema. The “Instance_type_extra_specs” table stores key/values pairs based on the flavor id. There can be as many key/value pairs for a flavor id.We will use a key/value pair of “disk_qos:[100 to 1000]” to store the disk_qos attribute for a given flavorThe feature should support addition of Disk_QoS attribute to new flavor types, edit existing flavor types to add this attribute and also delete a flavor type in the “instance_types” table along with cleaning up the entries in the “instance_type_extra_specs” table for the particular flavor id.Requires changes to the horizon default dashboard syspanels to add this supportHorizon changesAdd a new field in the create/edit flavor table with the caption “Extra Specs”The entry should be “key: value”. Example “disk_qos: 200”Multiple key/values can be specified in the entry. Example “disk_qos:200, rxtx: 2” etcThe key/value pair is case insensitiveMake changes in /opt/stack/horizon/horizon/dashboards/syspanel/flavors/forms.py /opt/stack/horizon/horizon/dashboards/syspanel/flavors/tables.py /opt/stack/horizon/horizon/api/nova.py ….. (more to come for the unit tests to pass)The horizon back-end needs to make two calls to add a new flavor type:one call to add the flavor in the “instance_type” nova db tableone call to add the key/value pair to the “instance_type_extra_specs” nova db tableAlso need changes in nova api to support the additional attribute in the http POSTNeed changes in schema for instance_type to support “disk_qos”We will use the “instance_type_extra_specs” to add the disk_qos key/value pair for the associated flavor id. This table allows us to store key/value attributes for flavor types without needing a schema change in nova dbbin/nova-managerun ./nova-manage flavor create -h to create a flavor on nova dbusiing cli….nova/api/...Need to make changes to python-novaclient (v1_1) to support additional attributes to flavor_createchanges …tbdTestingIdeally it would better to put the changes in a backward compatible way in novaThe make changes to python-novaclient in a backward compatible way (using default values for the disk_qos)Finally put the changes in horizonWill need three separate Gerritt review and unit testsDevelopment EnvironmentGithubThe github repos for the DiskQoS feature are at http://github.com/vbannaiGit setup on your pc for developmentClone from the github.com/openstackCreate a topic branchgit checkout -b DiskQoSDo your work on DiskQoS branch (not on the master)Git commit to your branchSubmit Gerritt ReviewDetails to come later…...
Development environmentLaptop capable of virtualizationmake sure that the HOST_IP_IFACE points to wlan0 (if you have wireless access) or eth0 (if you are wired) in your localrcor better yet set it to “lo” interface for a single node installInstalling devstackInstall dev stackgit clone git://github.com/openstack-dev/devstack.gitRe-starting openstackQuick way to restart openstack./rejoin_stack.sh will attach you the screen with all the terminals for the various apps. There could be as many as 14 screens depending on how many services are enabled“ctrl-c” and “ctrl-d” on each window to kill the process. “ctrl-a n” takes you to next terminal. Restart the process by using up-arrow key and entering returnAnother easier way to kill all and restart is to do “screen -ls” and kill the process. Restart by ./rejoin_stack.shHorizon developmentcd /opt/stack/horizonrun ./run_tests.sh (this creates the virtualenv and also tests everything is okay)python manage.py runserver 0.0.0.0:8000 (horizon server)Structure of Horizon code/opt/stack/horizon has all the generic libraries/opt/stack/horizon/horizon/dashboards has all the dashboard specific stuff/opt/stack/horizon/openstac_dashboard is the sample Django projectSetting up the development environment/home/vinay/DiskQoS - github local repos (forked from the openstack repo)Create a topic branch “DiskQoS”. Make changes here. Dont put your changes into the master branch as it will run into merge conflicts when you pull from origin/masterCode, review and run unit testsCommit to your local topic branchSend for Gerritt reviewAdditional commits should be amendedModify localrc to override the repos and the branches from stackrc to point to your repos (DiskQoS)stackrc invokes localrc so any settings in localrc will overidestackrc settingsgood place to set your repos and branchesYou can always switch back to your devstack by commenting your repos in localrcAll my changes are at github.com/vbannaiYou will need to pull at a minimum nova, horizon and python-novaclient to get all the changesPython build and coding setupDownload the python goodies for emacs (python-mode.el, python-pep8.el)Setup up cscope and tags (you will need this to wade through code)install ctags-exburant for emacs tags (instead of etags) as ctags does not handle pythoninstall cscopefind all the python files in the projectfind . -name “.venv” -prune -o \\( -name “*.py” \\) > cscope.files(you want to skip virtual env directories or your cscope.out is goign to be huge and with duplicates)cscope -b (build the cross reference)Eclispe setup for python developmentInstall emacs+http://www.mulgasoft.com/emacsplus/update-siteSet key bindings in preferences to emacs modesetup pydevhttp://pydev.org/updatesDisk QoS Attribute to Flavor TypesGeneral Descriptionlibvirt has a new feature called blkiotune that specifies a weight to a VM. Based on the weight the Disk I/O controller schedules the blkio operations for the VM. This is one method of providing guaranteed disk io operations when multiple VM’s are running on the same physical host/hypervisorWeight is from 100 to 1000Design ApproachOn horizon add a new flavor type that allows us to specify an attirbute “Disk QoS”The flavors are stored in the nova db in a table “instance_types”. Recently another table has been added “instance_types_extra_specs”. The intent of this table is to store additional information about the flavors without having to modify the schema. The “Instance_type_extra_specs” table stores key/values pairs based on the flavor id. There can be as many key/value pairs for a flavor id.We will use a key/value pair of “disk_qos:[100 to 1000]” to store the disk_qos attribute for a given flavorThe feature should support addition of Disk_QoS attribute to new flavor types, edit existing flavor types to add this attribute and also delete a flavor type in the “instance_types” table along with cleaning up the entries in the “instance_type_extra_specs” table for the particular flavor id.Requires changes to the horizon default dashboard syspanels to add this supportHorizon changesAdd a new field in the create/edit flavor table with the caption “Extra Specs”The entry should be “key: value”. Example “disk_qos: 200”Multiple key/values can be specified in the entry. Example “disk_qos:200, rxtx: 2” etcThe key/value pair is case insensitiveMake changes in /opt/stack/horizon/horizon/dashboards/syspanel/flavors/forms.py /opt/stack/horizon/horizon/dashboards/syspanel/flavors/tables.py /opt/stack/horizon/horizon/api/nova.py ….. (more to come for the unit tests to pass)The horizon back-end needs to make two calls to add a new flavor type:one call to add the flavor in the “instance_type” nova db tableone call to add the key/value pair to the “instance_type_extra_specs” nova db tableAlso need changes in nova api to support the additional attribute in the http POSTNeed changes in schema for instance_type to support “disk_qos”We will use the “instance_type_extra_specs” to add the disk_qos key/value pair for the associated flavor id. This table allows us to store key/value attributes for flavor types without needing a schema change in nova dbbin/nova-managerun ./nova-manage flavor create -h to create a flavor on nova dbusiing cli….nova/api/...Need to make changes to python-novaclient (v1_1) to support additional attributes to flavor_createchanges …tbdTestingIdeally it would better to put the changes in a backward compatible way in novaThe make changes to python-novaclient in a backward compatible way (using default values for the disk_qos)Finally put the changes in horizonWill need three separate Gerritt review and unit testsDevelopment EnvironmentGithubThe github repos for the DiskQoS feature are at http://github.com/vbannaiGit setup on your pc for developmentClone from the github.com/openstackCreate a topic branchgit checkout -b DiskQoSDo your work on DiskQoS branch (not on the master)Git commit to your branchSubmit Gerritt ReviewDetails to come later…...
./rejoin_stack.sh will attach you the screen with all the terminals for the various apps. There could be as many as 14 screens depending on how many services are enabled“ctrl-c” and “ctrl-d” on each window to kill the process. “ctrl-a n” takes you to next terminal. Restart the process by using up-arrow key and entering returnAnother easier way to kill all and restart is to do “screen -ls” and kill the process. Restart by ./rejoin_stack.sh
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
If you follow the docs, you are probably going to get this –
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
Git is not better than Subversion. But is also not worse. It's different.The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.This looks good at first, but just keep in mind the added complexity to this approach.Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "gitinit" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.
This PowerPoint Template includes a series of slide masters with predefined layouts and color schemes for formatting slides Slide Masters are displayed when you right click on a slide and select Layout from menu