Your SlideShare is downloading. ×
OpenStack-Summit-Surviving-Your-First-Checkin.pptx
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

OpenStack-Summit-Surviving-Your-First-Checkin.pptx

341
views

Published on

true

true


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
341
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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
  • Transcript

    • 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//20121 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 dont code for a living  Testing your code - what do you mean it doesnt build?  How to give back, and get other people involved in the community2 www.Nexusis.com 877.286.3987
    • 3. My Background3 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 PROGRAMMER4 www.Nexusis.com 877.286.3987
    • 5. How this craziness started5 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 learned6 www.Nexusis.com 877.286.3987
    • 7. Leveraging the power of the Meetup7 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 challenges8 www.Nexusis.com 877.286.3987
    • 9. Talking to your employer about contributing10 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 environment13 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.sh14 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 QEMU15 www.Nexusis.com 877.286.3987
    • 15. Getting beyond Default Devstack - Stackrc  /devstack/stack rc  Adjust API’s / Services  Change git repos16 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 ID17 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.sh18 www.Nexusis.com 877.286.3987
    • 18. “Getting Git” OpenStack Workflows19 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 GitInstall GitInstall DevStackConfigure gitInstall git-reviewClone a projectVerify gerrit works21 www.Nexusis.com 877.286.3987
    • 21. Setting things up – Installing DevStackInstall GitInstall DevStackConfigure gitInstall git-reviewClone a projectVerify gerrit works22 www.Nexusis.com 877.286.3987
    • 22. Setting things up – Configuring GitInstall GitInstall DevStackConfigure gitInstall git-reviewClone a projectVerify gerrit works23 www.Nexusis.com 877.286.3987
    • 23. Setting things up – Configuring git-reviewInstall GitInstall DevStack Git review redirects a commit into a review and test processConfigure gitInstall git-reviewClone a projectVerify gerrit works24 www.Nexusis.com 877.286.3987
    • 24. Setting things up – Cloning a projectInstall GitInstall DevStackConfigure gitInstall git-reviewClone a projectVerify gerrit works25 www.Nexusis.com 877.286.3987
    • 25. Setting things up – Testing GerritInstall GitInstall DevStack This error held us up for 2 weeks…Configure gitInstall git-reviewClone a projectVerify gerrit works26 www.Nexusis.com 877.286.3987
    • 26. Setting things up – Generate your public keyInstall GitInstall DevStackConfigure gitInstall git-reviewClone a projectVerify gerrit works27 www.Nexusis.com 877.286.3987
    • 27. Setting things up – Add your key to review.openstack.orgInstall GitInstall DevStackConfigure gitInstall git-reviewClone a projectVerify gerrit works28 www.Nexusis.com 877.286.3987
    • 28. Setting things up – Add your key to review.openstack.orgInstall Git Doesn’t Work -Install DevStackConfigure gitInstall git-reviewClone a project Works -Verify gerrit works29 www.Nexusis.com 877.286.3987
    • 29. Making, Testing and submitting changes30 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 Online31 www.Nexusis.com 877.286.3987
    • 31. Setting things upCreate a topic branchChange codeTest CodeCommit ChangesSubmit them for reviewMonitor the review process32 www.Nexusis.com 877.286.3987
    • 32. Edited v1_1 api to describe phys as well as virt CPUCreate a topic branchChange codeTest CodeCommit ChangesSubmit them for reviewMonitor the review process33 www.Nexusis.com 877.286.3987
    • 33. ./Run_tests.sh in each projectCreate a topic branchChange codeTest CodeCommit ChangesSubmit them for reviewMonitor the review process34 www.Nexusis.com 877.286.3987
    • 34. Commit your codeCreate a topic branchChange codeTest Code Be verbose, and be sure to call out whether a feature isCommit Changes blueprinted or a bugfixSubmit them for reviewMonitor the review process35 www.Nexusis.com 877.286.3987
    • 35. Submit it for review!!Create a topic branchChange codeTest CodeCommit ChangesSubmit them for reviewMonitor the review process36 www.Nexusis.com 877.286.3987
    • 36. Track the reviews progressCreate a topic branchChange codeTest CodeCommit ChangesSubmit them for reviewMonitor the review process37 www.Nexusis.com 877.286.3987
    • 37. Giving back Engaging the community38 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 world39 www.Nexusis.com 877.286.3987
    • 39. @colinmcnamara www.colinmcnamara.com / www.nexusis.com40 www.Nexusis.com 877.286.3987

    ×