Backporting

From HalyardWiki

We're backporting a bunch of features and bugfixes to 0.2.x for use with one of our internal projects. Most users of Halyard will be able to ignore this.

Contents 1 Backport progress 2 Getting a copy of old_tamale_test 3 Creating a backport branch 4 Patches to merge 5 Bulk merging

[edit] Backport progress

You can see what's already been backported using gitweb. Note that this branch is not visible in the default gitweb view.

[edit] Getting a copy of old_tamale_test

This currently lives in programs/old_tamale_test/branches/0.2-stable in our private Subversion tree. We could publicly release this if (a) anybody actually wanted it and (b) we were prepared to dedicate a fair amount of time to cleaning it up.

Currently, this script has a lot of problems. We'll need to troubleshoot some of them soon.

[edit] Creating a backport branch

First, make sure your working tree is clean, with no uncommitted changes:

git status

Next, see Git and make sure you have all fetched all the old branches from the repository.

Then, create a new working branch. Please use the branch name specified below; it will be easier if we standardize.

git branch backport-0.2 v0.2-stable
git checkout -f backport-0.2

[edit] Patches to merge

The following patches will need to be rewritten from scratch:

r28611 First attempt to fix slow-loading bug
r28728 Trusting precompiled *.zo files
  r28739 Fix progress bar when loading *.zo files

This pair will make Halyard 0.2.x stop hogging 100% of the CPU, but it will also break the TIMEOUT API used by an unknown amount of code:

r28551 Reimplement NAP, remove TIMEOUT
r28564 Don't use 100% of the CPU

Also needed:

1. A bare-bones rename patch.
2. Updates to copyright dates and file headers.
3. Minor editor fixes?

In a special, experimental version, we want to include several API changes:

r28551 Reimplement NAP, remove TIMEOUT
r28552 RUN-DEFERRED, part 1
r28553 RUN-DEFERRED, part 2

[edit] Bulk merging

Create a temporary merging branch:

git checkout -b backport-merge 

The basic theory of cherry-picking a bugfix:

git cherry-pick -x --edit `git svn find-rev r28551 trunk`

But in practice, we automate things quite heavily:

tools/backport r28551 r28552
# Oops, some conflicts, including Release-Notes.txt.
tools/backport ignore-release-notes
# Fix other merge problems using standard git tools.
tools/backport resume

Please use tools/backport--it protects you against commit logs containing bogus git-svn values, and it does a variety of other important formatting, including placing Bug ID values in the correct place (at the very end of the log message).