[00:01] very much so [00:05] hello jelmer [00:05] and lifeless and gary [00:05] hai [00:08] jelmer: when you use bzr-svn on a svn repo that's had changes merged from a branch into trunk [00:08] jelmer: not all bugs need tags :P [00:08] will bzr see the history of changes to a file on the branch before they're merged in? [00:09] hi poolie [00:09] poolie: In what context? [00:10] lifeless: It's so easy to add them now I'm trying to add some that seem relevant when possible [00:10] lifeless: I find them useful when looking for dupes [00:10] i think it's worth adding tags about proportional to the frequency you use them [00:10] i didn't use them much previously, now they're a bit useful [00:11] jelmer, well if you run log or annotate within bzr for example [00:11] the specific case was [00:11] being able to edit them without having to go to a different page makes them a lot more useful [00:11] > 1. import /trunk/foo.txt [00:11] > 2. branch /trunk to /branches/mybranch [00:11] > 3. edit /mybranch/foo.txt [00:11] > 4. merge /mybranch to /trunk [00:11] will bzr see step 3? [00:12] jelmer: I think tags that are reused a lot are great [00:12] poolie: depends on how (4) was done [00:12] poolie: if it was a merge done using bzr and pushed using bzr-svn, then bzr will see it [00:12] jml: is bzr 1.16 in any ppa yet? [00:12] poolie: otherwise, it won't, even with svn 1.5 (since it only supports tracking cherrypick merges, not "full" merges) [00:13] jelmer: but when there are few bugs for that tag its no better than searching [00:13] lifeless: right [00:14] mwhudson: "apt-cache madison bzr" [00:14] well, assuming you have them all added [00:15] poolie: rmadison bzr [00:15] oh damn [00:15] ppas [00:15] rmadison should be able to query ppa [00:15] what's rmadison? [00:15] seems not [00:15] remote madison? [00:15] yah [00:15] queries lp/debian [00:16] rmadison -u debian bzr [00:17] jelmer: in the mail i have, the person asserts that svn can follow the distory of that file [00:17] maybe because it didn't exist on trunk at all before the merge? [00:18] so svn just represented it as a copy (speculating) [00:18] in that case i think bzr-svn will track it? [00:20] spiv: ping [00:20] where should we put the ppa debs? [00:20] i guess we could manually maintain an archive somewhere... [00:21] poolie: svn would be able to see which revisions have been cherrypicked onto trunk [00:21] poolie: but bzr isn't able to deal with cherrypicks, so bzr-svn ignores that data [00:22] poolie: it could do analysis to see if a range of merged revisions is a "full" merge and then add the appropriate parents, but I'm worried about the performance of that analysis if it has to be done for each revision and it seems like it'd just be a stopgap until proper cherrypicking tracking is in place [00:24] right [00:30] Hi poolie [00:33] spiv, any ideas about bug 389087? [00:33] Launchpad bug 389087 in bzr "ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ..." [Undecided,New] https://launchpad.net/bugs/389087 [00:35] jml: mwhudson: thumper: is https://bugs.edge.launchpad.net/bzr/+bug/372881 still affecting you ? [00:35] Launchpad bug 372881 in bzr "RevisionNotPresent in insert_record_stream - bzr cannot branch from rocketfuel" [Critical,Confirmed] [00:37] lifeless, I couldn't say. [00:38] lifeless: haven't heard anyone complain about it for a while [00:39] jam: i'm back to where I was at 16:45 EDT. what is this trace class of which you speak for me to trace.mutter ? [00:40] nvm, google first. [00:40] lifeless: not me personally [00:48] will mutter messages always been output to STDOUT or STDERR? [00:49] jrwren: only to ~/.bzr.log afaik [00:49] If I have two different features to implement and propose for merging, should I use one branch for each one, or one single branch? [00:50] i don't have that file, do I need to touch it? [00:50] or maybe on windows it goes to that APPDATA place? [00:50] RenatoSilva: Two branches, if it makes sense. Obviously, if one depends on the other, that'd be harder. [00:50] Could still use looms, I suppose. [00:51] Peng_: the problem is that the branch is a bzr plugin, and I'm using both modifications locally. They don't rely on each other, but I do reply on both of them :) [00:53] Peng_: maybe I could have 3 branches locally, 2 of them for development, and one for local use. I would merge the 2 branches into the thrid one once in a while. How about it? [00:54] RenatoSilva: Sure. [00:54] ok, thanks [01:01] lifeless: pong [01:02] network deltas [01:02] I'm blocked on check, and picking the next thing to do [01:03] How do people usually submit one-line patches to LP projects? Branch it and request a merge? Just file an LP bug? === ddaa1 is now known as ddaa [01:04] #launchpad might have a better answer; I'd say branch and submit a merge (without doing that its rather hard to test :P) [01:04] but if its just a typo or something, sure abug with a diff inline [01:05] * ebroder nods [01:05] whatever gets the devs attention and is appropriate for the ammount of work really [01:05] *shrug* I'm used to the amount of prep work for a fix being disproportional to the fix itself :) [01:06] poolie: regarding that AbsentContentFactory bug, it's almost certainly a dupe of 354036, those are both stacked branches that were created before 1.14.1. [01:06] (and I see it's already been marked as a dupe) [01:07] spiv: 'network deltas' wass in reply to your pong [01:10] spiv, lifeless, thanks, i thought it probably was [01:10] poolie: 'bzr info ' is a fast way to check if branches are stacked [01:11] lifeless: network deltas would be great to do, I still haven't got to them :( [01:13] lifeless: i know, why? [01:13] i mean, why do you mention that? [01:14] poolie: just seemed like the time to handoff that bug was about the same as doing a quick check and duping [01:16] Peng_: optionally, I can merge the 2 branches to the 3rd one, and keep the merge uncommitted. When I have new changes in the 2 branches, I just bzr revert and merge again. I think it's the easiest way... [01:17] sigh [01:17] poolie: it was just a though [01:17] t [01:17] if you actually mean to say "checking that it's stacked is a 100% reliable way to know it's a dupe" then that i didn't know [01:17] and i'm not sure i believe it [01:18] poolie: its extremely high probability. In this particular case I know 100% that the current branch was a dupe, because I ran the fixer and it found missing inventories. [01:18] ok [01:18] poolie: the lp-code people have not yet run the fixer across launchpad stacked branches [01:18] humm I can't merge twice without commiting the first merge :( [01:18] RenatoSilva: you can by passing --force to merge; but its unusual to do this. [01:19] jam, are you still around? want to talk sometime? [01:19] lifeless: I'm afraidn you're following the discussion, but I think it's a good solution in my case, I'll try --force, thanks! [01:20] clear [01:20] I did follow it. [01:20] clear [01:20] lifeless: ok [01:21] Is there a technical reason why the text metadata in a bundle all has to come at the beginning, _above_ the patch? Could we not have a one or so line header [01:21] the 3rd branch is read-only [01:21] # Bazaar merge directive format 3 (Bazaar 1.17) [01:21] and then the patch [01:22] and then the revision id crap? [01:22] or better yet, [01:22] AfC: probably not a good reason [01:22] possibly showing the target branch there is useful [01:22] RenatoSilva: that doesn't make a difference AFAICT [01:23] RenatoSilva: doing merge,commit,merge,commit and merge,merge--force,commit is not altered by the read state of the third branch [01:23] poolie: oh, still showing it (if necessary) but down below, after the patch, above the base64 [or whatever] blob of data [01:23] jam, nice work on bug 345998 [01:23] Launchpad bug 345998 in bzr "MYSQL/BZR P3: Python-based Windows installers are not available for python2.6" [High,Fix committed] https://launchpad.net/bugs/345998 [01:24] lifeless: I mean that I won`t deliver the 3rd patch [01:24] lifeless: If I want to change something, I will do it in the other branches [01:25] lifeless: s/3rd patch/3rd branch [01:35] lifeless: how soon do you think 1.16 will be released? (as in installable on an ubuntu box) [01:35] s/lifeless/poolie/ [01:35] clear === abentley1 is now known as abentley [01:37] lamont: PPA should be up shortly [01:37] johnf is reasonably prompt [01:37] yay [01:38] he offers a two day SLA [01:38] but - 1.16rc1 is pretty close to 1.16. [01:38] actually, there's a 1.16-1 in debian, I assume that should just work, no? [01:38] and thats alrady in the ppa [01:38] I'd expect so,yes [01:38] just get it synced() [01:38] lifeless: I'm pretty sure you know why I'm asking, and what the rules are for me to live within. [01:39] lamont: wasn't, but just noticed now. [01:44] jam: are you still around at all? [01:46] jelmer: help me understand https://bugs.edge.launchpad.net/bzr/+bug/386079 [01:46] Launchpad bug 386079 in bzr "bzr-svn throwing procedure entry point errors" [Critical,Confirmed] [01:49] lifeless: as far as I've understood it the problem is that if there's other svn dlls in directories in PATH those get used rather than the DLLs that subvertpy was linked against [01:51] lifeless: so it's probably not important enough to be critical, but John would be better able to tell you [01:53] thanks [01:57] lifeless: I got my widget to load lazily :-) And so for working trees, I only create copies of items that are shown. [01:59] james_w: if you're around, is there a good link on bzr packaging at the moment? [02:00] lifeless: in the painful case, it's a merge of the diffs in 1.15->1.15-x to s/5/6/g [02:00] there are diffs? [02:00] which is part of why I got out of that business [02:01] apt-get source is your friend [02:01] some of them are only a diff in debian/changelog [02:01] garh [02:01] others have debian/control and debian/rules changes [02:01] others... well, ISTR one setup.py patch one time [02:02] jml, lamont suggests not doing the announcement mail until we have installers for say ubuntu and windows at least [02:02] interesting idea [02:03] I don't like it [02:03] because redhat + bsd + suse etc [02:04] unless we want to take responsibility for building all of them too [02:04] lifeless: I do. makes it get done before I get the privilege of explaining that it's not out to people who think I should install it NAO [02:04] lifeless: you could block on $everyplatform - that'd be more software industry standard [02:04] poolie, for that to work & still have time-based releases, building those installers would have to be the RM's job, I think. [02:04] lamont: the people in question should know better :) [02:04] well, making sure that someone builds it [02:05] poolie, which would mean that building those installers would have to be as easy as falling off a log. [02:05] it tends to make the RM's job bigger [02:05] if I have a light weight checkout, can I just switch the underlying repository format under it? [02:05] which is undesirable [02:05] thumper: probably yes [02:05] thumper: yes [02:05] move my packs repo out of the way, move 2a in and have it work [02:05] cool [02:05] oh [02:05] poolie, making sure someone builds it drags out the process further, because of hand-offs & TZ issues. [02:05] actually 'no' [02:05] thumper: the root data in the dirstate will be invalid [02:05] lifeless: why? [02:06] of course, its likely that I've just realised that 'bzr upgrade' has a critical bug with respect to rich root changes [02:06] :( [02:08] thumper: recreate the tree [02:08] ok [02:08] thumper: you should do this for all trees when you upgrade the repo across a model change (non-rich-root to rich-root) [02:08] ok [02:09] lifeless: if the announcement said "we'll have binaries shortly" or some such, that'd help. [02:09] i think it normally does [02:09] right now, if I go to bazaar-vcs.org and click on what appears to be the link to go get ubuntu install info for 1.16, I get.... 1.15-1 [02:09] which is kinda confusing to a newbie [02:09] which link? [02:10] Downloads and installation instructions [02:10] then [02:10] ppa repository, [02:10] downloads and install being a link under 1.16 [02:12] which, of course is one of 2 ways that I check to see if it's out already. [02:12] the other being apt-get update; apt-get showsrc bzr | grep Version [02:13] lifeless: branching from my server to my laptop where both repos are 2a over bzr+ssh I'm getting CPU maxing on the server, and very little network traffic [02:13] lifeless: fetching revisions [02:13] clear [02:14] thumper: is it an initial branch? [02:14] thumper: that is, is the target repo empty? [02:14] anyway, family time gluing a floor down. later. [02:14] lifeless: yes [02:14] ciao lamont [02:15] bug 388269 [02:15] Launchpad bug 388269 in bzr "getting a branch into an empty shared repository takes a long time to figure out revisions to send" [High,Triaged] https://launchpad.net/bugs/388269 [02:15] * thumper nods [02:15] ok [02:16] we probably want this fixed before everyone tries to grab LP :) [02:17] not going to happen [02:17] theres a bunch of stuff we /have/ to get done which if we don't things will be consistently bad much more often [02:18] and you have a fixed date for the LP code; I don't see us getting through everything for 2 before then; *if* we do then perhaps - but this isn't a regression [02:18] its been like this for a long time, and the LP code base is no worse than mysql's, AFAIK [02:33] lifeless: ...I totally didn't know about merge --force. I'll have to remember that! [03:20] igc1: ping [03:22] jelmer: hi [03:22] jelmer: I have a small request for you while you are touching bugs [03:22] I'm new to bzr and am trying to figure out a way to merge converted repositories. [03:22] ahn: What exactly do you mean? [03:23] jelmer: as you qualify as a dev, perhaps you could try to move the bug forward a step at the same time? [03:23] I have a bzr repository A, which is a conversion from CVS with full history, that includes versions from say 2000-2005. [03:23] I have a bzr repository B, which a conversion from darcs with full history, that includes version from say 2006-2009. [03:23] I'd like to know if there is a way to essentially "concatenate" the two repositories so that the histories are in series. [03:24] jelmer: specifically, after you touch it, it should be either incomplete needing more info, waiting for someone more knowledgable than you to comment/analyse, or ready-to-code. [03:24] jelmer: ^ not a requirement, but if you can, its actually more useful than merely categorising many bugs to do that to a smaller number of bugs [03:25] ahn: what you may find works best is to export B as a fast-export and use fast-import to append it to A [03:25] lifeless: fast-import appends to an existing repository while preserving full history? [03:26] I'm fairly sure it can [03:26] of course, work on a backup until you've got the process tuned for you [03:26] fast-export and fast-import are in the bzr-fast-import plugin [03:26] I will investigate, thanks. === mark|autoconnect is now known as mm-mysql [03:47] jelmer: FYI, you had a revision of bzr-rebase's trunk that marked it as compatible with bzr 1.16 and 1.17, but it's been replaced by the 0.5.1 release. [04:34] i am trying to get another project member using bzr [04:34] he he is running into all sort of porblems like this [04:34] http://pastebin.com/d58e1f99 [04:34] treeform: use a newer version, that bug was fixed [04:35] lifeless: thanks! [04:36] lifeless: hmm there is no 1.1.6 windows build yet [04:36] 1.1.6* [04:36] grr [04:36] 1.16* [04:37] should be a 1.15.x one though [04:37] no they got new on up in another place [04:38] https://edge.launchpad.net/bzr/1.16/1.16 has windows builds [04:38] thanks [04:38] but its not main link at the site === igc1 is now known as igc [04:40] hi all [04:40] pong lifeless [04:40] sup igc [04:41] igc: iter_changes; are you blocked/its on the shelf/its all done vis-a-vis commit? [04:41] igc: if its on the shelf I may do it next week [04:42] treeform, is now :) [04:42] lifeless, it's on the shelf for at least a few more days [04:42] (yay wikis) [04:42] igc: if you got to it, that would be really great [04:42] lifeless: ^^ [04:42] igc: ok. Monday I'll page it in and make a call about doing it/not. [04:42] jml: i love open source :) [04:43] lifeless: sweet. I did put a fair amount into it but nothing beyond my initial terrible-to-ok-but-not-great patch that's worth sharing [04:43] igc: kk [04:49] "bzr: ERROR: Unable to look up default port for ssh" ? [04:49] hmm its 20 or 22? [04:50] should bzr know that? [04:50] 22 wins! [04:50] never seen that error before [04:50] you might like to file a bug [04:51] http://pastebin.com/d79ccb48f [04:51] i think his problem is that [04:51] he cant break lock [04:51] because of this stupid ssh error [04:51] and he cant rebind [04:51] because of the stupid lock [04:51] if you run with -Derror you will get a backtrace that may help debugging [04:52] is there a way to break lock manually? [04:52] I'm not sure why you have a lock that needs breaking anyway [04:52] that should be very rare [04:52] treeform: have you tried "bzr break-lock bzr+ssh://host:22/..." ? [04:52] no [04:52] there is no lock on the server [04:52] its local [04:52] i ran bzr break-lock on the server [04:52] nothing cameup [04:53] run bzr unbind; bzr break-lock; bzr bind [04:54] Also, maybe your %SYSTEMROOT%\System32\Drivers\Etc\Services [04:54] needs fixing? [04:54] (that's just a wild guess, though) [04:54] the backtrace will tell us [04:56] hmm [04:56] how to disable default bzr-tortouze stuff on windows? [04:56] his computer is lagging like hell because of it [05:38] treeform: I'm not sure [05:44] i think i found it [06:33] any bzr-eclipse folk here? [06:42] hey folks [06:43] workflow question: i'm working on some code, i want to merge in upstream changes. i get the message "ERROR: Working tree "blah blah/" has uncommitted changes" [06:43] what are my reasonable options here? [06:43] either commit before merging, or shelve before merging [06:44] merging changes your tree and then you need to commit what you merged [06:45] what i want to do, is bring in the new changes, and then carry on with what i was doing. [06:45] to do that, do i shelve, merge, unshelve? [06:45] shelve; merge; commit; unshelve [06:45] ahhhh [06:45] okay [06:45] thanks! [06:45] or [06:45] commit; merge; commit [06:46] depending on whether you have reached a suitable point to commit your own changes [06:46] yeah, i haven't [06:47] okay, i just did bzr shelve, and then y y y y [06:47] but bzr status still shows modified files [06:47] do i need to manually rever them? [06:47] by manually i mean, explicitely, with bzr [06:47] uhm [06:47] and/or: won't merge still complain? [06:48] 'bzr shelve --all' should save everything such that 'bzr st' will show no changes [06:48] okay [06:48] if it doesn't, what bzr version are you using? [06:53] --all did it [06:53] i wonder if i was hitting y / return so fast that it missed a couple ys [06:55] johnjosephbachir: I'd say so ;) [06:55] hi people [06:55] my kitteh just managed to catapult my spoon out of my cereal bowl, so my monotor was covered in soy milk spatter [06:55] (it's a lappy) [06:56] it looked like someone has been looking at pr0n [06:56] *monitor === ttyType is now known as bizarrefish [07:19] anyone want to comment on the proposed phrasing in bug 346677? [07:19] Launchpad bug 346677 in bzr "message about launchpad-login is confusing" [Medium,Confirmed] https://launchpad.net/bugs/346677 [07:41] poolie: commented [08:27] thanks spiv === mthaddon is now known as afk [08:39] hmm lifeless, jml windows bzr just not working for us... the guy i was working with gave up [08:40] treeform, that sucks. [08:40] i dont know what to do [08:40] i been using bzr for so long [08:41] but when other people try to use it it just breaks for them [08:41] treeform, there's a couple of things I can think of. [08:42] part of the problem might be that the bzr repo is 1GB of data [08:42] treeform, the first is look for the failures in Bazaar's bug tracker: https://bugs.launchpad.net/bzr [08:42] and we dont have great network connectsion [08:42] so its always a bother pushing this much data around [08:43] jml: i have opend some bugz in that list [08:43] treeform, although my mental powers are to be greatly feared, they do not extend to mind-reading. [08:44] hi all [08:44] well what do you want me to do? [08:44] treeform, explicitly describing the observed failures is often half the battle. [08:45] yeah [08:45] vila, hi :) [08:45] treeform: where did you get stuck with your friend? [08:45] when working with some one who is not verly technical its a real pain [08:45] jml: hey ! [08:45] I'm not really here right now [08:45] but I'd say [08:45] be sure they don't run random commands, if they are having trouble flailing will make it worse. [08:45] if bzr gives an error that you don't recognise file a bug etc [08:46] well it started out with sftp [08:46] basically i did an update [08:46] it did a repack [08:46] and it when redownloading everything [08:46] so i say [08:46] hmm [08:47] ok lets switch to bzr+ssh [08:47] just kill the update [08:47] which was running now for 2 hours [08:47] so he broke it [08:47] now lets rebind [08:47] cant [08:47] its locked [08:47] lets break lock [08:47] cant break lock [08:47] then you guys suggested to update [08:47] ok we update [08:47] still cant break lock [08:48] because now we cant ssh [08:48] so another thing broke during update [08:48] on the other hand i cant really blame bzr [08:48] because its turning more into people problem then a software problem [08:48] --- end of rant --- sorry [09:05] * igc dinner [09:17] treeform, the situation certainly sounds complex. [09:17] treeform, maybe sending an email to the bazaar list is your best bet. [09:18] bzr is being blamed for making computer run really really slow [09:18] it can be a virus [09:18] he is uninstalling to conform === jtv1 is now known as jtv [10:09] jml: more bzrlib complications... I think I need to get a trans-id for a directory in my revision tree. [10:09] I know how to get its id, but not its trans id. [10:11] doesn't exist [10:11] trans-ids only exist during a tree transform, they are transient [10:11] why do you think you need it [10:11] ? [10:16] lifeless: nm, I've got it now, from the transform preview. [10:16] lifeless: this is still for the direct-commit-to-branch stuff. [10:56] spiv, lifeless, bug 389413 is strange [10:56] Launchpad bug 389413 in bzr "ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex()) is not locked running diff across hpss" [Medium,Confirmed] https://launchpad.net/bugs/389413 [10:57] is that a dupe maybe? [10:57] poolie: are you burning out? logoff :) [10:57] mm, why? [10:57] should i know what it is? [10:57] I think he's saying it's nearly 8pm :) [10:57] no, uhm have you seen Jono's talk on burnout? [10:58] (I'm certainly about to logoff...) [10:58] i believe it is that time in the northern suburbs too :) [10:58] i am too actually [10:58] i'm staying on because i'm enjoying it [10:58] I'm online, but doing personal stuff [11:00] poolie: if it's a recent regression, the traceback suggests it may be fallout from my get_rev_id_for_revno patch. [11:01] mm i thought so [11:01]