Page History

...

1. Create and switch to a new branch. A branch is a divergence point from the existing code base. Any changes made in a branch are restricted to the branch.

   Code Block
   language text
   $ cd $ONOS_ROOT $ git checkout -b myBranch Switched to a new branch 'myBranch'

   This creates a new branch named 'myBranch', off of the previous branch that we were in. Replace 'myBranch' with a name that briefly describes the topic of your change. This command will fail if there was already a branch of the same name. The command git branch can be used to list all of the branches to check that the name isn't already used. If a branch with the desired name is no longer needed, it may be deleted with git branch -D <branchName> and the above commands repeated to re-create a new branch. 

   
   

2. Make changes to the code. This can be done in any way - IDE, text editor, whatnot.
   
   
3. Test the changes. Any changes should be accompanied by unit tests wherever possible and must pass existing unit tests. The project should also be rebuilt and tested against a Mininet network (at the very least). 
   
   
   • The command mvn test will ob will run all of the unit tests.The utility onos-start-network can be used to launch a Mininet topology that will attempt to connect to the ONOS instances at each VM designated by the OC variables.
   
   
4. Commit the changes. Committing creates a snapshot of the changes made to the code so that may be revisited/manipulated later, but only in the branch where the changes were committed. The command git status allows one to view the files that were modified. 
   git add <file> adds a file to the pool to commit. Once all files are added, git commit -m "<message>" creates a snapshot with <message> as its description. git log may be used to list all of the commits that have been made, with the most recent commit at top.
   
   

5. Pull upstream changes. The repository on the development machine should be synchronized with the upstream ONOS source repository. 

   Upstream changes are always applied to the master branch. We first switch back to master with git checkout, before pulling downloading the changes in the upstream source repository with git pull:

   Code Block
   language text
   $ git checkout master Switched to branch 'master' $ git pull --ff-only origin master

6. Sync the branch with updated master. The updates pulled to master must be explicitly applied to the branch intended for code review. This is done by switching back to the development branch and using git rebase.

   Code Block
   language text
   $ git checkout myBranch Switched to branch 'myBranch' $ git rebase -i master

   The default editor will be opened with the list of commits that have been made to the branch locally since its creation. Saving and closing this file causes the changes from the master branch to be incorporated into the branch. Any merge conflicts (e.g. a file modified in both the local and master branch) will interrupt the process. In git status, the conflicting files will appear under "Unmerged paths" as "both modified". If this happens, the file(s) must be edited and committed before the rebase is continued:

   Code Block
   language text
   $ git rebase -i master error: could not apply ca081b6... Initial commit for information persistence. $ vim core/net/src/main/java/org/onlab/onos/net/device/impl/DeviceManager.java $ git add core/net/src/main/java/org/onlab/onos/net/device/impl/DeviceManager.java $ git rebase --continue Successfully rebased and updated refs/heads/myBranch.

7. Submit code for review. Once the branch is synchronized, it may be submitted for review with git review. (usage examples)
   

   Code Block
   $ git review

   This submits the changes with the branch name as its topic.

   Info
   title Commit and submit this branch only once
   If you would like to change your code after submission, please follow the procedure as described in the "Amending Submissions" section below.

   Tip
   title git review fails with Traceback
   If you're using a Mac and git review command fails with an error traceback like below: Expand title Error Traceback Traceback (most recent call last):   File "/usr/local/bin/git-review", line 11, in <module>     sys.exit(main())   File "/Library/Python/2.7/site-packages/git_review/cmd.py", line 1132, in main     (os.path.split(sys.argv[0])[-1], get_version()))   File "/Library/Python/2.7/site-packages/git_review/cmd.py", line 180, in get_version     provider = pkg_resources.get_provider(requirement)   File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 197, in get_provider     return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]   File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 666, in require     needed = self.resolve(parse_requirements(requirements))   File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 565, in resolve     raise DistributionNotFound(req)  # XXX put more info here pkg_resources.DistributionNotFound: git-review try upgrading the git-review package dependency first. $ sudo pip install --upgrade setuptools

...