[00:38] morning all [00:42] hi Ian [00:42] lifeless: it looks ok, but it seems like the check patch is significantly changeed, not just polished? [00:43] hi jelmer. Thanks that your reviews over the weekend. Much appreciated [00:43] morning lifeless [00:44] igc: svn-keywords is already partially working :-) [00:44] jelmer: I'm actually keen to get bzr-keywords into the core as well, so you can assume that code is there and build on it [00:45] jelmer: now that the fallback bit is in place, you'll only need to register how to expand the keywords I think [00:45] jelmer: and you get the sweet publishing features in bzr-keywords for free as well [00:46] next weekend maybe :-) [00:47] jelmer: saw my feedback for svn / dpush ? [00:47] stbuehler: hi [00:47] stbuehler: where? [00:47] (I haven't seen anything yet) [00:48] jelmer: just wanted to give some feedback: bzr dpush does *not* give you the svn-revisions back, even if you had new commits pushed to upstream svn [00:49] perhaps that works if you never used the normal push, didn't try that [00:49] seems like i cannot force bzr to rebase to the svn branch [00:50] stbuehler: no, it doesn't as that would require changing existing revisions; we can keep a map though and display that sort of information [00:51] jelmer: yes, 0.9.5 to 0.9.6 added a special linker script [00:51] i wouldn't mind changing them, if it where an option :) [00:52] stbuehler: can you please file a bug report about this? I'll try to get it fixed for the next version [00:53] jelmer: so dpush should change existing revisions? k, let me try :) [00:54] stbuehler: yeah, dpush basically pushes all revisions into the remote repository [00:55] stbuehler: and then fetches the revisions that were created remotely and overwrites the local revisions with them [00:58] stbuehler: push (by definition) only changes the remote revision [00:58] s/revision/branch/ [00:59] yes, that is perfectly valid :) [01:02] jelmer: the 0.9.6 patch is polish from the subunit point of view, its just updating against the check project [01:18] stbuehler: oh, maybe I misunderstood [01:18] stbuehler: dpush won't change any previously "bzr push"'ed revisions of course [01:19] it only affects revisions not yet in svn in any form [01:23] i mentioned i "dpush"ed new commits, which were not in svn [01:23] but maybe it only works if you never used "push" [01:24] stbuehler: sorry [01:25] stbuehler: it should work fine if older revisions were pushed [01:25] stbuehler: is this repo public? [01:25] svn://svn.lighttpd.net/spawn-fcgi/trunk [01:26] thanks [01:28] stbuehler: ok, I figured out what's happening, this shouldn't be too hard to fix [01:47] lifeless: btw, I hope to split out libtorture from samba at some point [01:48] so we can use that in bitlbee, ctrlproxy, etc in favor of libcheck [01:48] jelmer: thats your C testing infrastructure? [01:48] lifeless: yep [01:48] it already does subunit [01:48] jelmer: I'd be inclined to put patches into libcheck, the fork isolation really is nice [01:49] lifeless: is there any chance of your subunit patch actually making it into libcheck? [01:49] jelmer: yes [01:50] I've resubmitted it, chris pickett has ack'd that they were being overly nitpicky [01:51] hmm [01:54] entry point to the recent dicussion http://sourceforge.net/mailarchive/message.php?msg_name=1235597368.24285.63.camel%40lifeless-64 [01:54] its a terrible list archive ui [01:59] ah, cool [02:24] bleh, sf svn is still slow :-( [02:24] lifeless: you are using bzr-svn for check development, right ? >-) [02:24] jelmer: yes, do you want me to push trunk in bzr format somewhere? [02:25] lifeless: yes, if it's not too much trouble [02:25] sure thing [02:26] I can do a pull myself, but it looks like it's going to take at least 30 min at this rate.. [02:27] there is a https://code.edge.launchpad.net/~vcs-imports/check/trunk :) [02:28] lifeless: except that imports from CVS, and hasn't been updated since 2005 :-) [02:29] heh. we should redirect it then :) . bzr+ssh://bazaar.launchpad.net/%7Elifeless/check/svn [02:29] pushing my subunit branch now [02:30] lifeless: thanks [02:32] jelmer: bzr+ssh://bazaar.launchpad.net/~lifeless/check/subunit [02:34] got it [02:34] did launchpad just upgrade to 1.13 or something? [02:34] not for 2 more days [02:35] it's too freakishly fast all of a sudden [02:38] Last week bzr.dev got a fix for a performance bug when pushing to pre-1.13 servers, maybe it's that? [02:38] I think jelmer was pulling :) [02:39] well, pushing was the main thing that got faster [02:39] I pushed a 130Mb repo to lp in < 1m [02:42] that would be spiv's fix [02:45] :) [03:25] lunch, back soon [03:42] lifeless: the only subunit branch up for review I see is https://code.edge.launchpad.net/~radix/subunit/report-errors-better/+merge/4292 [03:42] jml: jelmer reviewed the polish branch [03:42] oh cool. === timchen1` is now known as nasloc__ [04:02] jml: if you didn't get notice about the subunit branch, are you subscribed appropriately to trunk ? [04:25] lifeless: what would cause a knit to become corrupt and raise SHA1KnitCorrupt when calling show_log? [04:26] an actual knit? [04:26] or something in a pack? [04:30] thumper: ^ [04:34] hi folks. is it posible configure bzr with emacs to commit comments? [04:43] ovnicraft: recent emacs has vc-bzr built in [04:47] * igc lunch [04:52] bob2, yep i got it thx [04:57] igc, hi [04:58] I was looking at your mergeline cache RFC supersede your plugin? [05:01] tracked down the commit failure [05:02] [bah] [05:25] hi beuno [05:31] hey igc [05:32] how are you? [05:33] beuno: flat out - trying hard to make our next-gen the best it can be [05:34] beuno: no, it doesn't supercede it - it helps it though [05:34] igc, I've seen. It's impressive work [05:35] ok, good, because I was about to spend the weekend working on loggerhead + your plugin to get them working well together [05:35] beuno: there's still a need for caching the full history to make log *really* fast - that the revnocache [05:35] I obviously got sidetracked by RL, but was very clse :) [05:35] *cloase [05:35] the mergeline case helps *one* special but importasnt case - lookup of a single non-mainline revno [05:35] hotcha [05:36] (typing sucking) === abentley1 is now known as abentley [05:36] I see [05:36] brisbane-core is going to rock... [05:37] Hmm. Is there some reason it can't help in other cases? [05:37] igc: a 22K file is quite a lot of data to be updating on push/pull over the wire... I'm inclined to react cautiously and suggest taking the revnocache approach [05:38] I can see that it wouldn't save you any total time on log (since you pull all the info anyway), but wouldn't it let you number and start displaying more quickly? [05:39] lifeless: it doesn't get updated on push or pull [05:39] lifeless: only the first time log is used on that remote branch [05:57] hi [06:00] igc: I don't get the connection between my ocmment and your reply :) [06:03] May i use BZR with any kind of files? [06:04] lifeless: log, status and diff are read operations [06:05] you suggested not updating files during them [06:05] bzr currently maintains an embargo against Cuban and North Korean files... [06:05] I'm saying "that's the whole basis of the design" [06:05] I'm now updating the mergeline-store file *outside* the read transaction [06:06] so I think it's safe [06:06] given I check the data is still current before saving it [06:06] and lack of data there is handled without a drama [06:06] lifeless: make more sense now? [06:07] lifeless: and sorry if the reply wasc rushed - I'm tired today :-( [06:07] s/wasc/was/ [06:10] igc: well, its clearly vulnerable to race conditions [06:11] * fullermd is somewhat uncomfortable on principle with the idea of 'log' writing stuff... [06:11] igc: I assume I'm not understanding the cache, and I'm really concerned that this is being rushed into - we have only this week to freeze the bbc format, if I remember the dates [06:13] lifeless: right. fwiw, I'm not doing anything that couldn't work on bzr.dev now - it's not tied to brisbane-core though I'm ok with doing that [06:13] igc: this isn't clearly correct, and has serious potentially serious issues as all caches do. [06:14] not to mention that writing during a read operation is simply impossible on e.g. http:// urls, so its entirely useless there [06:14] Are serious potentially trivial issues more or less hazardous than trivial potentially serious issues? [06:14] lifeless: true. But the important case if local so we could easily restrict it to that [06:14] s/if/is/ [06:14] and remove any network concerns [06:15] igc: I'm finding the discussion hard, it feels like you're presenting this as all-or-nothing, and already-analysed-this-is-right, rather than engaging [06:15] lifeless: sorry - I'm not meaning to come across like that [06:16] lifeless: and I'm very interested in how you think it's subject to race conditions and/or ought to proceed [06:16] igc: so as a design principle we are trying to remove all our caches [06:17] for instance, one possible cache that was proposed as an alternative to brisbane-core was to cache inventory deltass in commit objects [06:17] we successfully avoided that while still getting good performance [06:17] which means we get good performance on arbitrary tree deltas rather than only on adjacent ones [06:18] lifeless: really? That's sounds crazy. Caches are necessarily bad. Even bash has them :-) [06:18] s/are/aren't/ [06:19] Stanlin: yes [06:19] for this case, I'm interested in: what the root problem is. (is it revnos? is it index performance? something else?) I'm interested in why the operations are faster *overall* with this - what work is it actually saving, and why [06:20] igc: caches increase data storage, add the opportunity for bugs relateed to coherency, increase writes needed and can often reduce performance overall [06:20] bob2: including graphics and big files?? [06:21] Stanlin: It will _work_ for them (mod performance or memory issues with large files, anyway). Whether it's particularly _useful_ depends on your situation. [06:22] fullermd: awesome, ok so i can go ahead and use bzr for all my desktop [06:23] If any files are a significant fraction of your available physical memory (ISO's and the like are common offenders), you're likely to hit some unpleasantness. [06:23] And of course a number of operations (like merging) are a lot less useful with binary files. [06:23] fullermd: well for starters i just want to do it with small documents [06:24] fullermd: what is the best scenario to , use bzr, as server, and lets all users push and pull, without editors or any control? [06:25] igc: so we really want caches where they really appear to be the best answer, not the first answer. [06:26] Stanlin: That's way too broad a question to answer in general :) [06:26] igc: and this one, given the data I have so far, appears to be the first answer with none of the deep questions answered [06:26] Stanlin: Very dependant on exactly what your situation is. [06:27] is bzr superior to Git? [06:27] igc: I may well be wrong and have missed the guts of the analysis [06:27] Stanlin: we think so :) [06:27] Yes and No and See Me Next Tuesday. [06:27] gnight all :D [06:29] woo, faster commit landing [06:30] * Stanlin performs aptitude remove git [06:35] lifeless: it's very early days w.r.t the mergeline cache. It works but that doesn't make it the answer. Please don't reject it on principle though. From *my* analysis, it's the smallest amount of data needed to make some selected use cases perform well. I done lots in work in recent months on stuff like revnocache and this is the only part of that plugin that I've ever thought should go in the core [06:35] And if it's not core-worthy, it will go into revnocache instead [06:36] igc: I won't reject it on principle; but to put it in core I would want those deeper questions considered [06:36] lifeless: sure, and I have considered cache currency in the design already, for example [06:37] I need to head off; day is done and all [06:37] http://pqm.bazaar-vcs.org/ [06:37] record-iter-changes commit - landing now [06:38] lifeless: well done and thanks no the commit stuff [06:38] s/no/on/ [06:39] and for playing devil's advocate :-) [06:40] FWIW, I agree in principle too... [06:40] I'd rather see fixable performance issues fixed (even if rather later) than papered over. [06:40] Once papered over, fixes tend to get pushed back a long ways, and even when made, the papering often remains messing things up worse :| [06:41] (this of course expresses no opinion whatsoever on where the current questions falls on that spectrum, since that's all the opinion I'm qualified to express...) [06:43] fullermd: we currently cache the last revno and last-rev-id for the mainline [06:43] igc: revno is a cache, last-rev-id isn't [06:43] :) [06:43] * lifeless goes [06:44] fullermd: all I'm doing is extending the idea to each "mergeline" so finding a rev-id for x.y.z doesn't require a full graph build [06:45] igc: Convincing me of the fitness or lack thereof of some internal mechanism is kinda wasted effort ;) [06:47] I have pro and con feelings on the issue, but considering how drastically uninformed they are compared to anybody else you talk to about it... [06:51] fullermd: thanks for the tip. I was being polite and offering an explanation in case you cared :-) [06:54] Oh, I do appreciate that. It's why I'm here and occasionally even pay attention 8-} [06:55] Just that pretty much any insight or judgement that might occur to me, lifeless already thought of 20 minutes before I read any descriptions, and either already brought up or mentally discarded as absurd. [07:41] hi all [07:42] Good morning. [07:43] hi vila [08:09] can someone tell me the difference between 1.13 and 1.13.1? [08:09] will it matter server side? [08:09] should LP use 1.13 or 1.13.1? [08:17] thumper: Look at the announcement: 1.13.1 fixes a version number mismatch in bzr vs. bzrlib, fixes an error in NEWS (I think), fixes 'merge --force', and bzr-1.13.tar.gz didn't include the Pyrex-generated C files. Does any of that matter for LP? [08:18] thumper: If LP doesn't use "bzr", doesn't use "bzr --force" and has Pyrex installed on the build machine or doesn't use the tarball in the first place, I guess it doesn't really matter. [08:26] Peng_: thanks, I think LP will stick with 1.13 [08:26] :) [08:27] Err, "bzr merge --force", I meant.. [09:03] thumper: I agree with Peng_'s assessment. Also, we write the NEWS file for a reason ;) [09:03] spiv: don't expect people to actually read NEWS, geez [09:03] spiv: what makes you think I have a copy of trunk? [09:05] thumper: Well, I'm reasonably sure you have a tool to browse files in branches online [09:06] thumper: but also the relevant parts of NEWS are sent in each release announcement [09:06] spiv: geez, why all this reading when someone can just ask :P [09:07] thumper: of course, http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/head:/NEWS would be even better if LP didn't time out trying to render it ;) [09:07] thumper: when you ask, all I do is go and read that file [09:07] thumper: so you might as well cut out the middle man :) [09:07] spiv: and save me the trouble :) === serg_ is now known as serg === AnMaster_ is now known as AnMaster [12:09] Greetings. A general question. I have a project where parts of it are customized files for the end customer - e.g. web pages, set up files, theme files etc... [12:09] I want to maintain these branches in parallel for the long term. Is there a way to make this easier, i.e. to ensure that some changes in a branch never get pushed to the parent? [12:10] The other approach would be to treat all the customer specific files as a separate project under source control. [12:10] But bzr doesn't seem to handle related sub-projects yet - unless that has change since I last checked? [12:26] VSpike: got the same problem with 3 différent environments. [12:26] I use 3 differents branches [12:26] And I never use pull nor push [12:26] but only merge [12:27] That should work just great [12:38] yogsototh: do you mean that you never make code changes in the child branches that need go back to parent? === beuno_ is now known as beuno === ja1 is now known as jam [13:20] Apologies if I'm asking the obvious - but I can't find it in the docs. Is there any way of finding out the common ancestor a merge command is using? [13:21] (I'm kinda new to bzr - but been using baz for a long while, trying to make the switch!) [13:21] joie: bzr find-merge-base [13:22] joie: found in 'bzr help hidden-commands' [13:22] Ahhah - sounds like a useful thing to know - thanks! [13:23] I'm essentially trying to do the equivalent of a baz apply-delta to put all the work from one branch onto my working branch, and want to be sure that merge is doing the "right" thing! [13:43] jelmer: hey, thanks, I was just about to take another look at bzr 1.13.1 and I saw the ACCEPTED mail. [13:56] james_w: it turned out there was a bug in the python2.6 package in experimental that I had instlaled [13:56] james_w: uninstalling it made the problem go away === thunderstruck is now known as gnomefreak [14:05] jelmer: hello [14:13] night all [14:18] igc, just got your email. The reason I emailed you back with the link was because I don't have time to do this right now. [14:32] what's this mean: Unable to contact DBus session: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed. [14:36] liw: bzr-dbus was unable to contact your local DBus [14:37] liw: while attempting to signal that a new commit was made / branch was updated [14:39] ok. why is dbus being contacted? I'm not running under X for that command (ssh into the machine; there is an open X session in the console, though) [15:14] liw: you have bzr-dbus installed probably [15:14] liw: newer versions of bzr-dbus will not show any error / output if it fails [15:22] jelmer, ok, then I'll just ignore it, thanks [15:34] vila: just a quick question, if you managed to fix the duplicate "CHKInventory" stuff. [15:35] ajmitch: yu[ [15:35] ajmitch: sorry wrong target [15:35] jam: yes ? [15:36] vila: ?? or 'yes' :) [15:36] jam: I pushed --overwrite on vilajam [15:36] jam: 'just quick question, if' I was waiting for the question :) [15:41] jam: the fix may not be the cleanest one (you can still find the duplicate in a couple of revisions if you dig enough), but I think it's "good enough" [15:49] Is there an existing plugin or other method for creating a default template for commit text? [15:50] meuserj: there's no plugin yet, but there is a hook you can use if you're going to write such a plugin [15:55] jam: in gc, _compress last returned value is length, documented as 'number of bytes accumulated in the group output so far' but the code seems to calculate the delta length instead [15:56] vila: it seems to be used only in _insert_record_stream and even there that seems like a left over [16:03] vila: so the return is currently (sha1, start_of_record, end_of_record, kind, length_of_record) [16:03] the last part is obviously redundant with end_of_record - start_of_record [16:04] jam: not so obviously :-) but thanks for confirming, it's not always the case for the python impl. but if the semantic is correct, I'll just delete it [16:05] jam: can I get also get rid of the last_fulltext_len in _insert_record_stream ? [16:07] vila: sure, I think there was something about returning the size of the fulltext that was being compressed, etc [16:07] I would probably just get rid of 'length' [16:07] (evolving interfaces :) [16:08] jam: ok, doing it right now [16:08] so stuff like last_fulltext_len was meant as a possible way to play with varying the compression decisions [16:09] I can 1) get rid of it as well as length, 2) keep it and update it with end - start [16:10] vila: We can always bring it back if we decide we want to use it [16:10] for now, cleaner code is probably better for landing in bzr.dev [16:10] ok [16:22] jam: hi [16:22] jam: How do I create a branch5 format programmatically? [16:31] jelmer: in a test suite or just from bzrlib? [16:32] jam: in a testsuite [16:33] for other branch formats I can use ._matchingbzrdir [16:33] jelmer: self.make_branch('dirstate' [16:33] would probably be fine [16:33] at least that was the last one to use Branch5 [16:33] if you need more control than that, then I can go through it [16:34] (that will be a knit format repo, with a branch5 branch) [16:34] jam: is there any way to obtain that from a BranchFormat instance? [16:34] jelmer: are you saying you need the name of the format? [16:35] jam: I have a BranchFormat instance (BzrBranchFormat5) and need to create a branch that uses it [16:35] bzrlib.branch.BranchFormat5.initialize() [16:35] preferably as generic as possible, without special casing BzrBranchFormat5 [16:35] This is for the InterBranch tests [16:35] jelmer: my_format.initialiaze(a_bzrdir) ? [16:35] my_format.initialize(a_bzrdir) ? [16:35] jam: but in that case what format can a_bzrdir have? [16:36] jelmer: there is only 1 'metadir' bzrdir format [16:36] can I use a BranchFormat5 with a recent repo format? [16:36] jelmer: yes [16:36] it will "work" we just don't give you a way to specify that with a short name from 'init' [16:36] ah, neat, I wasn't aware of that [17:14] vila: so where are you at? I haven't seen your commit showing up yet :) [17:15] I tracked down the unicode symlinks error back to bzr.dev@4216 :-/ [17:15] Can you run ./bzr selftest -s bt.branch_implementations.test_sprout.TestSprout.test_sprout_with_unicode_symlink in your bzr trunk ? [17:18] jam: ^ ? [17:19] vila: currently on win32, I'm sure it will pass just fine :) [17:19] jam: lol, yeah, but I don't understand how pqm let it pass [17:21] vila: on my server, that test fails about 5 times [17:21] 'ascii' codec can't decode byte 0xce [17:21] yup, that one [17:21] with or without the dirstate pyrex extensions? [17:21] jelmer: both [17:21] jelmer: both [17:22] vila: maybe a python2.4 issue? [17:22] revno 4215 succeeds, 4216 fails [17:22] just reproduced it with 2.4 too 8-/ [17:26] vila: so I could see where 'iter_changes' is accidentally using 8-bit symlink_target rather than unicode, but yeah, I don't see how pqm didn't fail just like us [17:28] UnicodeFilenameFeature not available on pqm ? [17:28] vila: certainly possible, I don't know [17:28] actually, probably likely [17:28] try setting LANG=fr [17:28] or something [17:28] rather than fr.UTF-8 [17:29] EMYOSDOESNTSPEAKFRANCAIS :) [17:29] LANG=en_US.UTF-8 [17:29] always [17:30] :) [17:30] so LANG=en_US then :) [17:30] vila: yeah, it passed with a skip here [17:30] yup, tests are skipped in that case [17:32] crap [17:33] jam: by the way, I pushed my last changes at vilajam [17:34] jam: you may want to pull --overwrite from there though [17:34] jam: I mean, I you keep a mirror of that one [17:34] jam: I mean, IFF you keep a mirror of that one === solarion_ is now known as Solarion [17:36] vila: well, I'm a bit saddened that you keep '--overwrite'ing all of my branches. You pushed up your history for brisbane-core, and vilajam... [17:37] jam: ?? I try to respect the mainline most of the time, but here you had committed *on top* of the error, so I tried to get rid of the problem as best as I can :-/ [17:39] jam: I tried alternate ways to fix it, but most of them ended up with the wrong annotation for both CHKInventory and CHKInventoryDirectory (all the lines were attributed to *me*), at least now the attributions are correct and your revisions still present [17:40] not a big deal, really [17:40] I was just surprised to see both mainlines changing to "merged bbc@" especially since it was the bbc trunk [17:40] I thought correct annotations were more important than revision history :-/ [17:41] vila: personally I use "bzr log" about 20x more than "bzr annotate", but as I said, in another week I won't even notice [17:41] jam: and yes, the way I rebuilt my loom wasn't the clearest either :-/ [17:42] jam: on the other hand, may be you should push to jamvila :) [17:43] :) [17:51] does bzr use sha1 behind the scenes? [17:52] yes === davidstrauss is now known as davidstrau === davidstrau is now known as davidstrauss === jfroy_ is now known as jfroy [18:24] heh, python is going to use mercurual [18:28] luks, its official? [18:28] luks, link? [18:28] http://mail.python.org/pipermail/python-dev/2009-March/087931.html === jszakmeister is now known as jszakmeister|awa === jszakmeister|awa is now known as jszakmeister [18:44] yep, it's official. [18:47] That sucks :( [18:47] bzr rocks [18:48] * jszakmeister agrees [18:48] Is there an announcement or anything? [18:48] It probably boiled down to performance... the email is a little vague, but I agree... a decision needed to be made [18:49] luks put the url in IRC [18:58] but bzr is fast now :( [19:06] that is the joy of open source, you are free to choose amongst many good choices [19:08] I can't wait until Launchpad supports git and mercurial imports [19:09] is the code for launchpad avaliable somewhere already? [19:09] santagada, You might want to ask in #launchpad - this is #bzr [19:09] and each choice typically tries its best to make switching between choices as painless as possible [19:09] cody-somerville: soon! [19:09] for git [19:09] cody-somerville: no one here knows? I would supose it is pretty important [19:10] santagada, Why? [19:10] mwhudson_, :) [19:12] when I pack, can I delete everything in .bzr/repository/obsolete_packs/? [19:12] antoranz, in general, yes === beuno_ is now known as beuno [19:12] ok [19:19] hi guys, in which time igc (Ian) will be here? [19:20] bialix, I'd say in about 3 hours or so [19:20] thanks. perhaps too late for me [19:21] why doesn't it cleanup obsolete packs? [19:22] igc: I'd like to talk about eol labels and strategies with you tomorrow morning (~ 6-8 am UTC). OK? [19:22] BFrank, I don't know all the details, but it mostly has to do to ensure that we don't run into data loss [19:22] hmm [19:22] igc: I'll be there tomorrow. [19:22] BFrank, there are some crazy scenarios where that happens [19:22] when exactly does it cleanup the obsolote packs? [19:22] shouldn't there be a point when it is safe for bazaar to clean them up? [19:23] it cleans them up before writing any more [19:23] so next time it does a "pack" operation it first removes the obsolete ones [19:24] shouldn't it cleanup for other types of operations, where it won't create new ones? [19:24] or do all operations create them? [19:24] no, just the ones you would expect [19:24] commit, pull, pack, merge, push into, etc. === mwhudson_ is now known as mwhudson [19:25] hmm [19:25] what tool can I use to import a git repository into bzr? [19:26] antoranz: bzr-git or bzr-fastimport [19:26] ok [19:31] antoranz: the latter is probably more robust at this point, but bzr-git is moving fast [19:31] ok [19:32] mwhudson: moin [19:32] jelmer: hi [19:32] mwhudson: my git import now works on lp btw [19:32] jelmer: yes, i saw that [19:32] jelmer: did you find out what was going on when it was just showing 1000 revs? === beuno_ is now known as beuno [19:33] mwhudson: yes, I had only pushed 1000 revisions (bzr push -r1000) :-) [19:33] jelmer: hahahaha [19:49] jelmer: so if i wanted to make a bzr-svn import of pypy, what would i have to do? [19:49] jelmer: i remember you saying that i could probably hack something to ignore certain errors === mtaylor_ is now known as mtaylor [19:57] mwhudson: ah, yeah [19:57] mwhudson: when it calls get_dir() [19:57] you have to ignore 157002 errors [20:15] jelmer: alternatively [20:15] if i dump the repo, filter out the offending fileprops, recreate it locally [20:15] do the import from my local repo, will it be possible to update the import from codespeak? [20:16] mwhudson: yes [20:21] jelmer: awesome [20:21] jelmer: do you happen to know how to filter a dumpfile? [20:25] mwhudson: vi ? :-) [20:25] jelmer: heh [20:28] so i've got a meeting this afternoon about revising my group's code review practice, which currently consists of all devs (4-6 of them) sitting around a table and scrolling through one big diff that's getting deployed [20:28] wondering if anyone else using bazaar in a dev group can talk about what they do for code review? [20:29] we're hoping to move toward peer-review where one other dev signs off on each commit to trunk [20:33]