[00:00] does it say blackbox.test_diff, or bzrlib.tests.blackbox.test_diff ? [00:00] Ah, it's working [00:00] I, apparently, had not used the . :p [00:00] * ./ [00:00] :) [00:00] ERROR: blackbox.test_export.TestExport.test_tar_export [00:00] global name 'tests' is not defined [00:01] try ./bzr selftest --no-plugins [00:02] if that works, you have a plugin adding tests oddly [00:02] Well if I'm running from a source distribution, would it still find any plug-ins? [00:02] yes [00:02] The system running those tests doesn't have any in ~/.bazaar [00:02] ok [00:03] but it does in the system-wide bzrlib [00:03] this is windows? [00:03] Mac OS X [00:03] ok [00:03] please try anyway [00:03] './bzr selftest --no-plugins' [00:04] looks good [00:04] seems it does load system-wide plug-ins [00:04] *eats his tongue* never mind [00:05] same error [00:05] well, maybe just bite :p [00:05] ok [00:06] what version ? [00:06] 1.12 [00:06] quite a few failures in blackbox.test_filesystem_cicp [00:06] its odd that its only reporting 'blackbox..' rather than bzrlib.test.blackbox... [00:07] it makes me think something has gone seriously wrong with module loading [00:07] what python version ? [00:09] 2.5.1 [00:10] (apologies for the delay) [00:14] vila: was that the bust version? [00:20] So aside from that import error and the failures in filesystem_cicp it looks good so far [00:20] Are those filesystem tests known failures on OS X? [00:20] lifeless: your extend_command patch ignores the "plugins_override" parameter that controls whether plugins should be able to override builtins. Is that the desired behaviour? [00:21] james_w: yes [00:21] james_w: because that patch doesn't support replacing commands at all [00:21] jfroy: theres a buggy python on some mac os X's [00:22] jfroy: bugs in the tarfile module, and somewhere else, IIRC [00:28] abentley: on http://bundlebuggy.aaronbentley.com/request/%3C1235999150.10731.0.camel@flash%3E, it would be nice if the project: Bazaar link was to merge requests, and the actual project-meta-data was a link on the right [00:28] abentley: just an oddity but I *always* click on Bazaar and end up where I don't want to be [00:40] jelmer: has the network_name stuff been clear enough for you? [00:56] jelmer: hey, which branch of TracBzr should i use for trac 0.11.3 ? [00:59] lifeless, is there any reason for not explicitly comparing that the various bits that make up a repository's stream ? [00:59] rocky, sorry, I no longer follow trac-bzr development [01:00] rocky, I've only been involved to the degree that we need it for bitlbee [01:00] jelmer: someone is the lead maintainer or it's simply not being maintained? [01:00] rocky, I don't think there has been a maintainer for the past 2 years [01:01] ouch, that's too bad [01:02] rocky, I have been doing some work keeping merging patches people put up until a couple of months ago [01:02] s/keeping// [01:02] gotcha [01:03] rocky: There's enough people interested in trac-bzr, there's just no maintainer atm [01:03] i need it for ClueMapper [01:03] i want to support bzr as the main repo format instead of svn under my trac [01:05] rocky, would you be interested in stepping up as maintainer? [01:05] rocky, It shouldn't be a lot of work, as there seem to be enough people proposing patches [01:05] mwhudson: https://code.edge.launchpad.net/~jml/+junk/bzr-establish [01:05] thanks [01:05] there just needs to be somebody to review and merge them [01:06] jelmer: can you rephrase - 'explicitly comparing that the various bits that make up a repository's stream [01:06] ' [01:06] jelmer: it's a possibility [01:06] jelmer: lp:~jelmer/bzr-git/jelmer, not lp:~jelmer/bzr-git/trunk, right? [01:07] lifeless, so, rather than defining that repoformat X matches the network representation of repoformat Y, wouldn't it be possible to just compare the serializer format, inventory format, etc? [01:08] lifeless, Not suggesting it should work that way, just wondering why it can't work that way? [01:09] mwhudson, Yeah, http://people.samba.org/bzr/jelmer/bzr-git/trunk [01:10] mwhudson, it requires bzr.dev atm [01:10] jam, if you're still here, is there any mysterious reason why http://pastebin.ubuntu.com/125544/ is not a valid simplification? [01:10] jelmer: ok [01:10] mwhudson: http://code.mumak.net/2008/10/bazaar-hacking.html ; http://code.mumak.net/2008/10/more-bzr-hacking.html [01:12] jelmer: su [01:12] jelmer: 'so'. [01:12] jelmer: two formats may have the same serialiser but still not want to behave identically [01:13] jelmer: (format) is a complete encapsulation of behaviour, and works for things like bzr-svn that don't particularly even have serialisers [01:14] jelmer: I think we do want to end up with a complete meta-description, but we're currently adding dimensions faster than verbs are keeping up, so using a format.network_name is future proofing until we're ahead of the curve and can lock-down the round trips for operations and eliminate teh vfs [01:14] lifeless: ah [01:14] lifeless: That makes sense to me [01:14] lifeless, so [01:15] lifeless, bb:approve [01:15] I accidentally rebased a branch, and now I want to get back the original. what would be the easiest way to find the tip revision ID for the original? [01:15] lifeless, as this was the only bit I wasn't sure about [01:15] jelmer: well, its all landed :P I was more asking because we have the room to change things if it was interacting badly with bzr svn [01:15] nevans: "bzr heads" from bzrtools will help [01:15] lifeless, ahh [01:15] bzr heads is taking forever to return... is there some way to point it at the last common revision, and tell me only the descendants of that? [01:16] jelmer: I have no desire to make your task *harder* :P [01:16] lifeless, it shouldn't affect bzr-svn unless you're pushing from a svn repository to a smart server right? [01:17] BTW: as an aside, I really like how "bzr uncommit" gives you the original revision id right before it does its work. ;) [01:17] jelmer: or pulling from a smart server with svn behind it [01:18] jelmer: so you have several things you can do; you could: [01:18] - return a network_name of a bzr native format [where you claim that your streaming data is that format, and that cloning should create that format] [01:18] - return a unique network_name [where both ends will need bzr-svn installed, but you can potentially stream in a optimised form] [01:20] I can't really do (1) sensibly [01:20] since it will mean things using Repository.{texts,inventories,revisions} a lot [01:22] ok [01:22] * mwhudson gets the feeling he's doing it wrong [01:22] bzr: ERROR: No such file: u'/home/mwh/src/git-play/.git/inventory': [Errno 2] No such file or directory: u'/home/mwh/src/git-play/.git/inventory' [01:22] note that pushing from a svn workingtree to a hpss smart server is probably not that common :) [01:22] mwhudson, bzr-git doesn't support working trees yet [01:22] lifeless, I've seen people do it :-) [01:22] mwhudson: its not finished :) [01:23] i guess i should read the README [01:23] jelmer: how can i make it do something interesting? [01:23] jelmer: ok; so we can either say 'install bzr-svn on the server' (for 2), or perhaps have a bzr-svn-light that has just the Format objects, no actual capabilities. [01:24] mwhudson, bzr.dev branch git://git.kitenet.net/etckeeper [01:25] lifeless, there's no fallback scenario in case the network format the server offers isn't supported by the client? [01:25] no *generic* fallback scenario [01:26] jelmer: no [01:27] jelmer: you wanted to avoid people creating branches on the server the server can't open; this does that :) [01:27] jelmer: eh, i thought network support was flaky, did i get the wrong end of the stick [01:27] anyway, seems to be working, yay [01:28] mwhudson, pull is the main thing that's flaky [01:29] jelmer: ok [01:29] lifeless, well, if the server understands the format a branch is stored in, it could always send it to the client in some generic format that the client udnersatnds [01:29] mwhudson, please do file bugs for things you find don't work or don't work well [01:29] lifeless, can you explain the bzr-svn-light thing a bit perhaps? [01:30] jelmer: how do you use a dev version of dulwich out of curiosity? just set $PYTHONPATH [01:30] mwhudson, yeah [01:31] fair enough [01:32] lifeless, did apt-get find python-subvertpy for you btw? [01:32] jelmer: well for starters, bzr init; bzr pull git:// breaks nastily :) [01:32] init --1.9-rich-root is fine though [01:34] mwhudson, whoops [01:34] jelmer: no [01:35] * jelmer gets some sleep [01:35] jelmer: so, generic formats - yes, we could write a mapping table that says '1.9 is the same as 1.6' [01:36] jelmer: and if we tell the client about a format it doesn't understand, it could ask us to translate somehow [01:36] jelmer: and similarly client -> server [01:36] lifeless, yeah, that's what I meant [01:36] jelmer: however, option (2) doesn't have a mapping from 'svn' to 'bzr' at all at the moment:P [01:37] ah, in that sense [01:37] lifeless, tunneling svn over bzr [01:37] jelmer: spiv and I discussed doing this if its needed, but right now there is simply no way to work with a format not mutually known [01:37] jelmer: so we felt it was ok to not-improve-the-situation [01:38] lifeless: Yeah, I agree [01:38] jelmer: go sleep. doing some testing might be good if you get the chance [01:38] if we're wrong and it it suddenly problematic, we have 1.5 weeks to get a solution for the beta [01:43] still waiting for "bzr heads" to respond with anything... in the meantime, I've managed to open a python console and get the base revision before the rebase. [01:43] jelmer: functionally, if i point repository_dir to some random dir that contained repos that contained various branches.... trac should "think" that the random dir is the base repo right? (for TracBzr) [01:43] is there any way for me to use the Revision object to tell me its children [01:43] (I'm very much a python newb) [01:44] nevans, fwiw bzr-rebase will store the revid of the revision it is a rebase of [01:44] jelmer: o rly? :) [01:44] nevans, in the 'rebase-of' revision property [01:44] too easy. :) [01:45] nevans, it's not exposed in the UI, but there under the covers [01:45] how do I retrieve the revision properties? [01:45] rocky, I think some people reported that that bit was broken [01:46] rocky, It seemed to be having trouble using more than one bzr repository [01:46] rocky, but multiple branches would be fine [01:46] rocky, at least that's what I remember reading [01:47] nevans, If you have a Revision object, it has a 'properties' member [01:47] nevans, Repository.get_revision("some-revid").properties["rebase-of"] [01:47] jelmer: most trac projects i work with don't really correspond to the lightweight notion of bzr repos... since my trac projects consist of more than one code component and each code component really should get it's own bzr repo [01:47] nevans: revision.parent_ids [01:47] so i guess the multiple repo thing is something that "fits me" [01:47] rocky, are you talking about a bzr repo or a bzr branch? [01:48] jelmer: thanks. that does it! :) [01:49] jelmer: well, i have the ClueMapper "project" where it has it's own trac site ... but that project has 5 different libraries that all relate to one another conceptually ... so it seems to me each library should get it's own repo [01:49] and then each library (which has it's own repo) has it's own trunk and various branches [01:49] any decent-size project i work on is like that [02:09] jelmer: so if i call tree.inventory.path2id('') then bzr returns me None if the root of the branch has no files? that seems, odd [02:23] rocky: two trees A and B that are both for different projects have different root ids [02:24] rocky: at some point between 'null tree', 'new tree' and 'first commit' the id has to be set [02:24] rocky: bzr chose to do it at 'bzr add' in the new tree [02:24] ah [02:29] lifeless: i'm using launchapd branches for the first time and when i try to push my local branch to a launchpad branch that i just registered it gives on odd error saying the target branch exists but doesn't have a valid .bzr directory ... is that normal? [02:30] mwhudson: ^ [02:30] rocky: push --use-existing-dir probably? [02:31] rocky: but in general, don't register hosted branches in the ui :/ [02:31] lol [02:31] poolie: http://pastebin.ubuntu.com/125544/ seems fine to me [02:32] rocky, seriously, it's best to just push to Launchpad. [02:34] rockstar: sure, i will from now on... but i was just following the logical path to do what i needed, so i guess something needs some work there ;) [02:34] rocky: yah, it needs to be deleted :) [02:34] hehe [02:34] whatever works ;) [02:34] anyways, bedtime for me [02:34] night [02:34] gnight [02:53] thanks jam [02:53] and thanks for the reviews [03:01] dulwich and bzr-git require python 2.5 ? [03:01] * mwhudson sads [03:02] I'm upgrading my smart server to 1.12. I'm currently running it out of fcgi. Does this still work or should I be using bzr --serve? [03:03] johnf: hi; afaik it should still work; spiv should know [03:03] johnf: it should still work [03:03] johnf: please tell us if it doesn't :) [03:03] Might switch to serve and cook up an init script for the debian package [03:04] igc [03:04] is back [03:05] hi igc [03:05] johnf: FWIW most folk run over bzr+ssh i think [03:05] hello igc [03:05] johnf: afc runs a live server with --serve, on the internet. He may have a script. [03:13] johnf: what poolie and lifeless said. [03:13] spiv: I'm going to move to --serve the fcgi was a pain [03:14] Fair enough. [03:14] Which HTTP server? Apache? [03:16] yes. Going to use mod_proxy [03:16] erem [03:16] johnf: --serve isn't http [03:17] lifeless: did you also say something similar to https://bugs.edge.launchpad.net/bzr/+bug/322893 [03:17] Launchpad bug 322893 in bzr "new progress bars only use 80 columns" [Medium,Confirmed] [03:17] lifeless: ahh :) [03:17] johnf: --serve is 'bzr://'. IANA registered protocol. [03:18] ok back to fcgi then :) [03:18] johnf: if you want bzr-over-http, you need mod_python or fcgi or whatever [03:18] johnf: you don't need to do bzr-over-http [03:18] poolie: yes, I did [03:18] poolie: I also filed a bug about comment truncating [03:19] lifeless: yeah pondering connecting to it directly at the moment === Toksyuryel` is now known as Toksyuryel [04:34] should "bzr serve" be logging a whole heap of NotImplemented errors? Works fine but is logging errors [04:34] probably not [04:34] like what? [04:42] hello [04:42] hi [04:42] [- ] Transferring:Walking content. 0/36 [04:43] :-} [04:43] I've been pushing up a branch to Launchpad for about 421.534s now [04:43] srsl? [04:43] got a trace? [04:43] yes. [04:43] poolie: I've got the bzr log [04:43] poolie: and I'm running with -Dhpss [04:44] show spiv/lifeless? [04:45] jml: version? [04:45] http://paste.ubuntu.com/125595/ [04:45] Bazaar (bzr) 1.13dev [04:45] johnf: its a bug, fixed in bzr.dev [04:45] from the nightly ppa [04:45] jml: revno please [04:46] jml: the full package version has the revno in it [04:46] (bzr version should tell me the revno, don't you think?) [04:46] Version: 1.13~bzr8.10-4065-1 [04:46] jml: (maybe, file a bug on the packaging) [04:48] it's still going, fwiw. [04:49] ok, now it's done [04:51] jml: it was reading from 186.818 hpss call w/readv: 'readv', '/~launchpad-pqm/launchpad/devel/.bzr/repository/packs/fee0993f46df016a5650a9004f0f4fdf.pack' [04:51] and writing to [04:51] 187.201 hpss call w/body: 'append', '/~jml/launchpad/source-package-branch-listing/.bzr/repository/upload/05wh3tplu93ue19c02ok.pack', [04:52] jml: I suspect it was filing in missing deltas for files you modified the first time [04:52] This is probably a stupid question, but I can't find an answer. I'm using bzr in a simple centralized manner (checkout/commit) and I can't find a command similar to subversion's 'svn st -u' (that is, I want to see what has changed upstream since I last updated) [04:52] fignewman: bzr missing [04:52] lifeless: that's quite possible. [04:53] jml: so, this is because the streaming code path precludes the pack optimised one, which really is quite fast; we're using the public generic interface to stream [04:53] lifeless: I know what all of those words mean. [04:53] jml: -> should be faster on bzr.dev servers, but some possibilities of slower on downlevel smart servers [04:56] lifeless: thanks. It's complaining, but I think I know why. [04:57] lifeless: would be nice if it defaulted to the branch when using a checkout. [04:57] fignewman: possibly;possibly we should do status -u for this case [04:58] fignewman: our checkouts are also branches (in that they are a checkout of a branch) [05:01] lifeless: is there a way to set a default or should I just use an alias? [05:02] fignewman: there may be a canned alias like :master, not sure though [05:02] fignewman: you can just do missing --remember [05:02] jml, i got a tuit to make a debug_flags config option [05:03] lifeless: if I set post_commit_to in ~/.bazaar/bazaar.conf in the [DEFAULT] section should bzr-email work for all branches? [05:04] johnf: yes [05:04] poolie: what for? [05:05] so people can always capture hpss logs rather than needing to remember it [05:05] i guess you can use a shell alias === eMBee_ is now known as eMBee [05:06] lifeless: --remember doesn't seem to be in my version (1.3.1). For all I know, my issue was long ago resolved anyway. Thanks for the help. This will work nicely. [05:08] poolie: you can't pass debug_flags to a smart server [05:08] poolie: it would be nice to put them in branch.conf and have it just work :) [05:09] lifeless: when it's run over ssh you mean? [05:09] i think what i'm doing will make it read them from ~/.bazaar/bazaar.conf on the server [05:09] ok [05:09] thats a start :) [05:09] poolie: oh, cool. [05:09] starts are good :) [05:09] poolie: well, I have -Dhpss [05:09] as an alias. [05:10] poolie: but that sounds like a great idea. [05:24] lifeless: for bzr-email when the hook runs under bzr serve the op type seems to be "change" instead of "commit" does that make sense? [05:25] johnf: yes. Possibly a bug, but probably just de riguer [05:28] what is a change vs a commit. Should I patch bzr-email to also send email on change or work out why it's change instead of commit? [05:29] johnf: change is uncommit/push/pull [05:29] johnf: commit is commit [05:29] johnf: have you read 'bzr help email' ? [05:29] yes [05:29] it can send mail on change [05:29] what bzr-email version do you have? [05:30] trunk. But the thing is I'm performing a commit not a push. or does a commit become a push over bzr:// ? [05:32] johnf: it becomes a push [05:32] two-phase commit thingy [05:33] ahh ok I'll set post_commit_push_pull then [05:33] you want a patch for the docs to make that more obvious? [05:33] or would a patch for bzr-email to detect it's running in server mode make more sense? [05:34] feel free to make it as lovely as possible [05:34] I don't know offhand how easy it will be [05:35] * igc offline for ~ 2 hours [05:37] [rfc] rename TestCase.get_transport to something like get_test_transport, because it's not interchangeable [05:38] poolie: mmm, it could detect absolute urls, but we shouldn't really be using those in tests *anyway* [05:38] detect them and error? [05:38] i guess [05:39] well, actually we commonly do if we have a url from somewhere else [05:39] foo.base for example [05:41] well, we have foo then :) - is this something you're running into repeatedly? [05:43] any easy way to work out from a plugin if you are running in server mode? [05:46] johnf: 16:30 < lifeless> I don't know offhand how easy it will be [05:46] lifeless: heh I'm going to try for the server_started hook [05:47] although I have a feeling I won't get the callback [07:01] spiv: arrrgh test_stacking failing, sometimes, if you run a specific test before it [07:15] hi all [07:45] is there a way to get the path to the repo from the branch object? ie if it is chroot-1244:///devel/test I want '/devel/test' [07:46] or do I just need to regex on branch.base? [07:51] its a software chroot [07:51] look at bzrlib.transport.chroot [07:51] but! [07:52] what you probably want is branch.public_location() or whatever [07:53] lifeless: yeah I'm hacking the public_branch functionality. I adding public_branch_prefix which gets put on the front of everything served by the server [07:55] johnf: why do you want the repo at all though [07:56] as in why am I running a server vs bzr+ssh? [07:56] no [07:56] as in why do you want the repo at all [07:57] as in why do I want a central code repository? [07:57] no [07:57] you said you wanted the path to the repo - /devel/test; thats not usable in the general case by clients, its not relevant for bzr commands, it doesn't really have any use. [07:59] so I assume you have a larger use case [07:59] for the email in bzr-email. ie right now the email is displaying chroot-123:///devel/test or for other branches in that repo chroot-234:///devel/website [07:59] and I'd like to know what it is [07:59] johnf: branch.public_location() -> print that [07:59] ie multiple branches serverd by the same "bzr server" [07:59] johnf: if thats wrong, the server admin can fix it by configuring in branch.conf or locations.conf [08:00] its the same problem as a backend webserver with a squid frontend:) [08:01] you have to tell the backend somehow where clients are coming into it from [08:01] doesn't that assume I set public_location for every branch? [08:02] yes, so - if its not there assume branch.base is sane IMO. [08:02] as an admin you can set it for all served branches with three lines in locations.conf [08:02] once per branch or globally for all? [08:02] for all [08:03] ahh that's what I want let me go look that up [08:06] lifeless: hmm what would I be setting in locations.conf? [08:07] in theory; note that you may have found a bug/current limitation - we need more adopters of server side stuff! [08:07] [file:///srv/bzr/blah/blah] [08:08] public_branch:policy = appendpath [08:08] public_branch = bzr://host [08:08] then .../blah/blah/b1 [08:08] will get [08:08] bzr://host/b1 as its public url [08:08] for instance, I have: [08:08] [sftp://bazaar.launchpad.net/%7Ebzr/] [08:08] public_branch = http://bazaar.launchpad.net/~bzr/ [08:08] public_branch:policy = appendpath [08:09] "everything I push to lp/~bzr is visible on http://.../~bzr [08:09] ok let me give it a whirl [08:09] the transport chroot may break it [08:09] if so file a bug [08:09] but thats the _right_ solution [08:10] and then that should appear in branch.get_public_branch() ? [08:10] yes [09:04] woo, finally landed that branch [09:05] I thought it would never give in and succeed [09:15] lifeless: just sent you a review request. I have a feeling the way I store wether we are in server mode is a bit of a hack. But my python skills are lacking [09:23] johnf: thanks [09:24] I also have a patch for the locations.conf chroot problem. But I'm trying to find a less hacky solution [09:25] At the moment I convert chroot-12345:///devel/test into /devel/test which means you can match it using [/] in locations.conf [09:25] I would teach the location config handler that a chroot transport is to be unchrooted, then looked up [09:25] I'd really like to get at the non-croot path so I could turn the chroot into /srv/bzr/devel/test and match using [/srv/bzr] [09:25] keep Branch ignorant of that [09:26] in config.py? [09:26] that's where I've been hacking so far. it;s the unchrooting from there that is the trick [09:27] bzrlib.transport.chroot [09:27] look in there [09:37] hi, i've got a problem with my bzr where if I do a second commit I get a SHA1KnitCorrupt error - anyone had this before? [09:40] no [09:40] what bzr version? [09:40] 1.12 [09:40] are you on nfs/ftp/sftp? [09:41] its a branch I got via sftp yeah [09:42] does 'bzr check' pass on it? [09:48] with flying colours [09:49] unusual :P [09:49] uhm, what does bzr info -v report ? [09:50] http://pastebin.com/m35a6a43c [09:50] can someone explain why i have bzr looking for an svn cache? [09:50] bzr status [09:50] Initialising Subversion metadata cache in /home/kgoetz/.bazaar/svn-cache/d35b4800-ec1a-0410-b8e8-ae9f3643f637 [09:50] is this a bug, or a feature i've not noticed before? [09:51] Kamping_Kaiser: you have bzr-svn installed, and have run bzr in a svn checkout [09:51] Kamping_Kaiser: its doing just in time translation of metadata [09:52] lifeless, aaah, that explains it. (i only installed bzr-svn recently). thanks for telling me - i'd forgotten this was an svn dir *heh* [09:52] Kamping_Kaiser: that is the idea :) [09:52] crisb: this is very odd [09:52] crisb: unfortunately its late for me; could you file a bug? [09:52] * Kamping_Kaiser tries it out. [09:52] you should get a backtrace in ~/.bzr.log , that backtrace with the version details and so on would be very useful [09:54] lifeless: sure. its strange I've tried it on another machine with python2.5.2/bzr 1.11 and all ok. the branch is taken from a machine with bzr-1.12/python2.6.1 [09:54] crisb: none of those raise alarm bells [09:54] crisb: and check dos a scan of all the texts that could be failing [09:56] lifeless: bzr check fails as soon as I've done the first commit after branching [09:57] the sha1 that is corrupt is the one of the last revision [09:58] crisb: its fascinating, and AFAIK unique, but I have to halt() [09:58] crisb: sorry [09:59] jam: vila: either of you might like to look at this ? ^ [10:00] lifeless np ;) [10:00] about halting that is! [10:06] lifeless: just to confirm the functionality. If I have a location of [/srv/bzr] and I have append policy with public_branch = http://bzr.com/ then if a banch lives at /srv/bzr/project/trunk then the public url should be http://bzr.com/project/trunk [10:09] crisb: Did you file a bug already ? [10:11] vila: not yet I was just fiddling around a bit more [10:11] crisb: ok, Di you try bzr check just after branching ? And what bzr version do you use on the machine where the bug is occurring ? [10:12] bzr check just after branching is fine, its bzr 1.12 [10:12]