this has largely been made redundant due to:
* our general distaste for merging
* the fact that jenny jenkins does the lion's share of our deploys.
Once your work has matured to a point where you're happy with it and it's been code-reviewed, you'll want to push it from your working branch to the Stable branch.
In general you shouldn't be freaked out about pushing to stable (we can always backout problematic changesets) but you should try to make sure that everything is in fine working order before you do. This page is all about common hiccups that arise when merging your work into stable and the subsequent push.
<project_root>/.hg/hgrc file, i have the following paths set so that i can pull from stable often:
default = https://khanacademy.kilnhg.com/Repo/Website/Group/marcos
stable = https://khanacademy.kilnhg.com/Repo/Website/Group/stable
The Overall Workflow
The full details, with commands to run, are below. But the general pattern you're going to be following is:
- commit any changes you've made
- merge from stable
If you're feeling paranoid, checkout master in khan-exercises and pull in/resolve any new changes/conflicts.
- resolve conflicts (if any)
make sure that
- (this is only necessary if you're working in both hg and git and if, luckily, your changes in git don't adversely impact anything in hg or vice versa. otherwise, you'll want to merge your git branch with master. Also, it doesn't matter if you get this part right unless you're in the habit of deploying from your branch instead of stable. Cowboy.)
.hgsubstate matches up with the current hash of khan-exercises's tip.commit the merge from stable
push to your repositorytest to see if it's working, poke it
if everything looks good, push your local working copy to stable!have a cookie
- If you are making a large change, it's likely a good idea that you deploy the code first, and test it on production. Most changes do not require this step, but if this is your first time pushing to stable, it may be good practice to try it. See instructions on deploying for how to do this.
hg commit to commit your changes to your local branch.
Merge but don't commit the merge yet
If you're unsure (or are worried about a hairy merge), you can always
hg incoming stable first and see if any of the changesets seem to encroach on your position. If you're otherwise ok with the idea of pulling from stable:
$ cd <your branch>
$ hg pull stable # this will pull changes and likely create a new head
$ hg merge
Resolve any conflicts
If you have any conflicts, it's worthwhile making sure that you keep track of what they are and who else might be working on something you are. Otherwise, get cozy with your merge/conflict tool.
(Optional) Check out master in khan-exercises
If you are deploying from your branch -- which you shouldn't do -- you will need to make sure your branch's copy of khan-exercises is up to date. Even if you're not being a cowboy, you might want to do this out of a healthy sense of paranoia.
git checkout master
Resolve and checkin .hgsubstate
If the head of master has changed recently, you may be responsible for updating the
git show-ref HEAD | diff -u - ../.hgsubstate
The label name (second word) might differ, but the hashes (first word) should be the same. If not, then you need to update
.hgsubstate to use the hash from
sed -i -e 's/^[^ ]*/'`git show-ref HEAD | cut -d" " -f1`/ ../.hgsubstate
Commit the merge
$ hg commit # -m "merge from stable"
Typically people just put "merge from stable" as the commit message unless there's a complicated resolve that had to be done.
Push to your branch repository
Assuming the merge from stable was trivial, this doesn't need to be reviewed. (If you had a non-trivial merge, you'll want to specify a reviewer here. Hopefully you put a contentful commit message in when you committed the merge, describing the complexity of the merge!)
hg push --rr none default
Run the tests
allcheck from the root directory to make sure all the tests still pass. (You can also run
make check, which is faster but not as complete.) If not, you should fix either the code or the test before pushing to stable.
Clone/update your branch repository
This is really part of the deploy stage right now, so i'll gloss over it, but you want to make sure that a clean checkout does the right thing.
Deploy your working copy
The reason for this is to verify the appengine app is still working, even with your changes, before you push to stable. If they are, then you're good to go, but oftentimes there'll be something weird, so this is a nice safety thing.
When doing this, i don't specify a version, i just use
python deploy/deploy.py and let it do its thing, if it's a good change, i've killed two birds with one stone because now i can just switch my recent deploy to default, otherwise, i can nuke it and try again.
Push to stable
Assuming nobody's beat you to it, push! Once you do, your changeset is live and it's also now in stable. Assuming your merges above were trivial, this doesn't need to be reviewed, since it was already reviewed when you pushed the changes into your branch.
hg push --rr none stable
One thing that can go wrong here, is someone else may have pushed to stable since you merged a few steps ago. If so, mercurial will complain here. The solution is to go back to step 2 and re-merge from stable. (Don't
just push anyway!)