branching from a 1.14 branch creates a wt4 tree, therefore content filtering doesn't work
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Bazaar |
Confirmed
|
Medium
|
Unassigned | ||
Bug Description
Hi
I'm working on the Xibo project which is hosted in Launchpad (https:/
The development work is done cross-platform so we're constantly having problems with line endings, both when building release files and when looking at diffs.
We want to upgrade all the development team to using the 1.14 format so that we can use the line endings conversion tool. I've written up a rules file and put it in my .bazaar folder. You can see a copy I've checked in to the repo here for the other devs to use:
http://
Next I branched lp:xibo/1.0, fixed up all the line endings so that the use Unix style, and committed the changes. I then did bzr upgrade --1.14 to pull the branch up to working format 5 as per the documentation. I then pushed that up to lp:~alexharrington/xibo/line-end-test
If I now branch that on a Windows PC using 1.17 with the same rules file in %APPDATA%
What sequence of events do I need to go through to convert lp:xibo/1.0 to the new format, so that the developers branching that will use the new format, and hence loose the line endings issues we've had till now?
Cheers
Alex
| Martin Pool (mbp) wrote | #1 |
| Changed in bzr: | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
| John A Meinel (jameinel) wrote Re: [Bug 414305] Re: branching from a 1.14 branch creates a wt4 tree, therefore content filtering doesn't work | #2 |
| Martin Pool (mbp) wrote | #3 |
| tags: | added: content-filtering format-infrastructure formats |
| tags: | added: check-for-breezy |
I haven't gone through the reproduction steps but I think what's happening is that, because there's no wt in the source, we create the default format (or the default for this bzrdir) in the destination therefore it doesn't work.
One unattractive workaround is to upgrade the working tree after getting it.
It would probably also work to upgrade the hosted branch to 2a; this requires everyone be using 1.17 or preferable 1.18rc1.
I think there's still some kind of general bug here in how we choose the format; it should probably be determined by the branch and repo.