[00:08] Hello there. Any information about 1.13 packages for osx coming soon? [00:11] yacoob_: the mac folk are pretty responsive, so I'd expect something within a day or two [00:12] hit #335528: [00:12] This report is public [00:13] erp. [00:13] hit bug#335528, looked for any other version out there available. [00:13] bug 335528 [00:13] Launchpad bug 335528 in bzr "bzr status: TypeError: run() got an unexpected keyword argument 'verbose' (dup-of: 334202)" [Undecided,New] https://launchpad.net/bugs/335528 [00:13] Launchpad bug 334202 in bzr "internal error occured on bzr status" [Undecided,Fix released] https://launchpad.net/bugs/334202 [00:13] yacoob_: upgrade your loom package [00:13] yacoob_: you can also run 'bzr --builtin status' or 'bzr --no-plugins status' [00:14] ha, let's see. [00:17] bzr shelve rocks! [00:18] btw, I must be tired, I haven't noticed the 'dup-of' line describing the problem in detail... :) [00:55] hehe. Good thing: bzr gives you many possible models of development, to pick one that suit your needs. Bad thing: bzr gives you many possible models of development, and you need to worry which one to choose, if you don't have that much experience in the area... :) [01:15] At least it's easy to switch models. [01:17] True... I think. :) [01:18] for the moment I'm playing with a small pet projec, that only I work on... but I don't like that much idea of keeping my source in just working dir [01:19] so I've just pushed whole branch to external drive... and now if something happens to my copy, I'll just pull from there [01:22] hm, assuming I'm working with a centralized model and do some local commits - would later commit push everything as a single change, or will I have whole history pushed together? [01:35] yacoob: it has all the history [01:50] any way to "crunch" it down to single change? [01:52] yes - its in the user guide. May I ask why though? [01:52] no real reason, just looking at the possibilities [01:53] ok [01:53] so our log shows it crunched down [01:53] even while the full detail is preserved under the covers [01:58] I wonder how painful a checkout is, when the history is large... assuming we do want the history [02:26] jml: so, we can do push of a revision in 18 seconds now [02:26] jml: which makes 11seconds a rather large fraction :P [02:27] It takes 18 seconds to push 1 revision? What are we talking about? [02:27] Peng_: its not 36 for two, if thats concerning you :P [02:27] lifeless: I was looking at our data on this today [02:27] Peng_: 'bzr push' in an existing branch with one new commit on it [02:27] Peng_: via bzr+ssh [02:28] Peng_: pushing 1 new revision to an existing branch in a shared repo via bzr+ssh, including SSH handshake, from Sydney->London. [02:28] 18s, but also 18 HPSS calls, co-incidentally. [02:28] Oh, from Sydney to London. [02:29] Yeah, that part is rather key :) [02:29] spiv: 18s includes ssh set up time? [02:30] Also, there are actually two SSH handshakes there, it was a push to people.ubuntu.com. [02:30] mwhudson: yes. [02:30] spiv: oh good :) [02:30] mwhudson: if launchpad had 1.13 I'd use it ;) [02:31] spiv: bazaar.staging.launchpad.net will soon enough [02:31] staging can be really slow for other reasons though [02:31] mwhudson: that would be lovely. [02:48] * fullermd frowns. [02:48] Is this redirect of distfiles to launchpadlibrarian new? [02:49] fullermd: I don't think so; its to prevent XSS [02:49] is there a builtin command that does 1 hpss call? [02:49] jam has one in a plugin I think [02:49] 1 r/o call preferably [02:50] Hm. [02:50] https://code.edge.launchpad.net/~bzr/bzr-hello/trunk [02:50] lifeless: thanks [02:50] It's breaking the port download, which explicitly doesn't follow redirects :| [02:50] Never did that before, even earlier this week. [02:50] oh. have ports changed then ? ::P [02:51] whomp! [02:52] ? [02:52] I don't think so... I'm checking as fast as I can swallow the bile from running cvs ann... [02:52] lifeless: bzr hello stacktraces [02:52] ouch [02:52] I have one too, https://launchpad.net/bzr-ping :P [02:53] Not in a couple years at least... the line setting that arg hasn't been touched since 07. [02:53] jml: and mine doesn't backtrace ;) [02:53] And it worked earlier this week when I tested the RC. [02:53] AFAIK there hasn't been a rollout this week [02:53] spm: ^ [02:54] fullermd: given today is monday and all [02:54] spiv: thanks. [02:54] Are the librarian links stable (or stable enough 'till the next release) [02:54] It was probably Wed or Thur when I did it... [02:54] mtimes say Thurs. [02:54] jml: FWIW I just got 6.477s to bzr ping bzr+ssh://bazaar.launchpad.net/ [02:55] spiv: that's roughly what I get. [02:55] (5.6, 5.8, 6.2) [02:55] jml: how long do you get for 'bzr ping lp:bzr' [02:55] fullermd: which librarian links? [02:55] using the lp: url takes it up to 7.6, 7.8, 8.0 [02:56] * igc lunch [02:56] The 302 to launchpadlibrarian.net for the release tarball. [02:56] Which 302? [02:56] (I think I'm missing some context) [02:57] lifeless: so, uhh, I guess that means that launchpad page loads are expensive :P [02:57] fullermd: what url are you giving ports today [02:57] jml: but but but these are not full pages, they are ajaxy, they must be faster right? [02:57] oh damn, there goes my sarcastic side again. Meep [02:58] http://pastebin.ca/1361926 [02:58] (does the same with code.launchpad, which is what bzrtools is using; it's failing now too) [02:58] fullermd: ah, on Launchpad, as opposed to bazaar-vcs.org or something [02:58] * jml files a bug on bzr-ping [02:58] Well, last I heard release tarballs weren't going on b-v.o anymore anyway :) [02:59] oh, it doesn't use lp as its bug tracker [02:59] * jml uses IRC instead [02:59] spiv: ping should also be able to send N hpss requests [02:59] jml: thats just a bad default, assume it uses it [03:00] lifeless: we did have a rollout to crowberry on friday. Was a CP for jml/mwh's bzr connections fix. Is possibly related? [03:00] spm: what else was included though? the main app is at issue, not code hosting per se [03:00] hi all [03:00] fullermd: AFAIK /bzr/1.13/1.13/+download/bzr-1.13.tar.gz should be a stable URL. Also, the target of that redirect should exist for as long as the Launchpad web UI offers bzr-1.13.tar.gz for download. [03:01] fullermd: does that tell you what you want to know? [03:01] jml: ping 'fixed' to use lp [03:01] I guess... I'll just have to resolve it manually and use the librarian links. [03:01] Port fetch explicitly disables redirect-following. [03:02] fullermd: how does port fetch handle sf? [03:02] It would be nice if Launchpad served that data to you directly rather than giving a redirect. [03:03] It just lists the mirror explicitly. [03:04] * fullermd grabs a random example. [03:04] fullermd: can you just turn it on for this, I mean, sha1 isn't trivially broken [yet] [03:04] Not really, no. [03:04] Then using the librarian URL directly seems about the same. [03:04] I mean, I probably COULD override the fetch args in the port Makefile, but that's REALLY unfriendly to the layering. [03:05] But ideally I think port fetch would rely on the checksum rather than lack of HTTP redirect... [03:05] fullermd: args = echo $args | sed -e .... === pasc_ is now known as pasc [03:05] :P :] :> [03:05] Too late, due to make's makeage :p [03:06] It does use a checksum to verify the file after download. The comments suggest one reason redirects are flat disabled is because of sides that use a 302 to implement their 404's. [03:06] fullermd: ugh, breaking a standard to deal with broken sites [03:06] FAIL [03:07] turn it on, sites with 404 as 302 will get a sha fail, everyone wins [03:07] That's slightly above my paygrade :p [03:07] [I appreciate its not trivial to do this, but really. HTTP Nazi hat on now] [03:09] Ah, there's where it started. 1.306, 1999-03-08. [03:09] Now I can avoid touching cvs ann for another 5 years, hopefully... [03:20] I have today discovered that in Red Hat land they use the term "re-base" to mean upgrading the version of a package they are shipping to a newer (sometimes even latest!) release. [03:20] This is exciting. [03:20] its analagous at least [03:21] Well, seeing as how I never figured out what Git rebase did, nor how Bazaar's implementation of same worked, really, it's all the same to me :) [03:21] I'm just pleased to hear that they do, from time to time, upgrade their packages. [03:22] Sounds like a scurrilous rumor to put you off your guard. [03:25] fullermd: very likely [03:25] fullermd: but still, given that it looks like I'm going to be building, deploying, and maintaining a largish enterprise installation on RHEL over the next few months, I'll happily take false hopes. [03:27] The more hope you have, the more you can be disappointed. [03:28] I know. Isn't the universe a wonderful place? [03:28] Yeah. I've tried crushing the spirit of a pessimist before. It just has no flavor. [03:34] fullermd: did you add all-spice? [03:38] Nah, that's a little coarse for the usage. Cumin and paprika, more like. [05:30] Ah, found What Changed to cause the redirect issue. Pfeh. [05:33] fullermd: ... [05:33] * lifeless shakes his mind reading gizmo, its bust [05:34] Upgraded by system over the weekend. [05:34] Which fixed a bug in fetch(1) that cause the "don't-follow-redirects" arg to have no affect on http_s_ [05:35] And no effect, either. [05:35] Just goes to show, fixing bugs always screws things up... [05:37] :) [05:37] it also shows that the don't-follow-redirects setting wasn't affecting you :P [05:37] Yah. It was only working on http. [05:38] Which didn't have any effect on grabbing bzr{,tools}, so it was masked. [05:38] I know [05:38] just saying, delete the setting entirely, it'll be fine :) [05:39] That promises a very long discussion. I'm not sure I have the gumption to try and ram that through... [06:36] Looks like release announcement did not make it to -announce, someone needs to approve it? [06:36] sleep [07:03] Would this be enough information to file a bug with? its me trying to commit using bzr in an svn repo http://paste.debian.net/30664/ [07:04] /seems/ to be reproduceable - cd into svn dir -> try and commit -> segfault. [07:04] Kamping_Kaiser: sure, on bzr-svn please [07:04] lifeless, ok, thanks. [07:04] Kamping_Kaiser: jelmer will want your subvertpy version, platform (i386/adm64 etc) and libsvn versions I suspect [07:05] lifeless, ok, i'll be sure to include them. are bugs filed 'announced' here or should i link after filing it? [07:09] they aren't, because folk get mailed [07:15] spiv: LOL I broke the retry-tests by making packs much more efficient :P [07:21] lifeless: :) [07:21] lifeless: I was wondering what happened to your merge... [07:21] specifically I got rid of a reset() call in _refresh_data [07:22] so now it merges. hmm [07:28] lifeless, thanks for the help, bug is now filed. [07:32] Kamping_Kaiser: my pleasure [07:32] spiv: so, fixed by 'reset; refresh_data()' :P [07:32] spiv: hate this too-good code. [07:34] spiv: File "/home/robertc/source/baz/integration/bzrlib/tests/test_remote.py", line 1934, in test_ok_with_real_repo [07:34] client._calls) [07:34] AssertionError: not equal: [07:34] a = [('call', 'PackRepository.autopack', ('quack/',)), [07:34] ('pack collection reload_pack_names',)] [07:34] b = [('call', 'PackRepository.autopack', ('quack/',))] [07:34] from bzrlib.tests.test_remote.TestRemotePackRepositoryAutoPack.test_ok_with_real_repo [07:35] That eliminated a round-trip? [07:35] Peng_: changed from a private interface to a public one, round trips are the same [07:35] Peng_: this is test fallout I fear [07:36] mock objects, your best friend, your worst enemy [07:41] spiv: do you want to see these test changes? [07:41] :!bzr diff | diffstat [07:41] test_knit.py | 34 ++++++++++++++++------------------ [07:41] test_remote.py | 10 +++++++--- [07:41] test_repository.py | 1 + [07:41] test_smart.py | 4 ++++ [07:41] 4 files changed, 28 insertions(+), 21 deletions(-) [07:45] spiv: no answer == land it :P so am [07:52] lifeless: sorry, was busy thinking about pork like a tyrant day... :P [07:54] lifeless: if it's just adjusting tests in obvious ways (e.g. I imagine that the test_remote fix was pretty trivial), then +1 [07:56] spiv: mmm bacon explosion mmm [07:57] spiv: not entirely, let me pastebin the deed [07:57] http://paste.ubuntu.com/131855/ [08:00] lifeless: hmm, please adjust the test_remote change to append something like 'pack repository refresh_data' rather than reload_pack_names. It's just an arbitrary string, but I'd rather it more-or-less described the direct action... [08:01] spiv: yeah. I'll have to land that later though [08:01] lifeless: but otherwise it looks ok to me. [08:25] hi guys. Is there any nice way to do a visual diff on Windows? I have BeyondCompare installed, but using `bzr diff --using=BCompare.exe` gives me 1 file at a time [08:26] Hi, guys, I just upgraded to 1.13 to try the filtered view, but it seems that it has no effect at all. In my understanding, filtered view will only generated some part of the working tree, right ? [08:28] Will it only show the the contents in a directory DIR if I do "bzr view --name MyView DIR" ? [08:31] CaMason: I thought bzr had visual diffing builtin on windows [08:32] via the tortoisebzr thing? That doesn't work for me (64-bit) [08:32] SuperMMX: it currently only affects what the commands *do* not what is put on disk; also make sure you have followed ian's notes about it as it needs a in-development tree format [08:32] CaMason: oh :( [08:32] although bizarely, the icons do show up if I use a file browser within an application :o [08:33] lifeless: sure, the working tree format is upgraded to development-wt5. [08:34] lifeless: ... it seems that I misunderstand the feature totally at first [08:35] what's the best format for brisbane-core tests? [08:35] I thougth it will reduce the diskspace which is with very hight priority in my feature wishlist for bzr. [08:39] sabdfl: we're currently looking at gc-chk255{,-big}, not that you need to set NO_LABELS in the code to avoid parsing a lookup table that we're going to either remove or have partial-parsing on soon [08:39] s/not/note/ [08:39] But I think it should not be very hard to add that function. It will be great to only work with a small set of files in the same tree. [08:40] gnight all [08:41] lifeless: g'night [08:41] lifeless: btw, with my patch landed, tests all pass with InterOtherToRemote removed [08:41] lifeless: Good night. [08:42] Peng_: do you ever sleep? [08:44] Sleep is for wimps. [08:45] Happy, healthy, well-rested wimps, but wimps nonetheless. [08:52] so, my flatmate got a cold the day I got back from travel [08:52] I may well be cursed. [09:14] mwhudson: Disturbingly frequently. [10:06] Oh blah, merge --force is still broken. [10:18] i have a bzr-svn co of a svn repo which contains a move (everything was moved into a sub directory). now bzr log on a file only gives entries up to the move, but svn log on the same file in a svn checkout shows the full history (including before the move) [10:18] is there a way to get bzr to track the full history? [10:19] (i thought bzr should handle renames well - git shows the full log correctly in a git-svn branch if i give it the --follow option, is there something similar for bzr? [10:30] * SamB would suggest that thrope file a bug -- if only he were still here [10:31] thrope: ah! [10:31] file a bug, maybe? [10:31] hi - sorry having some computer issues [10:31] I'm pretty sure bzr-svn is supposed to handle that fine [10:32] i thought so - but I thought i'd check first [10:32] well, oh, but does SVN give the full log? [10:32] yep [10:32] good [10:32] git isn't really an indication since it doesn't track renames ... [10:33] ... it just figures them out after the fact [10:35] thrope: Is the repo public? [10:35] yep [10:35] http://pyentropy.googlecode.com/svn/trunk/ [10:35] thrope: Ask jelmer (when he comes online) and/or file a bug. [10:35] ok [10:35] i'll wait for jelmer [10:36] the file is trunk/pyentropy/pyentropy/pyentropy.py (I am just learning about python packages - it hink this will change) [10:36] hehehe [10:37] pyentropy.pyentropy.pyentropy? [10:37] first one is just a dir [10:37] because I keep something else in the repository [10:37] guess it should be pyentropy/trunk/pyentropy/pyentropy.py [10:38] I don't think bzr-svn does do svn 'renames' at the moment. [10:38] As svn doesn't do renames. [10:38] what else (besides the wiki) do you keep in the repository? [10:38] It copies and deletes. [10:38] wgrant: it was a svn move [10:38] another small module call femaxent [10:38] svn move is copy + delete. [10:38] it is related [10:39] bzr-svn could detect copy+delete as a rename. [10:39] And bzr can't track copies. [10:39] It could. [10:39] There's a bug about it. [10:39] I guess you should subscribe? [10:39] yep trying to find it [10:40] got it [10:41] * SamB personally errs on the side of reporting Invalid bugs, on the theory that most Invalid bugs are actually problems with the documentation ;-) [10:42] (or other code) [10:43] thankfully, jelmer seems to agree with me so far [10:46] also I was wondering if I can push two related bzr native branches into svn in such a way that they share history properly [10:46] (ie donthave doubled up commits) [10:47] thrope: did you try? [10:47] I figured it would involve pushing up to where they diverged to one place is svn, doing an svn copy, rebasing the branches to that copy [10:47] or something like that [10:47] I tried the naive way - pushing them both to different dirs, but there was no shared history (all the common commits appeared twice in svn) [10:47] "bzr native branches"? Why deal with svn at all then? [10:47] oh [10:48] Peng: well ... is that any reason for it not to work? [10:48] I thought you could store bzr branches in svn with bzr-svn [10:48] started as a seperate thing, but now I want to put it in the main repo (which is svn) [10:48] I guess it doesn't really matter about the repeated commits - I will just push the two branches [10:48] but I wondered if it would be possible [10:49] file a bug? [10:49] its a question really [10:49] i dont think it should work the naive way - i think i have to push the common bits, then do a rebase or something [10:49] I think maybe there should be a command for that? [10:50] or at least commands to help [10:53] * Peng_ goes to bed. [11:00] bzr log --format gnu-changelog [11:00] bzr log --format gnu-changelog [11:00] bzr: ERROR: no such option: --format [11:00] Well, something's broken with 1.13 [11:08] Has log ever had a --format? It's got a --log-format... [11:10] fullermd: Not AFAIK. [11:10] Leonidas: I think that's a typo in the NEWS file :( [11:11] ISTR a patch on the list about it, but I guess it didn't make it in. [11:11] ok. [11:12] Leonidas: Leonidas it's bzr log --log-format gnu-changelog, as fullermd says. [11:13] Leonidas: "bzr log --gnu-changelog" works too, as "bzr help log" says. [11:22] lifeless: http://people.ubuntu.com/~andrew/bzr/simplify-interrepo-stack removes InterRemoteToOther and InterOtherToRemote and has all tests passing. [11:22] lifeless: 2 files changed, 4 insertions(+), 78 deletions(-) [11:22] lifeless: :) === thekorn_ is now known as thekorn [12:50] spiv: yes, indeed. [13:11] How can I make it so when I merge and commit, the commit(s) message from the merged branch show up in the main one? [13:16] vadi2: It does, as subcommits. [13:16] Where? [13:17] Ah, just lp is not displaying it [13:17] okay thanks [13:18] eg, http://paste.ubuntu.com/131965/ - but yeah, LP doesn't show it. === nevans1 is now known as nevans [15:00] Hi, can I add a bzr branch inside another project I'm working on which is also version controlled? [15:00] (bzr add seems to do nothing in this case) [15:18] newz2000, right, it ignores any branches inside branches [15:19] is there a way around that? [15:23] no, abentley is going to work on nested trees soon [15:23] which is what you want [15:24] :-( [15:24] That'll be a cool feature when it's done. [15:25] beuno: I've already started work, in fact. [15:25] ah, that's even better! [15:25] hi abentley [15:25] beuno: hi [15:41] when will https://edge.launchpad.net/~bzr/+archive/ppa have 1.13 (bzr and bzrtools)? [16:07] you're killing me [16:08] er [16:08] wrong channel [16:08] what's the recommended commit/push emailer plugin === mtaylor_ is now known as mtaylor [16:54] vila: good evening [16:55] jam: hi ! How do you know I'm jetlagging :-) [16:55] I'm doing pretty good, all things considered [16:55] I managed to sleep on the plane at an appropriate time, and then stay up to ~9pm my first day back [16:55] So I'm probably 95% transitioned by now. [16:56] vila: I just remembered that we had talked about doing a phone call everyday [16:57] of course we missed the original time by about 3hrs, but I wondered if you were still interested today [16:57] I couldn't resist and slept 16hours yesterday, yet, I fall sleeping looking the perfmeter while toying with parallelized selftest (truth is watching the 8 curves is pretty hypnotic) [16:57] :) [16:57] jam: not today, I'm abot to stop, but tomorrow certainly [16:57] ok [16:59] jam: regarding parallel selftest, lifeless sketch is working, some rough edges (unavailable feature and know failures are missed and the test suite doesn't seem to end) [17:04] wow.... [17:04] good news for LP folks [17:04] I just did a test conversion of LP branch to CHK255-big [17:04] Orig source was 861MB, right after conversion, it dropped to 248MB, after doing "bzr pack" I'm down to 133MB [17:08] jam: wow, now *that* is significant :-) [17:08] I'm running 'repo-details' to make sure it is all accurate, but yeah, nice results [17:11] jam, that's awesome. [17:13] what's chk255-big? :) [17:14] NfNitLoop: the 'brisbane-core' work we've been working on for the past 6-8 months [17:14] split-inventory + groupcompress delta compression + a specific page layout [17:15] aah, cool. [17:15] sorry, just eavesdropping and was curious. :) [17:15] yeah [17:15] Its something we'll probably be moving into a 'development' format in bzr.dev in the next month or two [17:15] cool. :) [17:16] bzr.dev itself packed from something like 100MB down to ~25MB, IIRC [17:16] not quite as impressive, though still nice [17:31] if I have credentials stored in authentication.conf, shouldn't bzr automagically use them when I try to branch or whatever? [17:32] I need to write a hook script that will notify me by email every time someone commits a file in /trunk. I already have the email part working, but I'm not sure how to make the conditional statement to check if the commit is in /trunk. [17:33] Tak: there may be times when using a user in a URL triggers the code that tries to use a password [17:33] I certainly agree it is a bug if you need user@, but it may be a workaround you can use [17:33] I can't get it to use it with or without user@ [17:34] this is for sftp transport [17:34] at least, I'm testing with sftp transport [17:35] Tak: well, if you are using openssh as your ssh provider (the common case), we have no way to pass it a password [17:35] you might try "BZR_SSH=paramiko" [17:35] for security, openssh uses a direct connection to your terminal to prompt for a password [17:36] jam: any idea? [17:36] zsakr: Can you just check the branch url? [17:36] if thebranch.base.endswith('/trunk') ? [17:36] interesting === beuno_ is now known as beuno [17:38] Tak: I would certainly recommend using ssh keys and an ssh-agent under those circumstances, rather than paramiko [17:38] but you can use a password if you prefer [17:40] well, I'm attempting to use the authentication api generically - I just happen to be testing with an sftp transport because that's what I have on hand that's passworded [17:41] it appears to fail with paramiko as well [17:43] Tak: did you use "export BZR_SSH" ? [17:43] yeah, and the console output is different, signifying that it's not using openssh [17:48] Tak: I don't use it myself, so I'm not 100% sure how to configure everything. Though I know that http and ftp get more testing, since there aren't many alternatives there [17:48] I would have you chat with vila, since he implemented most of the auth work, but I think he stopped for today [17:48] * Tak nods [17:48] vila: ping ;-) === beuno_ is now known as beuno === fta_ is now known as fta [19:24] Is there a branch format register somewhere that will let me get all the current formats? === jelmer is now known as Guest32666 === Guest32666 is now known as jelmer [19:28] man, bzr's progress bar is so awesome now [19:28] rockstar: bzrlib.bzrdir.format_registry? [19:29] rockstar: or specifcally branch formats? [19:29] 'evening beuno, larsitq [19:29] *larstiq [19:30] LarstiQ, anything I can iterate over will do. [19:31] hey hey jelmer [19:31] how's it going? [19:31] rockstar: [] ;P [19:32] hey jelmer, beuno :) [19:32] jelmer: I started an identi.ca account! [19:32] jml, thank you again for lp-open [19:32] hola LarstiQ! [19:32] beuno: and indeed, mbp deserves much kudos for the progress bars [19:33] rockstar: the thing is, every domain object (the big three) has it's own formats, and then a combination of those is also known as a format [19:33] beuno: pretty good, looking at finally putting that first bzr-git release out [19:33] LarstiQ: whoa [19:33] jelmer, a lot of excitement around that [19:34] rockstar: so, for formats in that registry, bzrlib.bzrdir.format_registry.get('default').get_branch_format() [19:34] rockstar: but you might miss non-bundled branch formats [19:34] LarstiQ, is 'default' a format string? [19:35] rockstar: yeah, from the format_registry.keys() list [19:36] rockstar: if you are sure it is branch formats, and not repository or workingtree ones, I think only 6 and possibly 5 are 'current' [19:36] ie, bzrlib.branch.BzrBranchFormat{6,5} [19:37] LarstiQ, so I need to be able to specify a format string, and determine whether a branch with that format string needs upgrading. Maybe that'll help you give me clues. [19:37] LarstiQ: isn't it branch7 that adds stacking? [19:37] mwhudson, the source would say so [19:37] mwhudson: if it does, it's hiding [19:38] hmm, maybe import didn't get to it properly [19:38] LarstiQ, bzrlib.branch.BranchFormat7 is the first that overrides supports_stacking to return True [19:38] * LarstiQ quizzicaly looks at ipython [19:38] LarstiQ, so you see my dilemma. [19:38]