[00:04] k [00:04] i may do the announcement, or perhaps igc can [00:05] hi jam. I hope you're feeling a bit better [00:05] jam: enjoy your break [00:05] jam: sorry if I email re 'no announcement' came across as critical - it wasn't meant to be [00:05] s/I/my/ [00:26] Would love it if someone could point me in the right direction... I get 'bzr: ERROR: Target directory "drupal" already exists.' when I enter bzr branch lp:drupal. I've previously used parent branch: bzr://vcs.fourkitchens.com/drupal/7/ but awhile back I started getting 'bzr: ERROR: [Errno 13] Permission denied' I don't know how to fix either but I do need an up-to-date copy of Drupal 7. [00:27] lisarex: 'bzr branch lp:drupal' wants to create a local directory called "drupal", but you already have a directory called "drupal". [00:27] spiv: yes that's probably the case (not sure how to check) [00:28] "ls" will list the files and directories in the current directory [00:28] Also, what command were you running that was producing the "bzr: ERROR: [Errno 13] Permission denied' error? [00:28] 'ls drupal' [00:29] spiv: ok, yes there is a drupal directory within my 'root' web folder I'm calling d7 ... not sure how I missed that [00:29] spiv: can I just delete that drupal directory? [00:30] spiv: was running bzr pull [00:31] If you don't want the directory, the sure you can delete it. I don't know if you care about its contents or not. [00:32] You can also do 'bzr branch lp:drupal drupal-copy' to branch it to a directory other than 'drupal' (in that example 'drupal-copy'). [00:34] spiv: thanks, trying that now [00:44] spiv: cool. downloaded the files. Just need to ensure that the files I've downloaded are updating my d7 directory too (I may end up starting over :)) [00:47] spiv: OK it has. Thanks so much for the help :) [00:55] spiv, hi [00:55] which of bug 437626 and bug 445171 do you think is more important? maybe the first? [00:55] Launchpad bug 437626 in bzr/2.0 "exceptions.AssertionError: second push failed to complete a fetch set" [High,Fix released] https://launchpad.net/bugs/437626 [00:55] Launchpad bug 445171 in bzr/2.0 "ObjectNotLocked doing 'bzr log -r 199 path/to/file'" [High,Fix released] https://launchpad.net/bugs/445171 [00:57] poolie: hi [00:57] hi [00:57] hungry? [00:57] poolie: reminder: lunch. Also can you add niel to the contributor team - I don't have accecss to do that. [00:57] hm [00:57] neil, I mean. [00:57] remind me niel who? [00:58] oh ok [00:58] Neil Martinsen-Burrell [00:58] he mailed in the agreement yesterday [00:58] i understand now [00:58] i thought you meant 'niel' [01:00] done anyhow [01:00] poolie: you've added me? [01:00] yes [01:00] i was going to try to make you an admin [01:00] oh [01:01] so really we should just change the owner to a team [01:01] but i failed; see #launchpad [01:01] probably [01:01] rather than having us in it. [01:01] as we haven't strictly signed it. [01:03] I've sent mail [01:03] is this something that you want me to fix? or... ? [01:04] poolie: yeah, I think I'd say the first. [01:04] spm, we could ask you to steal ownership but at this point that seems like overkill [01:04] spiv, thanks, underway [01:04] poolie: oki [01:06] poolie: yeah, definitely the first, compare the number of duplicates. More users were hitting that. === ereslibre_laptop is now known as ereslibre [01:13] poolie: so seeing you soon? [01:13] going to finish bug 437626 sru process then leave [01:13] Launchpad bug 437626 in bzr/2.0 "exceptions.AssertionError: second push failed to complete a fetch set" [High,Fix released] https://launchpad.net/bugs/437626 [01:14] so pretty soon [01:23] * mwhudson remembers that there was a bzr bug that resulted in repos being very fragmented across many packs [01:23] (a) am i right (b) is it fixed (c) which version has the fix? [01:31] mwhudson: no, there was a bug where inside a pack we didn't consolidate properly. [01:31] mwhudson: any 2.0+ is fine. [01:32] lifeless: ah ok [01:32] http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/.bzr/repository/packs/ has 26 packs, is that more than i should expect? [01:32] mwhudson: no [01:33] mwhudson: you could get at at 999 revisions, for instance. [01:33] mwhudson: dump-btree on the packs-name index will tell you if you have stale packs [01:36] lifeless: seems we do [01:37] mwhudson: the number of packs you have is dependent on the exact operations that have taken place. The way it works is that there is an upper bound. [01:37] and when the bound is exceeded by a transaction, an incremental pack is triggered, which consolidates the smallest (by rev count) packs into one, stopping at the point that will be under the upper bound. [01:38] mwhudson: the upper bound is sum(int(digit) for digit in str(repo.revision_count())) [01:38] Hi - Is there a way to find the revno of the common ancestor for two branches? [01:38] lifeless: right, that's what i thought [01:38] mwhudson: so 998 revisons == 26 as upper bound [01:39] i guess i was too lazy to work out what that is for launchpad :) [01:40] and in general, upper bound ~= 10*log10(revcount) [01:40] mathiaz: not really, no. there is show-ancestor I think. [02:16] lifeless: ok found a workaround for ubuntu package branches [02:17] lifeless: bzr log -rancestor:../squeeze (in the lucid branch) [02:17] lifeless: ^^ that gives the revno of the common ancestor [02:37] <_habnabit> Is it possible to only merge part of a revision, without merging the whole revision? [02:38] I suppose you can shelve or revert some of the changes. [02:39] History-wise, you can either record that the revision was merged or not (a cherrypick). [02:39] <_habnabit> So, merge that revision, shelve the changes, and commit? [02:41] If you want to. [02:41] What are you trying to do? [02:41] _habnabit: yes, that works. But if that records as a merge, it means future merges will not try to merge the bits you left out. [02:42] <_habnabit> I'm trying to backport changes from a fork of a particular project, but one revision has some changes I don't want to backport. [02:42] Which may be what you want? [02:42] Ok, my guess is that is what you want, then :) [02:43] <_habnabit> I'm not sure what the exact connotations of what you said are, so. [02:44] Well, after you 'bzr merge' but before you 'bzr commit', look at 'bzr status'; it (usually) will show "pending merges" [02:44] igc: not critical at all, just genuine. I haven't had time because of X and Y and Z, and if someone else *has* the time, I'm really far behind [02:44] and it would be great [02:45] its a fair amount of work to announce [02:45] and I didn't open my laptop really until this evening for a little bit [02:47] _habnabit: commit records the contents of the files, but it can also record "revision X was merged in at this point". If it does, then the next time you 'bzr merge' in that branch bzr will know that the changes in that revision have already been merged and will not merge them again. [02:47] <_habnabit> spiv, ah. [02:48] <_habnabit> I did the merge, but it doesn't show that there are any pending merges. [02:48] _habnabit: so the question is basically, "the next time you merge from that branch into this one, do you want bzr to try merge all these changes again, or assume they have been merged (so only newer changes should be considered)" [02:48] <_habnabit> There were conflicts, though. [02:48] <_habnabit> (And I resolved the conflicts.) [02:49] Conflicts don't affect that; but if you do 'bzr merge -r X..Y' or 'bzr merge subdirectory/of/branch' or something like that, it won't record a pending merge in the working tree. [02:49] <_habnabit> Ahh, I see. [02:49] <_habnabit> Yeah, I did merge -r. [02:50] Because the merge record is just "this revision ID is another parent of this revision" [02:51] Which can't track revision ranges or merging just some files, etc. [02:51] We'd like to track these more complicated cases, but we haven't implemented that yet. [03:08] poolie: http://amp.carboni.ca/ [03:09] wow, that sounds fairly insane [03:19] Rewriting Bazaar? That's not going to be fun. [03:29] That sounds like a general waste of time, in fact. [03:43] is there an equivalent to git gc in bzr? [04:08] LaserJock: Removing unreferenced revisions? No. [04:08] LaserJock: Recompressing the repository? "bzr pack". But, a side from a couple old bugs leading to bad compression, you don't need to run it yourslf; bzr autopacks frequently enough to keep things healthy. [04:09] s/a side/aside/ [04:09] s/yourslf/yourself/ damn. [04:10] (Actually, the bugs aren't that old, but they weren't frequently hit: you would have to have been using the 2a format before bzr 2.0.) [04:12] LaserJock: BTW, unless you'r using the 2a format, "bzr pack" doesn't even do all that much: it combines the pack files into 1, bit it doesn't recompress them. [04:13] s/bit/but/ What's wrong with my typing tonight? [04:19] Peng: but there's the obsolete-packs dir, right. Does bzr pack get rid of that? [04:19] I was just comparing .git to .bzr sizes on a branch and I noticed that .bzr was huge [04:21] LaserJock: no, obsolete-packs is probably still there [04:22] ok, well I just rm'd the contents of obsolete-packs [04:22] LaserJock: Every time the repo is packed (whether an auto-pack or "bzr pack"), obsolete_packs is emptied, then afterwards, any now-unnecessary packs are moved into it. [04:23] LaserJock: Why? [04:23] Peng: ok, that doesn't make a ton of sense to me but I believe you [04:23] because I don't know how to get rid of it otherwise [04:23] LaserJock: It'll be automatically emptied later. Why do you need to do it now? [04:23] 1) because i'm trying to figure out repo sizes [04:24] 2) I don't know when it will be emptied [04:24] it was an extra 100+MB sitting in my branch [04:25] LaserJock: obsolete_packs is used because OSes can't be trusted to immediately write files to the disk. It'd be unfortunate if you had a power failure right after a "bzr pack" and lost all of your data because the file was really sitting in a buffer. This way, you still have the old packs around to recover. [04:25] having almost 200MB for a 20MB working tree doesn't seem very space-efficient to me [04:26] LaserJock: Which repo format? ("bzr info") [04:26] 2a [04:26] Aww. [04:27] what does bzr thing about \r in commit messages these days? [04:27] if you tell me I need a newer format I'm going to kill myself [04:27] LaserJock: Sadly, there isn't another new format yet. :P [04:27] how can this be?! [04:29] I thought the 2.0 format was supposed to get much closer to git with respect to size [04:29] It usually does. [04:30] LaserJock: how big is git for this branch? [04:32] mwhudson: 22MB [04:32] bzr is 45MB after rm'ing the obsolete packs [04:32] most of the branches I've tried bzr seems to run around twice the size [04:33] LaserJock: converted with bzr-git? [04:33] on that one yeah [04:33] other's have been git-svn vs bzr-svn [04:33] *others [04:34] mwhudson: Wasn't bzr recently changed to remove \r from commit messages, at least on Windows and/or at least in XML-based repos? [04:34] Peng: doesn't look like it [04:36] Peng: bzrlib.repository.CommitBuilder._validate_unicode_text [04:40] mwhudson: r4783 [04:41] mwhudson: It's only done at a high level, when you use "bzr ci -m". [04:41] mwhudson: Other than that, I've got no idea what the \r situation is. :D [04:44] LaserJock: try converting with git fast-export + bzr fast-import instead. I think you'll see a smaller size [04:44] LaserJock: than conversion via bzr-git gives you [04:44] interesting [04:45] the revids will me much shorter :-) [04:45] *be [04:46] 22MB vs 45MB isn't too bad, I just thought 22MB vs 200MB was a bit excessive [04:46] LaserJock: Bzr's compression is sensitive to the rev-id and file-id scheme used. fast-import uses the native bzr schemes while bzr-git uses a custom scheme [04:46] ditto for bzr-hg and bzr-svn [04:46] I see === kgoetz is now known as Kamping_Kaiser [07:23] hi all === vila is now known as vila-afk [08:24] hello vila === vila-afk is now known as vila [08:48] hello vila [08:48] hey poolie ! Sotty, had to go to school for Juliette who is sick [08:48] np [08:48] sorry to hear that [08:48] s/sotty/sorry/ [08:49] That doesn't seem too bad, a bit of rest will hopefully be all that is needed [08:56] igc here? [08:56] hello all [08:56] hi bialix [08:56] hi igc [08:57] is it possible to say "Version control for Human beings" as "Version control with human face"? [08:57] I'm still trying to find the good translation for you slogan [08:57] igc: ^ [08:57] Hi bialix [08:58] Hi GaryvdM [08:58] Hi all [08:58] * bialix needs to reboot, bbiab [09:00] bialix: Ubuntu's slogan is "Linux for Human Beings" [09:01] bialix: maybe translate "Human Beings" to "Everyone" [09:04] * bialix back [09:07] igc: for everyone is good [09:07] thx [09:12] * igc dinner [09:14] bialix: Howdy. You pung the other day? [09:15] fullermd: hello [09:15] pung? how's funny word [09:16] it's not relevant today [09:16] Oh, sorta I guess. Putative past tense of 'to ping'. [09:16] I've just tried to ask anybody of native English to ask meaning of "...for Human Beings" [09:17] Ah, 'k. [09:19] ерч фтнцфн Ж-) [09:19] thx anyway :-) [09:30] igc: has https://code.edge.launchpad.net/~mbp/bzr-usertest/trivial/+merge/7532 landed? the renamed branch means lp can't tell [10:08] who has moderator right re bzr ML? [10:09] can you accept mail from Henning Eggers? [10:20] bialix: done, thanks [10:21] thx spiv :-) [10:50] vila: could you review https://code.edge.launchpad.net/~doxxx/bzr/quiet-serve/+merge/15112 ? [11:02] lifeless: done [11:06] * fullermd pours some extra coffee for vila. [11:10] fullermd: yeah ! [11:10] 'course, you're not _here_, so I guess I'll have to drink it for you. [11:12] fullermd: that should give it a better taste anyway :-) [11:21] vila: Incidentally, did you ever get around to looking over that Fasces stuff? [11:22] ECONTEXT Fasces ? [11:22] My colocated branch-ish dofligger. [11:23] ouch, no :( [11:23] Ah, 'k. I guess that field of endeavor isn't percing up anybody's todo yet anyway. [11:24] Just wondering if silence meant that, or that it was so perfect nobody had anything to add 8-} [11:25] Well, I think colocated branches should resurface soon (for some value of soon up to six months).... === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === loxs_wrk is now known as loxs === AfC1 is now known as AfC [14:22] I have an svn repository containing multiple projects, each in its own directory with its own trunk/tags/branches setup. How do I teach bzr-svn to cooperate with this? [15:19] hey, what's the command to use if my bzr server changed it location? [15:19] yoavmoshe, --remember [15:19] bzr COMMAND LOCATION --remember [15:19] oh okay, thanks beuno! [15:20] umm... bzr says 'no such option: --remember', runinng bzr 2.0.1.. [15:24] yoavmoshe, when running which command? [15:24] update [15:26] hm, I don't know how to change what branch it's bound to [15:30] beuno: okay thanks. I'll keep trying and post here if i'll find something. [15:33] well i'm not supposed to do it, but i just edited .bzr/branch/branch.conf and it went just fine [15:34] yoavmoshe: 1) You're not supposed to do it indeed :) 2) That was the right thing to do 3) Please file a bug [15:34] * beuno waves at vila [15:35] * vila warmly waves back [15:37] vila: you're sure? i'm thinking that there's probably a way to do it but i just don't have the time to figure what is it... I can fill a bug but i don't want to create some fault 'bug' just because i didn't RTFM.. :p [15:39] yoavmoshe: better a duplicate than no bug at all, I'm pretty sure you're using a lightweight checkout (i.e. the setup used for a central server that rarely (never) moves) and as such you can't: unbind, pull --remember, bind :pull [15:40] hmm, or maybe just 'pull --remember' would have worked... [15:40] vila: um actually i use a full checkout, but some of the other clients use a lightweight one. I'll fill a bug [15:41] yoavmoshe: can you undo your edit and try 'pull --remember ' ? [15:41] i'll revert my changes and see, it it doesn't i'll fill a bug [15:41] s/bew/new/ [15:41] yoavmoshe: great, thanks [15:43] bzr pull doesn't work. it connects the new server, but it fails giving me an error for the old one. I'll fill a bug [15:44] vila: i did 'bzr unbind' and then 'bzr bind $newserver' and it worked. You sure you can't do that on a lightweight checkout? [15:45] you can't unbind lightweight checkouts [15:45] okay. [15:54] evening vila :-) [15:56] bialix: ghaa, as if jetlag wasn't bad enough, now you make me wonder even more about what time it is :) [15:57] just saw you're here, so decided to say hello === beuno is now known as beuno-lunch [16:54] \o/ [16:55] privet kostja === beuno-lunch is now known as beuno [17:07] hello all [17:27] vila: switch --force works with heavyweight checkouts. [17:27] vila: (and also with lightweight ones) [19:23] vila: thanks === Loginx is now known as Linkadmin [20:31] So, uh, how bad is "inconsistent details in skipped record"? [20:37] it indicates a different view of history between two repos. [20:37] how bad it is depends on the difference ;) [20:41] :D [20:42] "Crushed by a giant packfile"... what a great Subject: line. [20:49] Huh, one version of the record uses StaticTuples, and the other tuples and lists. [20:52] Peng: more fallout perhaps [20:52] Pastie: http://paste.ubuntu.com/327982/ [20:52] The contents of the records themselves are different. Dunno if it's in a meaningful way, though. [20:53] Maybe bzr is angry about my abuse of stacking. :P === Ng__ is now known as Ng === wgrant_ is now known as wgrant [21:25] Peng: looks bogus to me [21:28] lifeless: Bogus? So...nothing's wrong? [21:34] well something is [21:34] it may be in the warning code [21:34] Well, I'm running "bzr check". We'll find out in a few days. :P [22:05] Peng: thanks [22:08] hi lifeless [22:10] poolie: I've been looking into building the bzr installer for Mac OS X. Not easy... :P [22:10] :/ [22:10] did you find any documentation about it? [22:11] jfroy worked on it a bit before [22:11] yeah I was reading his messages on the bzr-mac mailing list [22:11] I also found some older wiki pages [22:11] it would be nice to get those wiki pages up to date with whatever is expected to be the best method [22:11] I'll give it a go in the next day or two when I can borrow the laptop from its owner [22:12] i think guilermo worked on this too [22:12] and he's sometimes on irc [22:12] yes [22:12] I'll probably bug him if I run into a tricky situation [22:12] spiv, hey, nice bug work recently :) [22:12] anyway, gotta run for a train. seeya later. [22:14] lifeless: Should be done in about 34.5 hours, FWIW. [22:14] hi poolie [23:35] igc: ping [23:35] hi lifeless - just looking at your Q now [23:36] lifeless: nope, it has landed. I'll do it now [23:36] has *not* [23:36] igc: be sure to manually mark it as done [23:37] shall do [23:37] thanks (this is why I don't like the rename-branch approach to upgrading, its disruptive) [23:37] igc, hi [23:37] hi poolie [23:37] igc, could you take over the task of proposing a merge to add graphs of the bzr bug count etc? [23:37] mwhudson has done the database queries [23:38] i'm asking you partly because you can actually test it against staging [23:38] so it needs hooking into the graph system, and then for a merge to be proposed [23:38] probably by copy&paste of configuration that's already there [23:38] apparently losas can't do it any time soon [23:38] i can forward the thread if you don't have it [23:39] poolie: I guess so. It's all new to me [23:39] poolie: please [23:39] poolie: or just point me into the mailing list archives if it's there [23:41] sent [23:41] not necessarily right now, i just want to take it out of their queue [23:41] it would be interesting to see if the mp queue length changes [23:41] right [23:41] poolie: the more interesting metrics IMO are ... [23:42] 1. average/median time to go from 'patch submitted' to 'patch landed' [23:43] 2. Average # of changes to bzr's mainline/week [23:44] i.e. are we decreasing delays and are we increasing velocity [23:51] patches welcome :) [23:51] i'd like to see them too [23:52] igc: I think your 1 needs some sort of normalisation w.r.t. to size [23:52] anyhow [23:52] i think breaking the ice as far as adding graphs would be nice [23:53] lifeless: it does. Or even a cutoff - patches below 500 lines say - would do to start with === arjenAU2 is now known as arjenAU