Merge lp:~jtv/launchpad/bug-439248 into lp:launchpad
Proposed by
Jeroen T. Vermeulen
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Eleanor Berger | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | not available | ||||
Proposed branch: | lp:~jtv/launchpad/bug-439248 | ||||
Merge into: | lp:launchpad | ||||
Diff against target: |
126 lines 3 files modified
lib/lp/code/tests/test_directbranchcommit.py (+1/-2) lib/lp/translations/scripts/tests/test_translations_to_branch.py (+44/-0) lib/lp/translations/scripts/translations_to_branch.py (+34/-1) |
||||
To merge this branch: | bzr merge lp:~jtv/launchpad/bug-439248 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Eleanor Berger (community) | Approve | ||
Review via email: mp+12781@code.launchpad.net |
To post a comment you must log in.
= Bug 439248 =
The plot so far:
The translations- to-branch script produces daily snapshots of a product
series' translations and commits them to a selected bzr branch.
It does this using the DirectBranchCommit. This helper class uses a
"shortcut" similar to a lightweight checkout to write files straight to
a bzr branch without having to pull down its full history first.
Branches in Launchpad are now stacked by deafult
The bzr folks have found that committing directly to a stacked branch
failed to preserve invariants. This is bzr bug 375013. Their interim
solution was to prohibit commits straight to stacked branches.
Et voilĂ : now some translations- to-branch exports are failing because
bzrlib refuses to commit (there is a helpful reference to bug 375013).
This branch works around that by unstacking the branch when needed.
Thanks are due to Robert Collins for proffering this solution.
Semantically it changes nothing for the user; the branch is just stored
in a less efficient way, which is mostly our own problem. The advantage
of this approach is that it's a one-time step per branch. I've already
contacted some users suggesting the command-line equivalent of this fix,
and some of them already seem to have fixed their exports in this way.
== Design considerations ==
I considered and rejected two alternatives in favour of this one:
* Reverting to a more conventional way of writing to the branch. This mit's simple API.
means having two alternative code paths for doing the same job, and
trying to hide the complexity behind DirectBranchCom
It also means letting a limitation of exports scalability exist and
grow unchecked.
* Requiring users to convert their own branches manually. I don't
think that would be acceptable; it's bad enough that "registering a
branch" is not enough to create one. That means there already is a
highly technical step to setting up a translations branch. We're not
in the business of selling expensive consultancy services for this
sort of chore.
Another design choice was whether to apply the fix in DirectBranchCommit
or in the export script that uses DirectBranchCommit. Here I opted for
keeping the workaround in the export script; making a helper class too
intelligent can lead to surprises for people who work intimately with
branches and have detailed expectations. Unstacking a branch may come
as a surprise there. A chat with Aaron Bentley validated this choice.
== Implementation ==
The export-to-branch script class has a factory method to facilitate chCommit. I added a shim _prepareBranchC ommit
testing: _makeDirectBran
between that and the calling code, that checks whether the branch it's
looking at is stacked. If so, it drops the committer it created,
converts the branch to unstacked, and creates a new committer.
Why does it create up to two committers? Because the first will open
the underlying bzr branch, which otherwise we'd have to do once extra to
check for stacking. This way is shorter and more efficient for the
common case.
== Tests == to.branch
{{{
./bin/test -vv -t directbranchcommit -t translations.
}}}
== Demo and Q/A ==
Pick a productseries with trans...