[00:00] that makes sense to me [00:00] under /srv or something? [00:01] yeah, /srv/pqm.ubuntu.com/chroot-pqm-bzr-amd64-lucid [00:03] poolie: okey, all changed. [00:03] thanks, we can call that ticket done then if you like [00:04] i don't know if it's easy for you to then do 42500(?) about the dchroot warnings, or if that's with someone else [00:04] poolie: did you want to leave the old chroot hanging around until the end of the week? [00:07] if that's not too much trouble [00:08] nope, thats fine, I'll just reply to the ticket saying its all done bar the shouting^Wremoval, and close it off after I get rid of it on Friday after checking with you [00:09] you could even lodge an at job now [00:09] though i would find an at job doing 'rm -rf' a little scary to set up myself :) [00:10] ah, and of course it will need care if anything is bind mounted [00:11] poolie: yeah. [00:11] brb, rebooting natty === Ursinha-afk is now known as Ursinha [00:21] poolie: passing around, but there was a problem with pqm, see https://code.launchpad.net/~jelmer/bzr/importwarning/+merge/57184 [00:23] oh hi vila [00:23] thanks for pointing that out [00:25] vila, i had inferred that this was just a change due to moving from 2.4 to 2.6 [00:25] that it now raises a warning rather than an error [00:25] does the patch fix it? [00:26] yes, at least it landed, I'm surprised we never encounter it though, so I wonder if there isn't something weird in the pqm setup [00:27] vila, it may be that pqm runs selftest with -Werror and we normally don't? [00:27] or i normally don't [00:27] or actually does selftest turn that on itself? [00:27] IIRC all branches are configured independently and each one specify PYTHON=python2.4, so I don't know if only trunk were updated for that or all other branches too (well at least the ones we still need: 2.3, 2.2, 2.1 may be not 2.0) [00:27] ha right, yeah good point [00:28] tsk, I even mentioned to jelmer that -Werror may be involved... [00:28] bradm, ^^ can you just check we don't have any more PYTHON= things hanging around? [00:28] I don't think selftest turns it on, it's make check I think [00:28] that was what i thought, but i'm not sure without checking [00:30] * jelmer waves [00:30] vila: you're up late :) [00:31] poolie: looking.. [00:31] jelmer: yeah, can't sleep :-/ [00:31] poolie: nope, definately no PYTHON= in the bzr-pqm.conf [00:31] excited about your trip? [00:31] thanks [00:31] or, trying to fix everything in bzr before you go? :) [00:44] poolie: hehe, probably hafl excited and half worried about my daughters and half trying to finish fixing the remaining bugs ;) [00:50] are they going to be looking after themselves while you're away? [00:51] yup for roughly a week, after that they'll be with family [00:51] first time I managed to convince Val, so now *I'm* worried ;) [01:04] Good morning. [01:23] * spiv reboots into natty, hopefully [01:34] hello! how do i create a patch containing binary files? [01:37] i just added some icons to a project, and i'd like to send the changes as a patch, but all it says in the diff is "Binary files ....... and .......... differ" [01:44] and when i try to do --format=svn (it's an SVN repo i want to contribute a patch to), it complains about it being a binary file [01:48] inductiveload: the patch format doesn't support binary files. [01:48] inductiveload: bzr's native merge directives support them [01:48] inductiveload: but I don't know that SVN has a builtin tool to consume patches to binary files. [01:48] ok [01:49] (If it does, then it'd probably be a bug in the bzr-svn plugin if --format=svn doesn't emit that) [01:49] then what would be the "right" way for me to hack on an SVN project and submit a patch (or patch-like sometihng) that can be used to apply my changes? [01:50] i've only ever submitted normal diffs to things before, and never a binary file [01:53] favourite command-line of the day: bzr missing --mine-only --include-merges :parent [01:53] inductiveload, ...well, there's xdelta, but the real issue is that there _isn't_ any format which will show the differences between two binary files in a human-readable and mergable way, and at that point you might as well just submit the whole new file unless it's a size/bandwidth constraint. [01:53] (err, maybe it's xxdelta) [01:55] right, so i just have to send an archive with the image folder saying "paste this into the root directory"? [01:56] there's no size or bandwidth problem, it's just that I thought there'd be a way to pass over a single file holding all the changes i'd made [01:56] for binary files, svn diff just says "Cannot display: file marked as a binary type." [01:58] and I don't think svn has a command for *applying* patches at all? [01:58] i have no clue, i've never used svn, that's why i'm using bzr [01:59] but the sourceforge repo is SVN, so how do i get my change across, short of tarring the whole damn thing, and letting them make a diff? [02:00] inductiveload: ask the developers how they'd like to receive changes [02:00] ok, i tohught there would be an "easy" way to do it ;-) [02:00] inductiveload: or e.g. send them the xxdelta, but also explicitly say "if you'd prefer this in another format, just let me know" [02:01] Not that I know of, unfortunately. But talking to people is usually not *too* hard ;) [02:01] :-p ack....interaction.... [02:22] hi there spiv [02:23] spiv i'm going screen and un-hide the ubuntu bzr bugs [02:27] spiv and co, thank you for you help [02:27] poolie: sounds good. [02:27] inductiveload: you're welcome. [02:27] and thanks for making bzr - it's great! [02:29] poolie: I've been spending the morning mainly getting used to natty & unity, and about to dive back into that pack retry bug [02:30] (I'm going to have to retrain my fingers a bit; I used to use Super- to switch workspaces…) [02:36] ok [02:36] how's hamster? === Ursinha is now known as Ursinha-afk === r0bby is now known as robbyoconnor === Ursinha-afk is now known as Ursinha [06:51] poolie: almost there ;) For hamster on natty, Alberto Milone started a project to put hamster into the indicator area: http://albertomilone.com/wordpress/?p=502 [06:51] spiv, well, i hit some more natty bugs including the rather amusing 758335 [06:52] but now, for sure, bug re-publicizing [06:52] hi vila [06:52] that sounds good [06:52] poolie: I didn't found the time to test it yet, only looked at the code which seems simple enough === r0bby is now known as robbyoconnor [06:52] i was thinking about puttting it into couch so it would sync across machines [06:52] there may be easier ways [06:53] poolie: hehe was about to mention my trick [06:53] hi - I'm wondering if it's a bug that 'bzr qlog' shows revision numbers starting at 1 and 'bzr log --line' shows them starting at 0? It's really confusing when 'bzr revno' doesn't show the same number as 'bzr qlog'. [06:53] is this worth reporting? It seems like something you probably already know about...? [06:54] poolie: there is a single file you can copy across hosts (~/.local/share/hamster-apple/hamster.db) [06:54] poolie: I have tested that it can be copied while no activity is tracked [06:55] that's true [06:55] maybe i should just do that [06:55] thomi, bzr log --line really shows a revision 0? [06:55] good enough for me, I never track two activities at once [06:55] please do file if so [06:58] poolie: pretty sure....I'll double check thanks [06:59] vila, i was a bit concerned it would touch the file even if nothing's being tracked [06:59] probably unlikely [07:02] poolie: it seems to update it only when needed [07:02] hehe, probably too vague a description :-) [07:03] thomi: interesting, is the very first revision a merge perhaps? [07:03] but I did some copys back and forth across several dats [07:03] spiv: possibly - I just noticed that it doesn't happen to all branches - but I have access to the branch where I noticed the issue [07:04] err, how would I tell? in qlog it doesn't show as a merge... [07:05] unfortunately I cannot make the branch public, it's not open source code :( [07:05] Oh wow, doing a merge in the initial rev gives some screwed up results! [07:05] revno -174 anyone? [07:06] spiv, there might already be a bug for that [07:06] Yeah, I think so too, this looks familiar [07:07] oooh - if I do 'bzr log --include-merges' the numbering becomes identical to what qlog reports [07:07] 'bzr init foo; cd foo; bzr merge $otherbranch; bzr ci' makes a branch with broken revision-info according to 'bzr check' [07:08] nice... [07:09] thomi: what does 'bzr check --branch' report for your branch? [07:09] poolie_, thomi: bug 522740 [07:09] Launchpad bug 522740 in Bazaar "Merging a branch into empty branch shows negative revision numbers in bzr log" [Low,Confirmed] https://launchpad.net/bugs/522740 [07:10] yup; probably should bump that up to at least medium [07:12] found error:Internal check failed: revno does not match len(mainline) 15 != 16 [07:15] so, is there an easy way to "fix" my branch? [07:19] thomi: bzr reconcile [07:24] cool - that works a treat, thanks === psynaptic|away is now known as psynaptic [07:36] hi all ! Last run ;) [07:38] so what's up for the last day of school? [07:41] poolie_: addressing some FIXMEs in my config proposals, mostly related to tests [07:42] poolie_: I came across them yesterday trying to implement the current locking scheme, hmm, more like option life cycle scheme instead [07:43] the later should just be to save on every modification, but testing that was... messy, so I stepped back [07:44] the "bug" is that from_string can't be easily re-used for all stores as it requires handling the same parameters as __init__ [07:44] that's wrong [07:44] mainly because it makes creating in-memory config objects far too hard [07:46] so I will allow load_from_string instead, targeted at tests only (AFAICS) as it makes no sense for code to inject a bunch of new options without going thru the "regular" API [07:46] sorry, i didn't get to read them last ight [07:46] no worries [07:46] you'll have two weeks ;) === poolie_ is now known as poolie [07:47] but if I can leave you a cleaner place, you should enjoy playing with it a bit more ;) [07:49] also, loading from a string *is* wrong if the store is already loaded (unless you're testing a particular case and knows what you're doing) [07:50] I'm not quite sure if I should leave such a method in the public API or only hack it from tests (test code in production is bad) but I'll start with the former anyway === Ursinha is now known as Ursinha-afk [08:40] sorry i didn't look closely enough to say [08:41] vila bug 712775 may be of interest? [08:41] Launchpad bug 712775 in bzr (Ubuntu) "bzr crashed with InvalidEntryName in __init__(): Invalid entry name: bindings/Makefile.in" [Undecided,Confirmed] https://launchpad.net/bugs/712775 [08:42] poolie: 85% sure it's a dupe and fixed in later releases [08:43] :) [08:43] hooray [08:44] bumping to 95%, the bug was due to my misunderstanding of the tt API, never ever try to use relpaths, always deal with parent_id and basename [08:44] :) [08:45] ghaaaaaaa [08:45] one more VM dying under my crying eyes :( [08:46] Don't cry. It makes VB sad, that's why it's crashing. [08:47] * vila disables karmic again, as silly as it seems, the huge number of spurious failures these last days *always* included it [08:48] on the positive side, upgrading the natty vm *today* allowed unity to start for the second time (since I started tracking it) === Ursinha-afk is now known as Ursinha [09:30] hmm. natty [09:30] I wonder when I should dare upgrade my main machine [09:34] maxb: AIUI, one of the main risks is the graphic card (any card less than 5 years should be supported though) [09:36] maxb: I had 3 tests setups: vbox, kvm, an apple laptop, all 3 works today but only the later has been working for a couple of weeks now [09:38] My laptop's under a year old, so I should be fine [09:42] maxb: there is a live CD that should allow you to test it without installing too [09:43] maxb: another important risk is that the UI is quite different so if you customized your setup you'll probably have to find alternatives [09:44] for values of setup including mainly the desktop/wm that is [09:47] I just started using natty today. I haven't found the transition too painful. [09:47] Despite having some custom key shortcuts I've been used to that unity really wants to use for a completely different purpose :) [09:48] two remaining nits: gnome do incremental matching is better than the dash one, no more hamster in the toplevel bar [09:49] spiv: yup, Unity stealing my Super key from emacs required some xmodmap trickery and muscle memory re-training [09:49] My major gripe is the globalmenu. [09:50] It really doesn't work very well with focus-follows-mouse. [09:50] I love it, one more usable line to display code [09:50] I can appreciate more screen real estate for code. [09:50] soren: hehe, yeah, same here, one trick is to type Alt first to activate the menus [09:51] vila: Oh, that makes them stay? [09:51] soren: yeah, if Alt is still available (which isn't my case ;-}) [09:51] Heh :) [09:51] vila: I should try that. I've just disabled the globalmenu proxy thing. [09:51] Alt is Meta here [09:52] soren: the other trick is to use applications where I *use* the menus in full screen mode (where ffm doesn't really make sense anymore ;) [09:56] I have a pretty big monitor. I bought so that I didn't have to make all the windows fullscreen to be usable. :) [09:57] * fullermd would be lost without his ffm... [09:58] 'course, I don't have to deal with gnomes or "globalmenu"en, whatever that is. [09:58] soren: happily I stopped liking focus follows mouse over a decade ago so I don't have that problem :) [09:59] fullermd: It's a plugin that takes the menu from your application and puts it at the top of the screen. Whichever window is active is the one whose menu shows at the top. [10:00] How odd. That would cover up my xbuffys... [10:00] fullermd: the twist compared to other global menus implementations is that most of the time the menu isn't shown === psynaptic is now known as psynaptic|sick [10:01] spiv: well, ffm to me, is a bit like tapping instead of clicking, I just move my mouse where I want the focus, I don't have to clik to confirm [10:02] a bit like: 'Are you sure you want to do that ?' , yes, don't ever ask again [10:02] Plus most clicky implementations autoraise the window too. Blech. [10:02] vila: you move the mouse to change focus? How inefficient ;) [10:02] (never mind the poor interaction with the icon manager...) [10:03] spiv: hehe, no, I also use other means [10:03] Oh, I'm sure he doesn't. Why bother with the mouse when he can just Ctrl-Meta-Q Hyper-Meta-N Ctrl-Top-Shift-X and *boom*, changed! [10:04] * Tak also <3 FFM [10:04] spiv: but since I share my keyboard and mouse bewteen two hosts, yes, switching from one to the other still requires moving the mouse [10:04] tsk tsk, switching from frame to frame and from buffers inside the frame (emacs window) is bind to... [10:04] M-TAB, what else ? [10:05] eerrrr [10:05] Ctrl-TAB [10:05] Six of one, half a dozen of the other. You just mash your hand down on the left side of the keyboard, it'll hit the right keys at some point. [10:07] bug 686161 looks like more failing-to-treat-paths-as-unicode fun [10:07] Launchpad bug 686161 in bzr (Ubuntu) "bzr crashed with UnicodeEncodeError in run()" [Undecided,New] https://launchpad.net/bugs/686161 [10:07] everybody loves shortcuts, but emacs *itself* only uses Ctrl and Meta, the others are free, I regularly check that I'm not overriding the emacs ones but only defines new ones (including using Hyper since Unity insists on using Super ;) [10:08] mgz: grr, str(thing) [10:08] mgz: hello by the way ! [10:08] hi! [10:09] the Conflict class doesn't even have a __unicode__ method [10:09] mgz: bah, did that even exist in these days ? [10:09] even though most/all the subclasses need to present paths to the ui [10:15] yeah... [10:16] wonder if I'll have some time this evening to write up some tests for the whole module. [10:17] Do you guys have any idea how long it takes to branch lp:linux? [10:17] mgz: that would be nice [10:18] soren: that will heavily depends on your bandwidth/latency, but well, don't expect miracles either [10:18] vila: hours? Days? [10:19] I'm 25 minutes in now. [10:19] right, time to leave [10:19] soren: 'bzr info -v lp:linux' should give you an idea [10:19] mgz: have fun ! [10:24] soren: Looking at the repo, it is about 500MB, probably less once it is all tightly packed in your local repository. [10:24] ah, missed one, make that 700MB [10:30] jam: "bzr branch" says it's copied 557803kB so far. "du linux/.bzr" says 252568. Which one of those must reach ~700MB before I'm done? :) [10:30] soren: the first, though it may go up a bit more that 700 [10:31] I wouldn't expect much more, though. [10:31] jam: No problem. I'm just trying to gauge the order of magnitude and whether I want to wait for it. [10:32] "675747kB 868kB/s / Fetching revisions:Inserting stream:Estimate 1879972/2512932" [10:32] hi jam, soren, mgz [10:32] maxb: thanks for all the ppa updates [10:32] o/ [10:32] should we update the topic now? [10:32] i think so === Topic unset by poolie on #bzr [10:32] sheesh [10:32] nice topic [10:33] :-) [10:33] poolie: hi === maxb changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | 2.4b1 is officially out (ppa:bzr/beta needs love) === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv [10:33] poolie: for bug 758164, if we are printing the filenames, and decoding to unicode, isn't that enough to explain the difference? [10:33] Launchpad bug 758164 in Bazaar "first status after add is slow" [High,Confirmed] https://launchpad.net/bugs/758164 [10:33] jam, it could very well be [10:33] Actually, bzr/beta still needs love [10:33] Your "very different" is 400ms vs 200ms [10:33] which yes, is 2x, but it is also only 200ms [10:33] indeed [10:34] poolie: I know we took pains to *not* decode utf-8 to Unicode for paths that don't appear modified [10:34] jam, i was going to profile it and see if anything stuck out [10:34] we almost need 'status -q' :) [10:34] but if everything is freshly added, we shouldn't be sha1-summing things (that would be more like 30s) [10:35] right [10:35] so it may be that formatting the file names is slower than it could be [10:35] well, almost certainly it could be made faster [10:35] but i don't know if it sticks out as something especially slow [10:39] poolie: utf-8 => unicode => utf-8 [10:39] would be something that sticks in my head [10:40] we like dealing with unicode in memory, but it does have a fair amount of overheda [10:40] overhead [10:40] heh [10:41] hmm, so I have a registry which return classes, but building objects require different parameters, what could be a tasteful way to design the __init__ methods and how could test provide parameters knowing that they'd like to refer to the test instance itself for that ? [10:42] example: a global config doesn't requires at most a transport object but a branch config requires a branch object [10:42] vila: "doesn't requires at most" ? [10:42] s/doesn't// [10:43] that's quite a sentence [10:43] hehe [10:44] ok, want me to split it ? (the point being that I can imagine solving both points separately but I'm still searching a combination that works well) [10:44] i guess generally speaking, provide a method or function that takes only the parameters the callers are likely to care about [10:44] for the __init__ ? [10:44] perhaps add either an adapter layer, or a separate class method, that will convert to the right constructor call [10:45] jam: Hmmmm... "1091782kB 520kB/s / Fetching revisions:Inserting stream:Estimate 1994478/2512932 [10:45] Still ~20% to go. [10:46] soren: and "du linux/.bzr" ? [10:46] 333440 linux/.bzr [10:46] right, but this route leads me to a test that needs to define a method which knows about the specific parameters OR a test method on the config class (bad) [10:47] hmm [10:48] ha, right, one test registry where specific adapters can be added [10:48] ok, i've disposed of about 70% of the ubuntu/bzr stuck bugs [10:48] the rest are now non-private [10:48] \o/ [10:48] i had a quick check for anything sensitive [10:48] https://bugs.launchpad.net/ubuntu/+source/bzr/+bugs?search=Search&field.status=New [10:49] many are dupes [10:49] of course [10:49] so that's most of what i've been doing [10:49] i wrote a little script to put the traceback attachemnte into the description- [10:49] poolie: and that's because you can now see the private ones right ? (I ~remember looking at the list but it was quite short) [10:49] that's right [10:50] great [10:52] If I CTRL-C my way out of a "bzr branch"... Can I resume it at a later time? [10:53] good night all [10:54] soren: unfortunately, no [10:54] if you start from scratch, you can do "bzr branch -r XXX; and then bzr pull -r YYY" etc. [10:57] soren: btw, do you know if you are going via http or bzr+ssh? [11:02] jelmer: question for you [11:02] '92745@138bc75d-0d04-0410-961f-82ee72b054a4:trunk%2Flibstdc%2B%2B-v3%2Ftestsuite%2Ftr1%2F4_metaprogra...' [11:03] is that a revision id from bzr-svn? [11:03] jam: bzr+ssh. [11:03] It is measuring ~ 158 characters [11:03] which is a *lot* longer than the standard 60char bzr revid [11:03] jam: It has transferred 1.6GB now. [11:04] soren, when it finishes, the final transfer amounts should all be in .bzr.log [11:04] you're welcome to submit a bug about this. 1.6 seems significantly excessive [11:04] I have thoughts as to why, but nothing very concrete. [11:04] jam: Will do. [11:09] jam: bug 758620 [11:09] Launchpad bug 758620 in Bazaar "branching transfers excessive amounts of data" [Undecided,New] https://launchpad.net/bugs/758620 [11:10] jam: question for you, I just tried 'bzr branch lp:linux' with bzr.dev and -Dhpss, and after 10 minutes it seems to still be issuing get_parent_map calls *only* alarmingly under-using my bandwidth [11:11] jam: could that be another fallout from querying tags first ? [11:11] soren: if you wait for it to finish, the summary of bytes transferred will be in bzr.log, It would be nice to get that in the bug report as well. [11:11] vila: into an existing repo, or into a new standalone branch? [11:12] jam: new repo [11:12] shared [11:12] but empty [11:12] jam: I'll do that once it finishes. If the average time per revision transferred holds, it'll be another 11 minutes. [11:12] also, the perfmeter shows little peaks every ~30 seconds... [11:13] vila: so into a shared-but-empty means we end up walking the whole history to find that you don't have anything we don't need to transfer. [11:13] jam: as if the smart server was... maybe loading the the ancestry graph to answer each query and being quite slow at that [11:13] >-/ [11:13] jam: a standalone branch would be better / [11:13] ? [11:13] vila: we have a special case in place for "target did not exist" [11:14] which is known deficient for "target exists but is empty" [11:14] ok [11:14] jam: That's a file id from bzr-svn [11:15] jelmer: k, still really-really big :) [11:15] I was debugging some loggerhead memory consumption [11:15] and 6MB for the intern dict ,+ 20MB of interned strings [11:15] jam: It looks like an old style one though, from bzr-svn < 0.6 [11:15] jelmer: it is the gcc-linaro repo [11:18] jam: bzr-svn parses the file id at the moment so this is tricky to solve easily [11:19] from looking at the code, it could indeed also be a new style file id [11:19] jelmer: it isn't critical at this point. but it is something that surprised me. [11:42] Is there a fast way to create a repository out of this mammoth branch (lp:linux)? I could just "bzr init-repo ." in its parent dir and do a "bzr branch linux linux2", but given the size of this, I was hoping there'd be a simpler way. [11:43] Err... Not necessarily simpler, but quicker. [11:43] Well, nothing will be really quicker. You can use 'reconfigure' to turn the existing branch into one using the shared repo. [11:43] Not necessarily quicker, but simpler ;) [11:44] ('course, a local 'branch' will be a putz of a lot quicker than going across the network, so it would certainly be 'quicker' in that sense) [11:45] I did it a couple of hours ago with lp:launchpad. It wasn't much faster than the initial bzr branch lp:launchpad, actually. [11:45] fullermd: bzr reconfigure --use-shared ? [11:45] Sounds like it, yah. [11:46] * soren awaits [11:46] Oh, lunch! [11:46] soren: touch .bzr/repository/shared-storage [11:46] it is now a shared repository [11:47] jam: So to make other branches share its data, I have to... what? [11:47] soren: create them underneath that dir [11:47] Oh. [11:47] What about its existing working dir? [11:47] soren: if you really want to relocate stuff, I would say: [11:47] bzr init-repo ../ [11:47] rm -rf ../.bzr/repository [11:47] mv .bzr/repository ../.bzr [11:48] Wicked. [11:48] Can I safely kill a "bzr reconfigure --use-shared [11:48] "? [11:48] soren: I think so [11:48] I'm pretty sure it just does a fetch [11:48] * soren takes a chance [11:49] Awesomesauce. Looks to have worked. [11:51] * jelmer is off to the dentist, back in ~1.5 hours or so [11:52] bzr actually just committed a changed file faster than git. [11:56] hey guys [11:57] if i make a cvs, svn or git checkout inside my bzr checkout - how do i make bzr not treat it with imports and all that stuff, just ignore the metadata? [11:57] I believe bzr by default will ignore metadata from most other VCSes [11:57] I've run mixed bzr + svn checkouts before [11:57] nah i did svn i think and it did that [11:58] i had to rm -rf all .svn dirs [11:58] Both bzr and svn have the ability to ignore files based on wildcard matches [11:58] is that the way to do it then? [11:58] bzr ignore .svn; svn setprop svn:ignore .bzr [11:58] or is it possible to turn off this importing stuff? [11:58] I don't know if that would prevent bzr-svn from noticing the .svn dirs, though... [11:58] Ahhh... That's an interesting one. Yes, you would have to disable the bzr-svn plugin [11:58] (or uninstall it or something) [11:59] even if the dirs are ignored? [11:59] ok i am now going to make a git checkout (ok clone) and will need bzr not to get confused by that [11:59] bzr ignore .git [11:59] Which I suspect it'll do by default [12:00] yeah but then i get bzr-git or something like that [12:00] and it will go crazy, no? [12:00] Hmm.. I'm not sure [12:00] same situation as peng mentioned [12:00] hmm hmm, I think foreign plugins detect the dor dirs before even thinking about .bzrignore [12:00] Without plugins, a mixed bzr+git checkout should be fine [12:00] what do you think Peng? what will happen? [12:00] I'm not sure how the bzr-git plugin will react in the presence of both sets of metadata [12:00] i hadn't installed any extra plugins but i don't know what is installed by default [12:01] how do you find out what plugins are installed? [12:01] Ideally, it'd be nice if you could disable plugins on a per-workdir basis [12:01] * Peng shrugs [12:01] cheater: "bzr plugins" [12:01] So just configure "Oi; bzr-svn, not now please" [12:01] but the foreign plugins are also intended to allow you to interact with foreign repos, not mix things into your working tree [12:01] hmm i did "bzr help topics" and "plugins" was not listed as a command [12:02] oh it's in "bzr help commands" [12:02] help topics just lists a few more things you might want to ask for help about; help commands lists all the commands [12:07] thanks [12:15] cheater: I would expect bzr-git to work fine with .git and .bzr in the same dir, because .bzr is probed first [12:15] however [12:16] bzr-svn and bzr-hg both put their probers before bzr [12:16] AIUI [12:16] and with bzr-svn if you were in a subdir, bzr wouldn't see the .bzr in the parent dir before bzr-svn saw .svn in the current dir [12:20] jam: my problem is that i don't want bzr-git to work at all [12:20] cheater: then why have it installed? [12:20] jam: i don't want any git integration stuff or anything, i just want it to be normal files to bzr [12:21] jam: i guess i don't have it installe [12:21] d [12:21] You can set "BZR_DISABLE_PLUGINS=git" I believe if you ever do have to have it installed but not working. [12:21] thanks [12:21] Ahhh cute [12:25] cheater: you can do similar things with bzr-svn, etc "BZR_DISABLE_PLUGINS=git:svn:..." [12:26] cool :) [12:26] thank you jam [12:45] aaaargh, noooo not *now*: bzr: ERROR: exceptions.AttributeError: 'LoomMetaTree' object has no attribute 'inventory' [12:46] jelmer: ^ :-/ [12:48] pfew, reverting to revno 578-0 indeed worked [13:05] jelmer: I filed bug #758696 [13:05] Launchpad bug 758696 in Bazaar "bzr.dev revno 5781 or 5782 broke bzr-loom (needs .inventory)" [High,Confirmed] https://launchpad.net/bugs/758696 [13:11]