=== medberry is now known as med_out [00:23] hbeck: yes, checkout and update would do just fine [00:23] hbeck: the other approach that springs to mind is the bzr-upload plugin, if the 'download' directory isn't local it may be more suitable [00:26] spiv: download is local. I'm trying to understand the difference (in the case of a checkout) between update and pull [00:30] hbeck: if you haven't made any commits locally, then none. [00:32] spiv: so bzr pull $MASTER == bzr update (in that case, no local commits) [00:37] Oh, actually, the other difference is that 'pull' brings a branch up to date with another branch (the parent branch by default), whereas 'update' just brings your working tree up to date with the checkout's master branch. [00:38] * spiv should go get a coffee [00:38] so pull is both read/write? [00:38] read (to local) and write (to master) [00:38] probably bad terminology [00:38] Yes, bad terminology :) [00:39] As the help says, “Turn this branch into a mirror of another branch.” For a checkout, “this” branch is the one you have checked out. [00:41] parent vs master is confusing [00:41] (if you look at the 'bzr info' output, it'll say “checkout of branch”) [00:43] Parent is, by default, where someone “bzr branch”ed from. And the parent is used as the default location for pull and merge IIRC. [00:44] after ‘bzr merge’, I can use ‘bzr status -v’ to see the summary lines of all merged revisions. [00:45] When people say master in bzr they mean the branch you made a “bzr checkout” of. [00:45] how can I see the equivalent of ‘bzr log’ or ‘bzr log -v’ on those revisions? [00:45] in other words, the full commit message, and optionally the list of file changes. [00:46] alternatively, is there an option for ‘bzr commit’ that will let me work from the commit messages of all pending merged revisions? [00:46] so I can summarise them in the commit message for the merge. [00:48] bignose: I'm not sure of a good builtin way. 'bzr qlog' from qbzr happily shows you those revisions, but I don't think 'bzr viz' from bzr-gtk does. [00:50] The easiest way possibly is to commit; then look at the log; then uncommit and then do the commit properly :/ [00:52] A crude way would be to do 'head -4 .bzr/checkout/dirstate | tail -1 | cat -v', then take the second revid on that line, and run 'bzr log -v r-1..$that_revid' [00:54] jelmer: lp:~jelmer/bzr/standard-annotate-interface has renamed file '.bzrignore' => '.bzrignore.moved in it [00:59] another newbie question: what happens if you bzr update to a rev earlier than what your local checkout is at? [01:02] bignose: as a one-line hack: bzr log -r -1..`head -4 .bzr/checkout/dirstate | tail -1 | xargs -n1 -0 echo 2> /dev/null | head -3 | tail -1` [01:03] We really ought to provide a revisionspec for this stuff. “pendingmerge” I guess. [01:04] hbeck: it will "update" the working tree to that earlier rev (if you have a reasonably current version of bzr) [01:05] spiv: would that be the same as pull -r rev# --overwrite ? [01:09] No, pull would modify the branch as well as your checkout of the branch. [01:10] ack, so that would be very bad, in the case of having some master repo and I just wanted to go back to an older rev to build - pull would in effect revert the repo? [01:10] Yes. [01:12] (Terminology note: we'd say “branch” there, not “repo”. We have repositories, but they are basically just containers for revisions, optionally shared between branches. It's branches that keep track of what the current revision is.) [01:13] noted :) [01:20] spiv: given that behavior of pull, I'm a bit confused as to its intended utility? "a mirror of another branch" suggests that only the "this" branch would be changed [01:29] hbeck: yes, that's right. I'm not sure where the confusion is? [01:29] pull modifies the destination, not the source (complement of push) [01:30] hbeck: typically you'd use it like "bzr branch URL my-mirror-of-URL", then later "cd my-mirror-of-URL; bzr pull" to keep that mirror up to date. [01:31] hbeck: e.g. if you are frequently working with the trunk of some project hosted on the internet you'll probably prefer to have a local copy of that trunk to work with, for speed. Pull keeps that copy current. [01:31] ok, I thought you said that if I did "cd my-mirror; bzr pull -r oldrev --overwrite" that it would move both my-mirror and the URL itself back to oldrev [01:32] I think he was talking about doing pull from a checkout (in which case there's only 1 branch to influence) [01:32] If my-mirror is a *checkout*, rather than a branch [01:32] Then the branch pull modifies is the checkout's branch. [01:33] ah. AH. [01:33] lightbulb [01:35] so... "bzr co URL dldir; cd dldir; bzr pull -r oldrev --overwrite" changes the branch (in the checkout) in dldir but not out in URL-land. [01:36] do I have that right finally? [01:36] Other way around. [01:36] (and you may need another arg on the pull, but that's irrelevant really) [01:36] Think of it this way; you have a branch 'master' (probably bzr+ssh://something or the like) [01:36] You want to work locally in 'mywork'. [01:36] You can: [01:37] 1) bzr branch master mywork [01:37] Now you have two branches; the existing 'master', and the new 'mywork' based on [the current state of] master. [01:37] You use 'bzr pull' in mywork to drag in new stuff from master (assuming you're not adding new revs locally of course) [01:37] or, [01:37] 2) bzr co master mywork [01:38] Now you still only have _one_ branch; 'master'. 'mywork' isn't a branch, it's just a new working tree on the existing 'master' branch. [01:38] You'd use 'update' to "catch up" the tree when 'master' moves ahead. [01:38] 'pull' is for copying revs from one branch to another. 'update' is for catching up the working tree to its branch. [01:39] (of course, both can be used with '-r' to go backward instead of forward, but that doesn't change the basic difference; pull is for updating branches, update is for updating working trees) [01:40] If you ran 'bzr up' in mywork in case (1), you'd be updating the 'mywork' working tree to match its branch, which is also 'mywork'; it contains both in that case. So it's usually going to be unnecessary, since you're not going to 'move' the branch forward or backward other than by going through the tree already. [01:41] IF you run 'bzr pull' in mywork in case (2), you'd be asking bzr to update the branch 'master' (that being the only branch existing) to match its parent, wherever that may (or may not) be. [01:41] * fullermd wanders off into further confusing details... [01:41] chewing on that... [01:43] I am working with a build system, it has a fetcher that will grab stuff using bzr. Currently it is written to do this: [01:43] 1) does the thing to fetch already exist? if no, checkout [01:44] if yes, pull --overwrite [01:44] with a revision specified by a recipe in the build system [01:44] which could be behind the current rev of the 'master' branch location [01:45] this stuff that is fetched is not a work area, it is just to download and build from [01:45] so it seems like checkout/update is appropriate. [01:45] ? [01:46] I'd probably tend to use branch/pull. But in this case it's probably 6.5 of one, half a baker's dozen of the other. [01:47] But doing checkout/pull is certainly not what you want :) [01:47] why? (for my own edification in all these confusing details) [01:47] to the branch/pull tendency [01:48] Well, I generally only go to 'checkout' when I intend to work on and commit stuff directly to 'master'. [01:48] I use 'branch' for readonly/reference/etc copies. [01:48] To some extent, that's just mental philosophy. [01:48] OTOH, it does give you a little extra safety, since your mywork is nearly completely decoupled from master. [01:49] If you accidentally pull or commit or whatever in it, it doesn't do anything to master. [01:49] You'd have to actually explicitly do something like push. Whereas with the checkout (assuming you can write to master), commits or pulls or the like will end up doing stuff to master. [01:51] ok, that last bit is where I'm confused (pull doing stuff to master, referring to master being the 'master' branch location and mywork being a checkout) [01:51] if I did bzr co master mywork [01:51] I think calling it the "master branch" in reference to a checkout is just confusing. It's just the _branch_. [01:52] There's only one, so anything that writes stuff to a branch (like pull, or commit) writes it there, because that's the only branch there is. [01:53] bzr pull -r oldrev --overwrite master (from mywork dir) [01:53] that moves mywork back to oldrev [01:53] and the master (off on some other machine) is not changed [01:54] That moves the _branch_ for mywork back to oldrev. [01:54] If you did 'bzr branch master mywork', then mywork is its own branch, and master is unchanged. [01:54] If you did 'bzr co master mywork', then mywork is _not_ its own branch, it's just a working tree on master. So the branch you're changing is master. [01:54] * hbeck head explodes [01:54] * fullermd grabs some duct tape. [01:55] while we've been talking, i tried this. [01:55] bzr co master mywork [01:55] hbeck: the really short version is: "if you have a checkout, use update. If you have a branch, use pull." [01:56] bzr pull -r oldrev --overwrite (which fails due to lack of pull location) [01:56] so then I did bzr pull -r oldrev --overwrite master [01:57] which worked exactly like I thought bzr update -r oldrev should [01:57] and our server-hosted stuff is happy and safe [01:57] hbeck: 'bzr log -d master' will now show that master is at oldrev too. Is that what you want? [01:58] negative spiv, I went over to the master location and it's still at the current rev [01:59] That would be one of those 'bound-branch-screwing-things-up" bugs... [01:59] fullermd: yeah [02:00] * fullermd clears his throat to do that grumble-dance again. [02:00] hbeck: well, it appears it does work, but personally I find that confusing :) [02:01] yeah [02:01] it is [02:01] extremely [02:01] Anyway. You shouldn't rely on that, because it's a bug/wart/implementational-detail that may (will, hopefully) change. You'll see different behavior if you used a lightweight checkout, for instance. [02:01] hbeck: and unlike "bzr update -r oldrev", it will give different results on a checkout made with "bzr co --lightweight" [02:01] I'm going to submit a patch to this fetcher thing to use update [02:03] appreciate the help :) sorry for being dense, heh [02:08] hbeck: that's ok, this corner of bzr is unnecessarily confusing :( [03:24] For some reason i can't access my repository on my ftp server using bazaar explorer anymore, i have to use the command line, anyone have any idea whats going on? :< [05:16] I'm a little confused by the earlier conversation on checkouts and branches. [05:17] I am such an old Bazaar user that “checkout” is what the new world order names “bound branch”. [05:17] what's the current state of play? are checkouts not good? are bound branches not good? are plaid pants not good? [05:18] Plaid pants are totally not good. Even I know that. [05:18] Of course, I'm not overly pro-pants in general, so I'm not the best source... === cinerama_ is now known as cinerama [07:08] hi all ! [07:10] Again? You just said that yesterday... [07:11] yeah, any idea about different punch lines ? I grow tired of repeating myself ;) [07:11] "So I said, 'Horse? That looks more like a peanut to me!'" [07:20] you could try RPN? ! all hi [07:27] spm: I like that ! [07:28] fullermd: s/Horse/Goat/ ? [07:29] I dunno. I guess it depends on the joke you put before it. That's your part; I just supply the punchline :p [07:31] well, you used to supply the goats too... [07:31] Oh, now you're just trying to get my goat. [07:31] only one left ?!?!? [07:35] fullermd: you were the one with strong opinions re. checkout, bound branch, etc. [07:36] * vila ducks [07:36] so why should I use one or the other or both or neither or 1.5-of-the-way [07:36] Oh, I've got strong opinions on all sorts of things. That's why people avoid me :) [07:37] * bignose is much happier now having configured Emacs ‘diff-mode’ colours properly [07:37] Well, I'm not the one to ask about bound branches, as I'm not overly interested in them. I'm not anti-them, just don't fit anything I need doing. [07:37] what imbecile thought that having the same colour for added and removed lines was a good idea [07:37] My periodic gripe is that there are conceptually "bound branches" and "checkouts", and bzr implements one thing that's part one and part the other, advertising it as botrh. [07:38] bignose: ? That doesn't match my experience and I don't remember having changed anything there... [07:38] And both, too. The 'r' is silent. [07:38] fullermd: and invisible.. [07:39] vila: ‘diff-mode’ has faces for added lines and removed lines; they both inherit from the “changed lines” face. [07:39] which is yellow. [07:40] bignose: weird, deleted lines are red and added lines are blue here.. [07:40] well, they are now for me, but I had to change it from Debian's Emacs defaults :-) [07:40] (deleted lines red, added lines green) [07:40] (now for me) [07:40] (in parentheses) [07:41] oh crap, lost connection to my secondary desktop :-( [07:41] bignose: ha. hunk separators are green here [07:42] It's not lost connection, it's just locked up for a few minutes while it tries to swap emacs in ;p [07:42] bignose: oh, I *did* change that ;) [07:42] ;;; Set more shiny faces for diff-mode [07:42] (custom-set-faces [07:42] '(diff-hunk-header ((t (:foreground "#007700"))) t) [07:44] * vila frowns at natty :-/ [07:51] pfew, thanks firefox for restoring my not-yet-saved review comments... I have no idea those could survive a reboot... [07:51] hmm, I had, now I know [07:53] Well, you just save 'em off into a file... [07:54] ha right, I always forgot my time machine [07:57] You use ViewSourceWith so you can use $EDITOR on textboxen, then you can just recover the temp file. [07:57] Well, unless you put it on a swap-backed /tmp like I do... [07:59] * vila blinks... and seriously considers resurrecting the emacs-client setup task from the TODO graveyard [07:59] * fullermd . o O ( easier to just set it up to use gvim... ) [07:59] .oO( for some values of “easier” ) [08:05] . o O (There are two editors: emacs and ed. The later and a working internet connection are enough to setup the former and even there the later may not be needed ;) [08:07] And dd/sh is the One True programming language ;p [08:07] :) [08:12] spiv: do you know in which ubuntu package one may find the python test suite ? [08:13] vila: it's not in the Python source code package? [08:13] I wouldn't expect the Python test suite to be in any binary package, if that's what you're expecting. [08:13] bignose: it probably is but this won't make it available with a simple 'import' no ? [08:14] vila: well, the Python test suite isn't something available with a simple ‘import’. [08:14] I don't think so, anyway. [08:14] crap [08:14] since Python is not itself implemented wholly in Python [08:15] or rather, the ‘python’ packages are CPython, which is implemented mostly in C. [08:15] well, I'm reviewing a proposal where a module from the test suite is used as a basis so it's a compelling reason to make it available [08:16] by “as a basis” we might not understand the same thing. [08:16] vila: are you referring to a subclass? [08:16] because “as a basis” doesn't imply that. [08:17] right, sorry for my broken english, have a look at https://code.launchpad.net/~songofacandy/bzr/i18n-utextwrap/+merge/59950 [08:17] at the end of 'bzrlib/tests/test_utextwrap.py' [08:18] I've never seen such use and wanted to look at it with a working setup, hence the need to have the import succeeds [08:18] vila: okay. I think you're referring to the test suite for the Python standard library [08:18] which is mostly implemented in Python, and AFAIK the test suite for the standard library is also implemented in Python [08:18] and hence importable [08:19] vila: the package might be ‘python-dev’, but that's just a guess [08:19] yup, I'm after tests.test_textwrap precisely [08:19] already installed [08:20] I'm 99% sure the stdlib test are not installed [08:20] I would not expect any binary package to make the standard library's own test suite available for import. [08:20] hehe, I don't mind if the package is called xxx-test-suite ;) [08:22] vila: I don't think Python's test suite is packaged [08:22] vila: the test.regrtest module is packaged, but none of the individual test modules AFAICS [08:22] right, I'll live with that and will just put the module in my private setup for... testing :) [09:37] vila: for you: https://bugs.launchpad.net/bzr/+bug/777650 [09:37] Ubuntu bug 777650 in Bazaar "[win32] `bzr selftest > test.log` creates too long lines" [Undecided,New] [09:37] bonjour vila [09:38] bialix: great, thanks ! [09:38] vila: it seems the old behavior I remember is now changed [09:39] now selftest does not clear correctly progress messages at all [09:39] when redirected [09:39] I wonder if it related to testtools [09:40] It seems related to a bad terminal detection, I don't think testtools is involved.... or is it ? [09:41] bialix: what happens if you force values in osutils._win32_terminal_size ? [09:42] it's not very easy [09:43] so it possible but not right now, sorry [09:43] this bug is not critical for me [09:43] a bit annoying but I have enough mental force to not cry [09:44] Darn. I'll have to come up with an even more inventive means of torture now... [09:44] try adding comments in this bug for the various different cases your observe then [09:44] ok [09:45] o, hi fullermd [09:45] have you asked for qdiff to remember unidiff knob? [09:46] I think I did $YEARS ago... [09:47] how's bad, I've just thought about fixing that [09:48] Well, so you just read my mind very slowly ;) [09:48] 's probably for the best anyway. If you read it quickly, you'd probably run away screaming. [09:48] yep [09:49] are you using qdiff or qbzr in general? [09:49] Not with any regularity. And mostly recreationally when I do. [09:50] damn, and we don't have blackjack inside yet [09:50] I'm waiting on Solitaire. Red 1604.2.37 on the black 1605. [09:55] ghaaaa! that's so cool idea! [09:56] It's a new UI for rebase 8-} [09:56] :-D [09:59] . o O (UI for rebase and other history tweaks....) [10:00] . o O (drag: pull, merge, etc...) === hunger_ is now known as hunger [12:33] Does anyone know if there is an open bug for bzr's algorithm for figuring out which revisions to fetch being fairly dire? [12:34] As an example, try bzr branching gcc-linaro into an empty shared repository. It spent >2MB of data transfer trying to figure out what revisions were missing ("all of them") before I gave up [12:36] maxb: not sure if a bug is filed for it, but branching into an empty shared repository disable the shortcut used when branching otherwise (branching as in: I want all the revisions) [12:37] maxb: the "workaround" is to create a standalone branch and *then* reconfigure it to use a shared repo so that all the queries are local instead of across the network [12:37] I think we could learn from mercurial here. Their network protocol for figuring this out seemed rather well designed when I read its developer docs [12:44] maxb: there's an open bug for that. [12:44] I figured there would be, I'm just having trouble phrasing a suitable search :-/ [12:45] maxb: https://bugs.launchpad.net/bzr/+bug/388269 [12:45] Ubuntu bug 388269 in Bazaar "many get_parent_map calls during walk to common revisions when branching into empty repository" [High,Confirmed] [12:45] thanks :-) [12:47] maxb: one limitation is that calculating the heads for a repo is not a cheap operation for us [12:49] maxb: I think we could relatively easily make that cheap (it would involve having the repo on-disk format track the list of heads), although that's only part of the problem. [12:50] Another is that we probably should be doing exponential walking backwards, rather than the fixed number of steps we do now [12:51] There's also some potentially clever stuff we could do by using bloom filters rather than sending long strings of revision ids on the wire, although that's more about keeping individual roundtrips small than reducing roundtrips [12:51] (But if a single roundtrip can do more work then that obviously helps us reduce roundtrips) [12:52] The approach I see described on the hg wiki seems pretty much in line with ideas we've previously discussed. Care to help us implement them? :) [12:53] Definitely interested, though I need to learn a bit more about the existing internals first. [12:54] Bazaar's rather profligate use of bandwidth is a sore point when trying to tempt hg and git users, I think [12:54] Well, if it's profligate use of bandwidth you want to fix, those are different buts ;) [12:54] *bugs [12:55] This one is excessive network round trips :) [12:55] (Which tends to suggest more bytes are being exchanged than strictly necessary too, but to a much lesser degree) [13:45] jam: I've got a crude hack for 'bzr branch --stacked REMOTE local' that fetches inv and text data that'll be needed to build the working tree at lp:~spiv/bzr/faster-stacked-tree-build [13:46] jam: it's in an extremely ugly state but for one branch it cuts the roundtrips from 151 to 85, and the bytes transferred from 38.6M to 13.5M [13:47] jam: but it takes 6.9s rather than 3.1s; I guess it's the extra time to write and validate all the extra data into the local repo that we'd otherwise discard [13:48] jam: it looks like making get_stream_for_missing keys is the main remaining source of VFS calls, fixing that would probably trim the roundtrips and bandwidth even further. [13:48] * spiv -> zzz [13:59] okay, what else needs following up on... === Ursinha-afk is now known as Ursinha === ScottK2 is now known as ScottK [14:09] spiv: how REMOTE is remote in that case? [14:11] he's abed. [14:13] vila's back now right? I wanted to bother him about some config bugs. [14:13] yup [14:13] shoot [14:13] mgz: and I'm landing export-tt without eith [14:14] gotcha. [14:14] so, currently bzrlib.config has three entry points for ConfigObj() [14:15] one of which doesn't try/except, hence bug 502060 [14:15] Launchpad bug 502060 in Bazaar "Clearer exceptions on config file parsing errors" [Medium,Confirmed] https://launchpad.net/bugs/502060 [14:15] also bug 688677 would need fixing in three places [14:15] Launchpad bug 688677 in bzr (Ubuntu) "UnicodeDecodeError loading config file containing invalid UTF-8" [Low,Triaged] https://launchpad.net/bugs/688677 [14:15] what do you call an entry point ? [14:15] is the idea with lp:~vila/bzr/config-abstract-store that the _load_from_string method will then be the only place? [14:16] mgz: yes [14:16] okay, so I may as well leave those bugs till you've landed [14:16] mgz: but this isn't used so far [14:16] otherwise we'll just conflict [14:17] yeah, I didn't see any of your bits *removing* code. [14:17] so, when you do, you'll fix the first of those bugs as a side effect, probably want a test for it. [14:18] and the second one will be easy, just need an except UnicodeDecodeError clause. [14:18] huh, while would I fix the first one ? [14:20] anyway, there are tagged with 'config' so I'll probably won't miss them [14:20] because if the code for TransportConfig._get_configobj goes through your method, it'll start catching ParseError [14:21] ha right [14:21] they both seem tagged appropriately [14:22] yes, sorry, that what I meant, I checked [14:23] ...my flakey internet at the moment really screws up bzr and launchpad http access [14:23] jam, mgz: so what are we up with lp:~gz/bzr/test_traceback_compat_656170 ⇒ lp:bzr ? [14:23] vila: failing for seemingly unrelated issues, IIRC [14:23] I was just going to try and send it again to get the pqm output myself [14:23] but hydrazine's hung [14:24] * mgz hits ctrl+c and waits a few minutes for the timeout [14:29] mgz: when did you use hydrazine last ? I had to clear my cache and re-authorize after upgrading to natty... [14:29] mgz: and launchpadlib has been upgraded too [14:29] it's just my connection's sucky during the day lately I think, randomly fails to establish tcp connections [14:30] k k , just mentioning [14:30] I'll pull launchpadlib too and see. [14:33] http://paste.ubuntu.com/603717/ <- eg. Worked on the next try though. [14:35] weird [14:38] hmm [14:38] hi vila, jam, jelmer [14:38] hey poolie, how's Budapest? [14:38] hi poolie, enjoying Budapest? [14:40] It looks like IDS refuses to work with non-local repositories [14:40] yet, Inter.get defaults to returning "InterRepository" if it can't find any alternatives, and that uses RepoFetcher [14:41] which seems to assume data has the same model, etc. [14:46] I'll look at Naoki's text wrapper branch later when I can actually fetch it [14:46] mgz: that would be awesome ! [14:49] hi, am i back? [14:49] it is good [14:49] no [14:49] :) [14:51] vila, so you merged all your config code? [14:52] that's great [14:52] poolie: almost yes, I'm piloting right now but will resubmit the concrete-stacks one for re-review before starting on new stuff [14:53] the review queue is almost back to a manageable size [14:53] mm still pretty hefty though [14:54] jelmer: InterRepo doesn't assume same models, does want to use InventoryDeltas if it can. [14:54] otherwise I think it falls all the way back to new.serialize(old.deserialize(content)) [14:54] IDS doesn't do remote per other people's request. [14:54] poolie: yeah, but according to http://webnumbr.com/bzr-active-reviews were on the right track ;) [14:54] (and if we have decent inventory deltas, it should be ok) [14:56] jam: do sinks deserialize/reserialize? [14:58] jam: as far as I can tell RepoFetcher doesn't do any sort of translation; it's also used exactly the same way by InterSameDataRepository [14:59] it seems strange that InterRepository is the default while InterSameDataRepository is basically InterRepository with an is_compatible method and is separately registered [15:04] * jelmer if this also be why it is possible to fetch from a subtree format into a non-subtree format [15:13] In the bzr beta PPA for hardy: [15:13] ERROR: bzrlib.tests.commands.test_commit.TestCommitWithBoundBranch.test_commit_both_modified [15:13] NotImplementedError: [15:14] Does that mean anything immediate to anyone? [15:14] mab: it looks vaguely familiar, but I don't recall what the exact issue was [15:15] hi maxb, [15:15] it is familiar [15:15] maxb: rings a bell [15:15] i think it's a lack of isolation from the test environment [15:15] is that on trunk? [15:16] Yes (2.4b2) [15:16] maxb: running tests in parallel ? [15:16] *gha!* [15:16] yes [15:16] hmm [15:16] but on random ports [15:17] that gives more weight to the test isolation issue [15:21] jelmer, ams_cs was saying on the linaro list he found rebase really slow [15:21] ... what should we do? [15:23] that seems likely, it's O(tree) at the moment and it uses a workingtree for its operations rather than e.g. a memory tree [15:24] I don't have a silver bullet, although I do have some plans on how to fix rewrite [15:24] I can spend some time on that if you like [15:25] mm [15:25] it would be useful to improve but it's probably not top of the stack at the moment [15:25] poolie: btw, do you know if any of the Linaro folks we've been talking to are going to be at UDS? [15:25] if it was surprising, or if you thought it would be easy to fix i could get more data [15:25] michael hope is here now [15:26] i would guess he's here next week too [15:26] and jamse [15:26] *james [15:27] it's this thread http://lists.linaro.org/pipermail/linaro-toolchain/2011-May/001196.html [15:39] jelmer, i think we should have at least a bug for rebase performance so people can vote for it [15:41] poolie: that's a good idea [15:53] vila thanks for the prod on my rules branche [15:53] on the whole i think i'll just land it with the curren name [15:53] poolie: yeah, and keep working on it to fix the related bug ? [15:53] indeed [15:54] that gives a better history in the end while making the intermediate reviews easier [15:54] maybe not this week though [15:54] np [16:00] oh also, vila, consider yourself prodded to send a pp mail at the end of the week [16:01] poolie: hehe, yeah, sounds like an habit we should all take ;) [16:01] indeed [16:01] i think i sent one last time i piloted [16:01] sometimes the Ubuntu pp reports worry me that they are so long [16:02] it seems like a lot of overhead for one day's work (in their case) [16:02] but for us i think a short report is good [16:02] it reminds us we're doing it [16:02] yeah, I read them searching for ideas to pick [16:02] but their context is too different so far [16:17] cute launchpad bug. I can edit a bug's priority if it's on a project I have rights to and move it to one I don't at the same time. [16:25] haha [16:25] presumably this means you can edit anything [16:26] mgz: go ahead, fix bug #1 [16:27] Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 [16:28] hi; can bzr merge unrelated branches alla git ? [16:28] io2: yes, though you have to force it to do so [16:28] io2: "bzr merge -r0..-1 ../unrelated-branch" [16:29] oh [16:30] thanks jelmer [16:31] jelmer: i thought that http://zakalwe.fi/~shd/articles/why_not_bazaar.html was still valid tbh [16:34] io2: that's a very biased document [16:34] indeed [16:34] trying to find out a cross platform dvcs that works well right now [16:44] s/biased/inaccurate/ [16:47] "We accept social misanthropes, perfectly normal people with 2.5 kids, a dog and soccer practice on Sundays." [16:47] I get the bit about accepting the dog, after all on the internet no one cares if you're a dog... but can soccer practice on Sundays really format a patch correctly? [16:48] * jelmer has religious problems with both [16:48] guys, wanna help me get from git to bzr ? [16:49] I like the ui tools and launchpad :P [16:49] yes, particularly if you say that in a NZ accent. [16:49] http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html [16:50] lol [16:50] how fast is bzr these days btw ? [16:52] still slow on kernel-sized things for some operations, but pretty good for most projects. [16:56] I tend to get most annoyed by the time it takes Qt to page in rather than anything bzr does, to give you an idea of the kind of delays I normally run into. [16:57] hmm === med_out is now known as medberry [17:36] oh man, pqm looks totally hosed. [17:36] ? [17:36] I just got a totally different set of errors from jam's run. [17:37] ah, no, that's the log being confusing. [17:37] mgz: just after processing your submission... [17:37] mgz: :-D [17:37] they're nearly all expected failures in the email [17:37]