=== dereine is now known as dereine[OFF] [00:15] Hmm, entries in NEWS aren't being alphabetically sorted lately. [01:02] morning [01:02] igc: evening ;-) [01:09] mwhudson: so [01:09] in idnars branch [01:09] check last-revision [01:10] and then iter_revision_history [01:10] loggerhead is thinking that they are equivalent [01:15] lifeless: are they not? [01:16] try it on the branch in question [01:18] spiv: https://code.edge.launchpad.net/~txawsteam/txaws/trunk for your ec2 usage [01:18] >>> b.repository.get_revision(b.revision_history()[0]).parent_ids [01:18] ['mithrandi@mithrandi.net-20090320033718-jxiqtdpm4qru31x2'] [01:18] that's a big strange, isn't it? [01:18] spiv: bin/aws-status specifically [01:19] mwhudson: unusual, but we may see it with ghosts in arch conversions [01:19] mwhudson: so not _wrong_. But unexpected with a native originated branch yes [01:19] lifeless: right, but i don't think that's what's happened here :) [01:19] mwhudson: I've explained what happened already :) [01:20] oh right [01:20] well, i still think it's _probably_ a bzr bug [01:21] our data structures permit it; we don't try to create it and its likely a bug that its being permitted [01:21] lifeless: bzr log --short http://bazaar.launchpad.net/~txawsteam/txaws/trunk is quite funny [01:21] regardless, lp and loggerhead should agree about their links. and right now loggerhead *doesn't* agree with bzr about the revno. [01:22] lifeless: *bzr* doesn't agree about the revnos [01:23] lifeless: if you log --include-merges you get different revnos than if you log --short [01:23] (and this more or less explains why the scanner and loggerhead disagree, in fact) [01:23] mwhudson: ugh [01:23] mwhudson: we need a bug about this [01:24] lifeless: not going to disagree about that [01:30] What happens when you update a branch when pushing another branch that is using the former branch to stack off of? [01:32] cody-somerville: you update the branch [01:32] okay :) [01:47] * igc offline for a few hours [02:39] Hi guys. I've just installed bzr on my Vista32 box, and can't seem to find the location of bazaar.conf. it's not where it says in the docs. [02:40] it doesn't exist by default [02:40] bzr --version will list the path that bzr will be looking for it in [02:40] lifeless: i see. so where does it store my user info when i use "bar whoami ..." ? [02:40] lifeless: thanks that's helpful! [02:43] spiv: alive? [02:57] lifeless: yep [02:58] lifeless: just got a couple of vaccinations, so alive but with two sore arms :) [03:00] ouch [03:00] flu? [03:00] how do i get the difftools plugin to point at my external diff tool? [03:00] TheColonial: I'm not sure sorry; is there a README in it? or perhaps bzr help difftools? [03:01] bzr help difftools was what i was looking for. thanks again. sorry ffor the noob questions [03:02] lifeless: yeah, and tetanus/whooping cough/diptheria. [03:06] the flu one had my arm sore for about 3 days, couldn't type one of them [03:07] Interesting. So far the tetanus arm is hurting more, but early days... [03:08] Tetanus always hurts most, IME. [03:10] Yeah, that was my memory from 10 years ago. [03:13] is tetanus a live virus, or deactivated? [03:15] anyone know if PEP 383 considers normalisation issues? [03:21] tetanus isn't a virus at all, is it? [03:22] Gram-positive, obligate anaerobic bacterium Clostridium tetani [03:22] ^ apparently [03:25] This vaccine contains "tetanus toxoid". === abentley1 is now known as abentley [03:40] 'ello [03:42] if i have A is a branch of B is a branch of C, and I want to make A a branch of C, how do I do that? [03:43] you could do pull --remember C, I guess [03:45] johnjosephbachir: i'm not really sure what that means [03:46] johnjosephbachir: A is already a branch of C, in most reasonable definitions of the word [04:09] johnjosephbachir: if you want a direct relationship, as SamB says, pull --remember C (or merge --remember C) [04:09] SamB, mwhudson, lifeless -- appologies, got pulled away for something -- will be back later, thanks for your answers [04:45] spiv: ping [04:59] lifeless: I see you're an Aussie. Used to use internode myself, pretty nice ISP. Where you based? [04:59] I live in Sydney [05:00] Did university there === jfroy is now known as jfroy|slave [05:00] so what makes you a fan of bzr as compared to other dvcs? === jfroy|slave is now known as jfroy|worker [05:02] lifeless: pong [05:04] TheColonial: well, I'm one of the core developers/architects [05:04] lifeless: didn't know that :) sorry. [05:04] TheColonial: nothing to be sorry about [05:04] but it means my answers are not typical :P [05:04] i noticed ;) [05:05] lifeless: I've only played with it a little, and doday is the first time i've had a go. it certainly seems nice. output is certainly a lot easier to digest than in the likes of git and hg. [05:05] lifeless, SamB: after pull --remember, after the next time i push, will the parent branch for the remotely hosted branch also be changed? [05:05] johnjosephbachir: the parent branch won't, but it won't have a reference anyway [05:06] TheColonial: glad you're liking it [05:06] spiv: if you look at my most recent patch, I need to get the token for an already locked repo; I couldn't see an obvious api for that [05:06] lifeless: me too :) So is bzr something you work on in your own time? of so,what do you do full time? [05:07] bzr is what I'm paid to work on at the moment [05:07] lifeless: I think token = r.lock_write(); r.unlock() is all we have [05:07] spiv: thats ~= what I did ;). Anyhow - 9 round trips [05:07] :) [05:08] spiv: also did you see the ec2 status gui I wrote? [05:09] lifeless: excellent stuff. well i wish you good luck. thanks for the help. i shall continue to play with it. [05:10] TheColonial: thanks :). Just ask if you have any questions [05:11] lifeless: no, sounds shiny though! [05:15] lifeless: will do :) [05:16] spiv: we probably need to examine some of the other ACF reports [05:16] spiv: see if there are other causes [05:19] lifeless: I've been looking at them as they come in, so far there's no solid evidence of other causes that I can see. [05:19] But it's hard to rule out. [05:20] These bugs where cause and symptom happen far apart are PITA to diagnose. [05:21] bzr tags works for anyone in r4307? === bob2 is now known as Guest5952 [05:22] crash early and often, I say! [05:22] BasicOSX: seems to for me [05:23] I get nothing :-( [05:23] Well, that's expected if you're running it on the bzr.dev branch (unfortunately). [05:23] just tried it on fresh check out of 1.14 too [05:24] Yes, the PQM-managed branches don't have tags. [05:24] I'm not sure why; it's a known issue that hasn't been tracked down yet. [05:24] oh! [05:25] I thought I really borked my local stuff :) [05:25] thanks for the quick answers [05:25] I blame Celine Dion, myself. [05:25] lol [05:25] that's a pretty strange person to blame [05:26] That's exactly why she thought she could get away with it! [05:26] spiv: how do I check out 1.13.1 if there are no tags in PQM managed branches :-) [05:26] If you can't blame a former winner of the Eurovision Song Contest who can you blame? [05:27] Well, if you are American, there is always the Republican Party [05:28] Yeah, but then the other guys feel all left out. It's so much work being sure to balance the blame evenly all the time. [05:28] I don't think the Republicans are smart enough to cause such a problem! [05:28] democrats neither! [05:29] BasicOSX: by reading the bzr log of the 1.13 branch I guess. [05:30] ok, that is what I was doing, thanks. [05:31] * spiv -> lunch === Guest5952 is now known as bob2 [05:51] lifeless: when i do bzr info , it reports a parent branch. that parent branch is going to disappear from existence... shouldn't i change what it points to? [05:52] johnjosephbachir: Depends on why you want to change it. [05:52] The parent branch is mostly cosmetic. It's used as the default for a few commands like 'pull'. [05:52] fullermd: well for one thing, it will be a bit meaningless/useless after that parent branch disappears [05:53] fullermd: well exactly, i want to change the default pull location : ) [05:53] But it doesn't imply any deeper data-model-ish link between the branches. [05:53] Well, you just use --remember next time you pull there. [05:53] and for the rest of the life of the project? for years and years the default pull location won't exist? [05:53] seems like there should be a solution for this... [05:53] No, when you use --remember it'll be changed. [05:54] remotely? [05:54] * fullermd suspects we're talking past each other. [05:54] i mean, for years and years, contributors for the project will have to change the default pull location... [05:54] haha [05:54] perha [05:54] ss [05:54] Huh? No. [05:54] Pull locations are ENTIRELY local. The pull location on $REMOTE_BRANCH is of meaning only to $REMOTE_BRANCH. It doesn't mean anything to any other branches you make based on it. [05:55] fullermd: look at the output of: bzr info bzr+ssh://bazaar.launchpad.net/%7Ejohnjosephbachir/lyceum/trunk [05:55] So if you "cd $REMOTE_BRANCH ; bzr pull", the parent loc matters. If you "bzr branch $REMOTE_BRANCH local ; cd local && bzr pull", the $R_B's "parent" doesn't mean anything. [05:55] Right, but you never ssh to launchpad, cd into that branch, and run 'bzr pull'. [05:55] ahh, okay [05:55] gotcha [05:56] The parent location does not propagate. e.g. When contributors branch from your branch (say lp:~johnjosephbachir/lyceum/trunk), then their branch will get lp:~johnjosephbachir/lyceum/trunk as their parent location. [05:56] How did it get a parent loc in the first place? [05:56] Oh, I see. That's LP internal bits. [05:57] spiv: that's what i thought, but was also wondering what the meaning of parent branch was [05:57] I guess you COULD go in with sftp and edit the branch config file manually if you really wanted to. But it wouldn't affect anything to you from the outside. [05:57] And LP may assign internal meaning to it, in which case it would probably be Bad(tm). [05:57] pull -d lp:whatver whatever-else --remember would also change it, i guess [05:57] fullermd: LP doesn't, for sure [05:58] * johnjosephbachir nods [05:58] Well, I see a URL that starts "lp-hosted:///", I run the other direction from touching it :) [05:58] fullermd: it's actually just an accident of how LP publishes hosted branches, I think. [05:59] johnjosephbachir: Anyway. In a technical sense, the parent branch only matters when you actually cd into that branch and do various ops. You won't in this case, so there's no technical reason to change it. [05:59] fullermd: to the extent that the owner of the branch can't edit the relevant branch.conf... [05:59] k [05:59] johnjosephbachir: You may WANT to change it for cosmetic reasons, but there's no in-bzr reason to. [05:59] mwhudson: LP probably shouldn't be cluttering the branch info with that though. [06:00] fullermd: yeah, to avoid user confusion [06:00] spiv: hey, launchpad is just calling .clone! [06:00] mwhudson: that command-- is that done on the server, or do you mean, i can do that remotely? [06:00] johnjosephbachir: i think you can do it remotely [06:01] mwhudson: sure. The end result is still a bug though :P [06:01] spiv: i guess [06:01] spiv: want to file it? [06:01] Sure. [06:01] * fullermd stabbies all the progress bar fragments left on his terminal from that 'info'... [06:01] * johnjosephbachir reads about the -d flag on pull [06:01] OIC [06:02] spiv, mwhudson: a bzr bug, or a launchpad bug? [06:03] launchpad-bazaar i guess [06:06] Filed: https://bugs.launchpad.net/launchpad-bazaar/+bug/368383 [06:06] Ubuntu bug 368383 in launchpad-bazaar "Public copies of hosted branches have nonsense parent location" [Undecided,New] [06:11] mmmm, not sure I agree [06:11] still, worth noting it caused confusion [06:22] well, i know my newbie question was a good once, since it caused several veterans to embark on intense debate and file a bug report :-D [06:24] s/once/one [06:51] back soon, popping up to chemist [06:59] hi all [08:00] spiv: I'm done for the day; 3 patches up [08:04] lifeless: :) [08:04] PQM 1.13.2, success, attempting to re-pull bzr.1.13 and I get this: http://pastebin.com/m61bd628c [08:04] lifeless: I guess I should do more reviewing then :) [08:04] spiv: 9 rtt :) [08:04] spiv: and 15 for stacked [08:08] BasicPRO: Hmm. That command worked for me. [08:08] bzr branch http://code.launchpad.net/~bzr/bzr/bzr.1.13 bzr-1.13.2 ? [08:08] Right. [08:08] which version of bzr? :-) [08:09] $ bzr --version [08:09] Bazaar (bzr) 1.15dev [08:09] revision: 4307 [08:09] BasicPRO: same [08:10] hmm, /usr/bin/python 2.5.2 ? [08:10] shared repo? [08:10] Although I do notice that that branch has the AbsentContentFactory bug! [08:11] lifeless: http://code.launchpad.net/~bzr/bzr/bzr.1.13 [08:13] trying it on pristine hardy+updates [08:13] BasicPRO: Python 2.6.2 (jaunty) [08:14] BasicPRO: are you branching into a shared repo or standalone? [08:14] python revision should not have anything to do with it? standalone [08:15] issuing bzr branch http://code.launchpad.net/~bzr/bzr/bzr.1.13 bzr-1.13.2 and bzr-.13.2 does not exist on local filesystem [08:16] Yeah, python version should be irrelevant. [08:16] we need to get pqm running 1.14 final [08:16] BasicPRO: is there a local shared repo? [08:16] lifeless: yes please! [08:17] but thats not the issue [08:17] the issue is probably that lp's mirror-branch-pull makes bad branches [08:17] mwhudson: ^ [08:17] I think LP is planning to upgrade to 1.14 more-or-less as soon as its out. === BasicPRO is now known as BasicOSX [08:18] for now foo.py on the 1.13 branch is probably a good idea [08:19] Is there a release date scheduled for 1.14 yet? [08:19] "soon" :-) [08:19] BasicOSX: Is there a listing of current blockers? [08:19] just 1, my time [08:21] BasicOSX: So there aren't any critical bugs left? [08:22] none that I know of, but that normally does not get revealed until I put the last call for merge for release to the mailing list [08:22] BasicOSX: lol [08:25] BasicOSX: Just Do It [08:25] lifeless: ok, I'd like to get 1.13.2 out before switching gears [08:25] BasicOSX: I'm asking because I'm eager to use the new join support for vendor branching. [08:31] BasicOSX: can you pastebin the traceback from your .bzr.log for that error? (Or use -Derror) [08:31] BasicOSX: it probably won't tell us much, but just in case... [08:31] BasicOSX: (but don't let that stop you from doing the release!) [08:34] I opened bug report, it's all in there Bug 368418 [08:34] Launchpad bug 368418 in bzr "ERROR: Revision X not present" [Undecided,New] https://launchpad.net/bugs/368418 [08:36] GAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH [08:36] DAMMMMMMMMMMMIIIIIIIIIIIIIIIIIIIIIIIIITTTTTTTTTTTTTTTTTTTTTTTTT [08:37] lifeless: why does revert with no arguments not present a warning? [08:37] mtaylor: because its safe? [08:37] * wgrant points out that 'bzr revert' backs things up first. [08:37] lifeless: um, no [08:37] mtaylor: it backs everything up [08:37] it does? [08:37] oh thank god [08:37] *.~N~ [08:37] mtaylor: except for things that are unaltered [08:37] It's not like Subversion. [08:37] how do I un-revert [08:38] mtaylor: thats a little harder, [its not automated] [08:38] lifeless: that's fine ... I just reverted about 3 hours of hacking [08:38] mtaylor: also, if you want it to be able to be configured to warn, like rm -rf can be, that would be fine [08:38] in the wrong window [08:38] but it shouldn't be the default, its an unbreakme option :) [08:38] lifeless: that would be nice... this is not the first time I've reverted [08:38] agree [08:38] because, if it did ask, you'd hit Y by muscle memory and have the problem anyway [08:38] so... are there docs somewhere as to how to un revert? [08:39] well you have the list of changes in the output from revert [08:39] just look for those backup files and put em back [08:40] lifeless: gotcha. rock! [08:47] lifeless, wgrant: you have saved my life (as usual) [08:50] anytime (that I'm awake :P) [08:55] reverts backups are so annoying [08:55] revert's* [08:55] you can configure it I think [08:56] lifeless: I guess I could alias to no-backup [08:56] lifeless: but i much prefer the shelve all workflow [08:56] lifeless: and then clearing the shelf [09:05] wtf [09:05] svn obliterates uncommited working tree changes on up [09:08] spiv: 1.14rc2 branches just fine, I don't feel comfortable releasing 1.13.2 (2nd regression) unless I can get some dev feed back that the issue is local to just me [09:09] BasicOSX: I'm about to update the bug [09:09] BasicOSX: I can reproduce too when I branch to a standalone branch. [09:10] ok, well, 3am, real job in 5h, so bed time for me, will work on it again tonight [09:10] BasicOSX: ok, sleep well [09:10] yes, dreams of swine flu :-( [09:13] BasicOSX: *oinksneeze* [09:22] BasicOSX: ok, I've narrowed it down some, it's to do with that change I landed in bzr.dev today. [09:48] Morning all. Anyone using bzr with trac? I'm having a weird problem where trac only shows me the files from my last checkin regardless of what branch I'm browsing. === thekorn_ is now known as thekorn [10:34] Hi all, I'm trying to push on a mounted webdavfs, unfortunately, I believe somethings goes wrong with the latency... [10:35] Knowing rsync works correctly but not cp -R [10:35] is there someone who managed to work with webdav? [10:36] there's a webdav plugin for having bzr push via wedav [10:37] I know, but there is a bug with iDisk [10:37] And I can't use it [10:38] This is why I tried to mount directly the webdav disk [10:38] But with no more success :-( [10:44] BasicOSX: its not a problem with the tip, its the other ongoing issue we're debugging [10:44] BasicOSX: I suggest not blocking on it [13:49] night all [14:07] hey, I want to use trac with bzr, but I don't want to install the .deb b/c the package manager want to install alot of other packages, any idea how I can just install trac-bzr [14:10] Are they actual requirements, or just recommends? [14:10] IIRC apt now installs recommends by default.. you can ignore them [15:10] does bzr support something like svn:external? [15:11] mrbrocoli: Not yet. [15:11] It's been sort of partially experimental since...1995? [15:11] hehe [15:12] mrbrocoli, abentley is working on finishing the implementation [15:13] I hear that it will be widely available in the next release or two [15:13] hi Peng_ :) [15:13] Hello. :) [15:13] nice, thanks for the info! [15:47] Wait, "nosmart+lp" works? I totally didn't know that! === jelmer is now known as Guest30662 === jelmer is now known as Guest10759 === Guest10759 is now known as jelmer === ja1 is now known as jam === thekorn_ is now known as thekorn === jelmer is now known as Guest94894 === dereine[OFF] is now known as dereine [16:54] whats the best way to work on 2 seperate features at the same time [16:55] Two separate branches? [16:55] ah never thought of this [16:55] thx! [17:33] say I had a branch for project/ and a separate branch for project/docs, with no common ancestor, is there any way to consume docs into the project branch without losing all the history? [17:34] Ng: "bzr join". You might have to upgrade to an experimental disk format, or you might not. I don't remember. [17:34] interesting [17:35] how experimental? will any puppies be endangered? ;) [17:35] (and could the resulting branch merge back into a non-experimental one?) [17:38] Ng: it would need to be rich-root version of a format, of which there are vegetarian varieties. However, they are a trap-door format (with good reason), so they couldn't be merged back [17:38] there is a merge-into plugin that John wrote to do this [17:38] it doesn't require a format bump, but works best at one-off conversions [17:40] james_w: thanks :) [17:43] rich-root formats are not experimental. Everyone'll need to upgrade eventually anyway. === beuno_ is now known as beuno === dereine is now known as dereine[OFF] === dereine[OFF] is now known as dereine [18:26] mwhudson: BTW, Loggerhead memory usage is staying far lower than it used to; like 60 MB. However, it still creeps up slightly over time. That may be okay or it may not; I dunno. === dereine is now known as dereine[OFF] [19:59] Running "bzr check" after upgrading bzrtools to rich-roots, there were 23 inconsistent parents there weren't before. === dereine[OFF] is now known as dereine === dereine is now known as dereine[OFF] === dereine[OFF] is now known as dereine === dereine is now known as dereine[OFF] === dereine[OFF] is now known as dereine === dereine is now known as dereine[OFF] === dereine[OFF] is now known as dereine [21:16] Peng_: good to hear, thanks [21:18] :) === beuno_ is now known as beuno [23:22] BasicOSX: is 1.14 out yet? :) === dereine is now known as dereine[OFF] [23:54] mwhudson: ran into bug with bzr.dev and ghosts which slowed me down, but lifeless said don't let it block me, so working on it right now [23:55] bummer make dist-check fails, investigating