-
Notifications
You must be signed in to change notification settings - Fork 196
HowToDevelop
| « back to DeveloperGuide |
|---|
The document below is outdated. GettingStarted should cover most of the stuff.
We use Mercurial (hg) for revision control. If you're new to Mercurial, try the tutorial at http://hginit.com/. Mercurial is a distributed RCS, which means that your local machine gets a complete copy of the repository with all its history, and you can commit changes locally before pushing them to the main repository.
Note: If you are working from a specific release branch (instead of the default branch), follow the instructions in green and replace "releasebranch" with the release branch name.
Before you start making a new set of changes:
| hg pull -u or hg pull; hg update releasename | # Brings your local repository up to date | |
| hg branch username-feature | # Makes a new branch for your changes |
Your branch name should consist of your username, a hyphen, and a short identifier that describes your change.
Now you can write code, edit, test, etc. If you are adding or removing files, use hg add or hg rm. If you are moving content from one file to another, use hg cp or hg mv. The hg status command will show which files you have modified.
There are two kinds of tests. When you make a significant change, please add tests for it (see HowToTest for details).
Run the unit tests with this command:
| tools/unit_tests | # Takes about 3 seconds |
Run the system tests with this command:
| tools/server_tests | # Starts the app server on port 8081 and makes requests to it | |
| # Takes about 3 minutes |
You can also run all the tests with tools/all_tests.
You can first look at your changes:
| hg status | # Lists all files modified, created, removed. | |
| hg diff | # Display diffs on all modified files. |
Other changes can continue to happen on the default branch while you are working. So, you'll need to merge in these changes before you do the final round of testing. To merge in these changes:
| hg commit | # Commits your pending changes locally. | |
| hg pull | # Pulls down any new changes from the main repository to your local repository | |
| hg merge default or hg merge releasename | # Merges changes from the default (or release) branch into your branch | |
| hg commit | # Commits the merge locally on your branch |
hg commit will bring up an editor for you to enter a commit message. If you don't enter a commit message, the commit will be cancelled.
The merge command operates on two committed changesets (which is why you have to commit your local changes first) and produces a new changeset (which you then have the opportunity to inspect before committing).
If you have changed or added messages in the UI, hg merge may ask you to resolve conflicts between all the 90+ message files. To solve this problem:
- First back out your incomplete merge with hg update -C username-feature, and remove any stray files from the incomplete merge
-
for i in app/locale/*/*/django*; do hg cat -r releasename $i > $i; done# Copy all the message files from release-branch into your branch - If you added translations in other languages,
hg revertthose .po files with your new translations.
-
hg commit -m "Merge with messages from releasename" hg merge releasename
After merging, rerun your tests to make sure merge was fine.
When you have code that is tested and works, request a code review by running the rietveld script like this:
| tools/rietveld reviewer_list optional_cc_list | |
| tools/rietveld-releasename reviewer_list optional_cc_list |
(reviewer_list and optional_cc_list are lists of e-mail addresses separated by commas.)
At some point, it will ask for a user and password, just leave them both empty and it will go through.
Note: If you are asked to enter "Password for --send_mail", make sure there is a .email file in your home directory with the account you used to sign into code.google.com.
This will produce a diff from the default branch to your branch and upload it to Rietveld, an open-source review tool. The reviewer or reviewers will receive e-mail from you directing them to a page where they can browse your changes and make comments, and everyone can send comments back and forth.
If your reviewer asks you to make some changes, you can do those changes locally, run the tests again, and then run rietveld again. This will update the existing code review with a new patch.
You can have multiple branches in progress in your local repository, if you need to, and switch among them with hg update. Each time you run rietveld, it will detect the branch you are working in, and will either create a new code review or update the existing code review.
When your reviewer approves the changes, then you need to send your change to the reviewer which will incorporate it in the default branch.
If you do NOT have developer permission for this project, create a bundle of your changes like this:
| hg outgoing | # shows changeset which are not in default branch | |
| hg bundle -r your_branch_name --base default your_filename.hg | # creates a compressed changegroup file with these changesets | |
| hg bundle -r your_branch_name --base releasename your_filename.hg | # creates a compressed changegroup file with these changesets |
Then e-mail your_filename.hg to your code reviewer, who will incorporate your changes into the default branch.
Then you can update and return to the default/release branch like this:
| hg update default or hg update releasename | # Switches back to the default/release branch | |
| hg pull -u | # Pulls down updates from the main repository |
If you do have developer permission for this project, use hg push -f to push your branch into the main repository. Your reviewer will then merge the change into the default branch.
| « back to DeveloperGuide |
|---|