Open stack summit surviving your first checkin
•Télécharger en tant que PPTX, PDF•
1 j'aime•2,382 vues
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.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Open stack summit surviving your first checkin
Similaire à Open stack summit surviving your first checkin (20)
Plus de Colin McNamara
Open stack summit surviving your first checkin
- 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
- 3. My Background 3 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
- 5. How this craziness started 5 www.Nexusis.com 877.286.3987
- 6. “A simple experiment” Ewan Mellor – Citrix Xen Simple feature, Deploy Storage QOS Turned into a 4 month saga Lots of lessons to be learned 6 www.Nexusis.com 877.286.3987
- 7. Leveraging the power of the Meetup 7 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
- 15. Getting beyond Default Devstack - Stackrc /devstack/stack rc Adjust API’s / Services Change git repos 16 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
- 18. “Getting Git” OpenStack Workflows 19 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
- 29. Making, Testing and submitting changes 30 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
- 39. @colinmcnamara www.colinmcnamara.com / www.nexusis.com 40 www.Nexusis.com 877.286.3987
Notes de l'éditeur
- 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