[00:38] hi! I'm trying to write a python program that uses bzr lib to take a series of revisions in one branch A and re-applies them to a subdirectory of branch B (A and B are different and have no common history in bzr, although in reality they do) [00:39] i've managed to get the logger to output a patch for each revision in the gap i want [00:39] but... a) i'm sure there's a better way and b) i'm wanting the metadata as a sep object so that I can construct a commit message. [00:40] I'm also having some issues of revno versus revid and wondering why the difference? as in, why can't i just use the full id everywhere? [00:43] hi stewart... things have been rather dead all day here to warn ya. I suspect the regulars are on their weekend :) [00:43] it might be worth posting the questions to the mailing list? [01:23] stewart: I can't help you with the bzrlib stuff. But the reasons for revno vs revid is that they have different properties of permanence and convenience. [01:23] Certainly you _can_ just use the revid everywhere. [01:23] hi stewart [01:23] fullermd, not in bzrlib calls it seems. i get strange errors passing things around. [01:23] thumper, hi! [01:24] stewart: have you looked at a plugin that has replay? [01:24] stewart: it may not do exactly what you want [01:24] stewart: but may be close [01:24] thumper, haven't seen one... [01:24] * thumper wonders where replay lives [01:24] bzr-rewrite i think [01:25] Mmm. I'd be tempted to assume an API that requires a revno and refuses a revid (other than ones inherently biased to that of course) is a bug... [01:25] stewart: I agree with fullermd about the revid thing [01:25] most of the things i've seen have either been a) epically undocumented or b) tries something with ids of files :) [01:25] stewart: I use revid almost everywhere in bzrlib calls [01:25] Oh, well, stuff with file-id's is totally outside that axis :) [01:26] a revno is a valid revision speci [01:26] as is revid:some-long-id [01:26] at least I think so... [01:26] s/speci/spec/ [01:26] most bzrlib calls will work with revision specs [01:26] thumper, check out my loop in http://paste.drizzle.org/show/65/ - the obvious of passing in the id from iter_merge_sorted_revisions to make_log_request_dict ends in an error for me. [01:26] Revision specs sit way up at the top of the API, right below the UI. [01:28] stewart: why are you wanting to convert a revid to a dotted revno? [01:28] for log.make_log_request_dict ? [01:28] thumper, i don't know. [01:29] thumper, an attempt to get it to work :) [01:29] stewart: so... you are trying to get the diff for a particular revision? [01:29] thumper, yep. [01:29] thumper, to then apply to another tree. [01:29] stewart: there are definitely easier ways of doing this [01:29] * thumper wants a simple way to do this too [01:30] abentley pointed me at some docs [01:30] let me see if I can find them [01:30] thumper, just for reference, the config file being used is http://paste.drizzle.org/show/66/ [01:31] thumper, the next step is to parse the revision and work out if it would apply or not. as i only want revisions that touch a certain subdirectory :) [01:31] http://doc.bazaar.canonical.com/developers/integration.html was the doc, but it doesn't give an example of getting the diff [01:32] stewart: I know there is a relatively simple way to get an iterator of the changes [01:32] stewart: and check the files for each change chunk [01:32] stewart: so it shouldn't be too hard... [01:32] * thumper thinks [01:32] we do get diffs for particular revisions in LP [01:32] like in the outgoing email [01:32] * thumper checks the code [01:36] gah [01:37] sometimes the bzrlib code reminds me of looking at zope internals [01:37] stewart: I'll point you at the bzrlib.diff file [01:37] thumper, luckily, i've never had to deal with zope internals [01:38] zope internals are AMAZINGLY convoluted [01:38] stewart: http://paste.drizzle.org/show/67/ [01:38] thumper, it would be nice if a bunch of this was exposed via command line interfaces too. for the purposes of what i'm doing now, a list of revisions and a loop in shell would have been fine :) [01:38] stewart: that is how we get a text representation of the diff between two revisions [01:38] stewart: yep... [01:39] stewart: luckily bzr plugins a pretty easy to write [01:39] stewart: to actually get to the guts of the diff, you need to look at the differs [01:40] stewart: how about this: http://pastebin.ubuntu.com/510517/ [01:40] stewart: IIRC you get some form of iterater over changes [01:41] stewart: then for i in $(seq $(bzr revno)); do bzr diff -c $i > $i.diff; done ? [01:42] mwhudson, relatively close... the next step being to have teh diff in a variable that i can analyse and change before applying to another tree. [01:42] stewart: use a stringio instead of a real file? [01:43] mwhudson, looking [01:43] * stewart not a python programmer. is ENOTPERL :) [01:43] or, rather, ENOTC [01:43] hi stewart, mwh [01:43] poolie, hi! [01:43] I heard of somebody once doing some stuff with bzrlib via Inline::Python or something ;) [01:43] * thumper leaves stewart in poolie's capable hands [01:45] Hi poolie [01:45] hi spiv, how are you? [01:45] i thought today i'd try to clear the queues a bit, both mine and others- [01:47] Sounds good. I'm going to finish up my split-NEWS branch, then also look at the review queue, seeing as I promised vila I'd look at some of his patches :) [01:47] k [01:47] stewart: are you all set now? [01:48] poolie, possibly... enough to go occupy myself for a while at least :) [01:53] Bazaar doesn't use blueprints? (according to launchpad) [01:54] Should I just write up my proposal on the mailing list, then? Or propose an Ubuntu-level blueprint for UDS? [01:59] The mailing list is a good place for discussion. For work-in-progress documents (which can include proposals) you could consider a merge-proposal to add to doc/developers/, or a wiki page... and probably post to the list about it. [01:59] jbowtie: for what proposal? [02:05] poolie: My binary diff/merge proposal. Right now it's sitting in a text file on my hard drive. [02:06] I was thinking of splitting it into three blueprints: core changes, archive handling, GIMP xcf file handling. [02:06] ok [02:06] i'm coming to think that doing blueprints [02:07] can be most useful if you're clear what you're trying to achieve [02:07] (which sounds obvious) [02:10] ..and therefore? [02:14] poolie: you may like to know that consolidation of the various trackers in LP is back on the table [02:15] sorry jbowtie, distracted [02:15] therefore, are you writing this [02:15] - to get it straight in your mind [02:15] or [02:15] - to make sure no one objects later or [02:15] - to get other people to find mistakes before you do or [02:16] - because you want other people to actually do it.. [02:16] etc [02:16] i think the spec tracker is most useful, perhaps, when there is a long dependency chain and the person writing the spec is not the one who will implement it [02:16] but that's not really true for us [02:17] so for you, i think just sending mail and then turning the thing into user-oriented docs should be enough [02:17] don't send mails that are individually too big or you may swamp people and they'll glaze over [02:18] OK, that sounds reasonable. I'll split it up into bite-sized pieces for the mailing list. [02:19] may also help to think 'what is the simplest thing in this direction that could possibly help?' [02:19] Is it helpful to create a tracking bug for future reference? Once I have some consensus, of course. [02:20] Or is better to just wait until I have a branch with something implemented. [02:32] jbowtie: well, do whatever helps you best [02:32] my feeling is that bugs generally should be something where you can say when it's done [02:32] or at least you should be able to decompose them into that [02:33] so a bug like "should support managing non-source files" is kinda true but it's pretty hard to say when you have enough "support" [02:33] but if you make it something more specific about diffing an archive by diffing the components [02:33] it's more clear what's needed [02:34] and you can always file more bugs ify ou want more [02:36] spiv, in https://code.launchpad.net/~mbp/bzr/http-messages/+merge/37931 i'm inclined to just land it [02:36] poolie: +1 [02:37] thanks [02:38] poolie: I can definitely think of more nice-to-have things (e.g. checking for content-type == text/html before munging), but I'd rather have it landed than wait for polish that will rarely matter. [02:39] mm [02:39] this area is in practice really messy [02:39] Yeah, exactly. [02:39] exhibit A, the tendency for browsers to hide the error message together even though it's html [02:39] So I'm happy for incremental improvements to be driven by practical experience. [02:39] Rather than what I think would be nice-to-have :) [04:30] spiv, i don't know if this was you but "compatibility breaks" seems to list a lot of internal changes at the moment. [04:30] or were you trying to fix that? [04:33] I don't recall doing anything to cause or fix that. [04:33] I did move some news entries to b3 that were misattributed to b2, I don't think that involved any recategorisation thouhg. [04:34] k [04:35] i might fix them up but i don't want to clash with your splitting-up branch [04:35] It shouldn't clash, or if it does I think I can cope without undue pain. [04:45] still otp? [04:45] you know we could just keep NEWS for the current series and move it away for old ones [04:45] if that's an easier change [04:55] poolie: not otp, but still helping thumper somewhat [04:56] I think that's fractionally harder, actually, because it makes the build logic slightly more complex [06:02] Hi [06:15] hi afc [06:15] spiv, hi, iirc keyboardinterrupt is under systemerror, not exception? [06:16] poolie: in recent Python (definitely 2.6, maybe 2.5?) it is under BaseException but not Exception, yes [06:16] I'd be ok with catching and reraising it explicitly if you like [06:48] i think it's good the way it is [06:48] in general i think it's pretty important repr methods don't crash [07:02] morning [07:03] can someoned comment some of the points mentioned in regard to bzr in http://selenic.com/pipermail/mercurial/2010-April/031191.html ? [07:05] ah, i don't know [07:05] gour: most of those points are a matter of personal taste, as the poster says. [07:05] one benchmark recently found us faster than them on commit [07:05] and some other operations [07:06] but people who don't like that result can always find a different benchmark [07:06] spiv: in few places, iirc, i saw criticism at "bazaar relies on a linear integer index for its revision numbering [07:06] are there any consequences about it? [07:06] we have a deterministic numbering of revisions on any graph [07:06] gour: I've seen other people comment on how much they like our revnos compared to the other DVCS systems. [07:07] gour: matters of taste can have consequences :) [07:07] hg last i looked had a numbering that varied between different copies of the repo depending what order they pulled [07:07] spiv: heh [07:08] after mostly stopping using darcs, i used monotone a bit, which i like, but considering whether bzr/hg may be better due to wider support [07:09] oh, and for colocated branches, i think bzr-colo is very very nice [07:09] that's plugin? [07:10] yes [07:11] btw, what's with fast-import plugin after Ian left us? [07:14] No-one is actively working on it, but it also seems to be working very well for most people. [07:15] is there a way to list branches in a remote repository? [07:16] 'bzr ls' seems to only work on branches. I'm looking for some equivalent to 'svn ls .../branches/' [07:16] spiv: https://bugs.launchpad.net/bzr-fastimport/+bug/541626 [07:16] Launchpad bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors' (affected: 5, heat: 24)" [High,Confirmed] [07:17] gour: 'bzr ls' is for listing stuff within a branch. bzrtools provides a 'branches' command that lists branches under a given location. [07:17] (but only on indexable transports) [07:18] fullermd: you thought about glyph ^^^ [07:18] Bah. All you 'g' folk look alike :p [07:19] hi all ! [07:20] Well, there goes the neighborhood. [07:22] On the subject of neighbourhood, I heard complaints about goat smells.... [07:22] no pointing fingers of course [07:22] Goats? I don't see no *burp* goats 'round here... [07:22] hi vila [07:23] poolie: hey ! [07:23] fullermd: what makes a transport 'indexable'? [07:23] glyph: Roughly, "I can do ls on it" [07:23] glyph: the ability to list a directory [07:23] So e.g. http doesn't count. [07:23] PROPFIND! [07:23] sftp does. [07:23] you can hella do ls on http. [07:24] and webdav does [07:24] maybe we should do that [07:24] glyph: PROPFIND is for DAV and can work for more than just directories iirc [07:25] vila: I work on calendarserver.org, so I know _all about_ all the crap PROPFIND can do ;-) [07:25] but one of the things it can do is list a directory. [07:25] glyph: great ! :) [07:25] glyph: thanks for confirming :) [07:25] Doesn't the bzr-webdav plugin provide listdir? [07:25] * glyph tries 'bzr branches' on a few representative things [07:26] (Although you may need to use http+webdav as the url scheme) [07:27] spiv, glyph : yes, bzr-webdav does it (with PROPFIND ;-) but it's rather crude (from memory) [07:28] I haven't touch this plugin code for the last two years :-/ [07:28] err, last year [07:28] times doesn't fly that fast finally [07:47] poolie: so, I'd return a small class with __iter__ [07:47] poolie: -or- [07:47] poolie: there is a iter caching decorator around somewhere [07:48] i thought about that but it seems too easy to get it wrong and have it accidentally called earlier [07:48] its trivial, might want to embed it itself [07:48] and then i thought, yagni [07:48] load_tests is called barely any later than the test module is loaded, probably [07:48] so you just need to make sure any wanted stuff is created earlier [07:48] first iter it iterates its delegate, caches the results, etc [07:49] poolie: yeah, also in bzr's case its registries are initialized before any tests are laoded. [07:49] library init, plugin load, test load [07:50] right [07:50] i do think in the other course there are a couple of antipatterns [07:50] one is holding an iterator in a place where it could possibly be resued [07:51] because the second attempt will tend to just look like [] rather than an error [07:51] and the other is anything that takes "might be a callable or might just be the thing" tends to give a similar trap [07:52] poolie: I don't like the 'might be callable or object' either ;) [07:53] specifically saying '.scenarios' might be a list or might be callable (or a list of callables) is a dangerous idea [07:53] poolie: agreed; it is currently defined as 'an iterable' which implies 'not a generator' [07:54] (for it to be a generator it needs to be defined as 'an iterable which will be iterated once' [07:54] (as you know :P) [07:54] afk for a bit [08:03] spiv: I briefly looked at your split-NEWS mp, sounds nice, don't forget to fix all references and usage descriptions in docS though [08:04] vila: thanks [08:04] hi guys.... is there an easy way to get from the sha1 to the commit message for a given rev in a tree? [08:04] vila: it also needs some of the non-sphinx glue fixed up :/ [08:04] spiv: exactly, or we should accelerate the switch-to-sphinx work [08:05] peitschie: sha1 ? Did you mean revid ? [08:06] vila: as in the specific key that is printed in the sha1 static tuple thingy [08:06] peitschie: ECONTEXT [08:07] I put those little sheets in my dryer to avoid static tuple thingies. [08:07] peitschie: static tuple thingy? Are you trying to debug a traceback? [08:09] spiv: yup...repo keeps dying from bug #485601... i have tried reconcile and a few other things... but it works for a few commits then dies again [08:09] Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 13)" [Medium,Incomplete] https://launchpad.net/bugs/485601 [08:11] vila: so i have dropped into a pdb session and found NoSuchRevision( has no revision StaticTuple('sha1:9e2e17285dde089256cf0a2567416008c67559b4',)) [08:11] vila: I don't quite understand how to get the ECONTEXT from there however.... [08:12] poolie: https://code.edge.launchpad.net/~barry/bzr/609186-shortcuts/+merge/37787 might be a good place to play with your new ideas about load_tests, there are a nuch of very similar tests there that could be parametrized from the _ubuntu_series_shortcuts dict [08:12] poolie: there are fine *as is*, but look simple enough for you to play with too [08:13] peitschie: haaa. now you give me context :) [08:13] vila: I only just got the error back again :)... sorry! [08:14] peitschie: so this sha1 is not directly linked to a tree revision, more probably linked to a *file* revision, so the way to the commit message is a bit longer [08:14] peitschie: your original question isn't very on target, because that SHA-1 is not directly associated with a particular revision [08:15] (And quite possibly there are multiple revisions referring to that record) [08:15] spiv: indeed :). I'm trying to figure out the revision at which things are starting to go haywire :) [08:15] peitschie: you probably need to go up a bit in the stack... [08:15] peitschie: are stacked branches involved? [08:16] spiv: is a bound branch the same as a stacked? [08:16] peitschie: no [08:16] spiv: as far as I know I have no stacked branchs... I do have a local repo, with a bound branch that points to a remote repo though [08:16] peitschie: if you don't know what stacking is, and you aren't hosting the branches on Launchpad, then it's reasonably safe to say it isn't involved. [08:16] Is bzr-svn involved? [08:16] yupperz [08:17] sorry... need to clarify that [08:17] the central trunk code gets checked into is svn [08:17] poolie: oh, re-reading the comments on https://code.edge.launchpad.net/~barry/bzr/609186-shortcuts/+merge/37787, yes a helper first and on top of that the parametrization, I was thinking about adding the helper myself as part of landing, thoughts ? [08:17] so most dev changes are bzr => svn => bzr [08:17] having said that, this exact bug is bzr => bzr [08:18] peitschie: have you tried the suggestion in jelmer_'s latest comment? [08:18] (upgrade to bzr-svn 1.0.4 or newer and a fresh conversion from svn->bzr?) [08:19] spiv: that is likely a good place to start. I've upgraded and run reconcile on the central repository, but the challenge is the difficulty of migrating all teh version history across to a "clean clone" [08:19] *nod* [08:20] spiv: i'm not sure of an easy way to simply fetch all the ghosts from the old repository... or whether that might defeat the whole purpose of the clean clone and migration [08:21] spiv: is it likely to be a bad idea to use fetch-ghosts or similar do you think? [08:22] peitschie: so [08:22] * spiv hmms [08:23] I'd try making a new shared repo, and branch into it all the branches you already have in SVN [08:23] Then I guess try to branch across all the others [08:23] I don't think it would hurt to try fetch-ghosts [08:23] Although my guess is it won't help [08:23] I have something else that may help [08:24] spiv: the branches into the new one is painful... there is currently >500 I think :) [08:24] spiv: yah? [08:25] peitschie: bzr branch lp:~spiv/+junk/bzr-chk-used-by ~/.bazaar/plugins/chk_used_by [08:25] Then look at 'bzr help chk-used-by' [08:25] It may help you answer your original question [08:26] spiv: oh! thas cool :)... thanks very much for that [08:27] peitschie: IIRC it expects keys to be written as 'sha1:........' [08:28] it's pretty rough and simple, just something I threw together for debugging a different bug a while back. [08:30] spiv: hmm... comes out blank on both sides [08:30] peitschie: I don't think it will ever give any results on an SVN repo [08:30] spiv: i've tried various combinations of with and withouth sha1 :) [08:30] spiv: yep... I'm running this between the bzr => bzr broken stuff [08:31] well, it can't tell you about keys that aren't there, of course :) [08:31] Well, hmm. [08:31] And it only reports CHK root keys, I guess. [08:31] i figured ;)... i'm running this in on boths sides of the break [08:32] oh... so this could likely not be a root key then [08:32] Actually, it will tell you about any root key that is referenced by an inventory in your repo. [08:33] I don't think it actually requires that root key to even be present (although perhaps it would raise an exception if it isn't?) [08:36] spiv: hmm... quite mysterious. do repo => repo transfers cause any inventories to be re-evaluated in any way? [08:53] spiv: I wonder if this is related to ghosting somehow [08:58] ping losa about pqm upgrade status [08:58] vila: it's on my list - should be able to get to it soon [08:59] mthaddon: great ! And which kind of upgrade will be done ? I'm waiting for a testtools one myself, but I understand a lucid one has also been discussed [09:00] vila: I thought you'd rejected that possibility as you wanted to maintain python2.4 compatibility? [09:00] mthaddon: indeed, but I lose on this front, I need to address it in another way, hence my question :) [09:00] mthaddon: indeed, but *if* I lose on this front, I need to address it in another way, hence my question :) [09:00] I wasn't aware of that... [09:01] aware of what ? [09:01] (from your first comment it sounded like you had "lost" at that and we were going to upgrade to lucid) [09:01] or did my missing *if* started a misunderstanding :-/ [09:02] no, I have no idea why the lucid update is proposed so I don't know if it's required for some more important reasons or it if makes it impossible to only upgrade testtools, hence my query for status [09:05] vila, hi there [09:05] i'm going to sign off soon [09:05] i'm interested in what you think about https://code.edge.launchpad.net/~mbp/bzr/597791-http-tests/+merge/37941 [09:05] and about news [09:06] thanks for making a 2.3b2 freeze [09:07] poolie: clarification about news, I duplicated the entries as it was the *current* policy, I agree we should change the policy, but until it's done, I've applied the old one [09:07] fair enough [09:07] i think soon spiv is going to split the news files and that would be a good moment to change [09:08] poolie: exactly, I've looked at it but it's not proposed yet and I've already asked for the docs to be fixed too :) This kind of imply explaining how we should address that :) [09:10] about the http test, I agree with the approach (I haven't review it yet, I'm starting pp'ing with non-core contributors ;) but it seems you're also discussing it with lifeless so I was tempted to wait for more stuff from you ;) [09:10] poolie: s/variations/scenarios/ sounds nice to me [09:10] for the attribute name I mean [09:11] poolie: and my remark about barry's shortcuts was related too [09:17] sorry, which remark? [09:22] poolie: https://code.edge.launchpad.net/~barry/bzr/609186-shortcuts/+merge/37787 might be a good place to play with your new ideas about load_tests, there are a nuch of very similar tests there that could be parametrized from the _ubuntu_series_shortcuts dict [09:22] poolie: there are fine *as is*, but look simple enough for you to play with too [09:23] poolie: I went ahead, introduced the helper and sent the result to pqm already [09:23] ah, yes [09:23] i think, generally, if you can write it out just as a series of tests [09:23] or a static list, in a single test, that might be better? [09:23] maybe not - if they're variations then you can run just one of them [09:23] well, the problem with a single test is that you get only one failure... [09:24] right [09:24] anyhow, i should go [09:24] good night === Christian is now known as Guest65924 === Guest65924 is now known as Christian12 [09:49] Hi I have a general question concerning version control tools. atm we have a central coldfusion test server(unix). The developers run windows machienes and work directly on the files on that system. when the development is dont the files are replicated to the prod system. Which bazaar workflow would fit best in this case? Do I need to install on all local machines a webserver + coldfusion? [09:50] mthaddon: can you clarify why a lucid upgrade is needed ? [09:51] vila: it's not necessarily needed - it's just that's what we're upgrading all the servers in the DC to, so we were asking if it made sense to do that [09:52] ok [11:03] grrrRRRR pqm submission failing but no mail :( [11:04] ping losa, two of my last submissions to pqm failed and I didn't get the associated email [11:04] old problem with some MTA dropping it because it's too big, but I can't reproduce locally and I need some hints about which tests are failing :-/ [11:05] the submissions are related to https://code.edge.launchpad.net/~vila/bzr/609186-shortcuts/+merge/38098 [11:05] vila: we're getting mail returned from the address PQM is trying to send to... [11:06] vila: seems your smtp gateway thinks it's spam and is rejecting it [11:06] mthaddon: ha ! [11:06] mthaddon: argh :( [11:07] mthaddon: can you forward to my canonical email both the pqm mail and the spam report ones ? [11:08] k, have done [11:08] thks ! [11:08] I hate spam and it's unintended consequences.... [11:22] mthaddon: I got the spam report one but not the pqm one (that part cited in the first doesn't mention any failure) [11:23] vila: that email includes the entire test run output [11:24] mthaddon: the spam report says it's truncated but more importantly, I see *no* failures there [11:25] vila: what about https://pastebin.canonical.com/38477/ ? [11:26] mthaddon: it's an *expected* failure XFAIL not FAIL [11:27] well there's definitely something it doesn't like: > merge http://bazaar.launchpad.net/~vila/bzr/609186-shortcuts http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev [11:27] > Command failed! [11:29] mthaddon: right, that's why it doesn't get merged, but this doesn't tell me why. I briefly see ~36 failures in the summary on the pqm web page but no details [11:30] mthaddon: I received mails for other failures for other mps though: Conflicts during merge: Text conflict in NEWS [11:31] mthaddon: I *can* address these ones, but the one I ask your help about seem to be related to *test* failures, that's why I need the pqm email which is supposed to include pqm-stdout.gz and pqm-stderr.gz [11:32] I don't have access to that [11:32] * vila bangs head on desk [11:32] if you can fix your SMTP server, you can resubmit and they'll get sent through [11:33] mthaddon: my ISP smtp server ? I can't fix that. I'm searching the right way to get in touch with them about their spam filter going mad [11:33] or you could submit from an email that doesn't have a broken spam filter [11:35] hmmm, pqm authenticates on the gpg signature not the originating email right ? [11:35] nah, the gpg sig *is* for a given email === frakturfreak is now known as enaritud === enaritud is now known as frakturfreak [11:37] mthaddon: by the way, isn't there a RT ticket about configuring the news_merge plugin on pqm (which would have let 3 of my proposals goes through instead of failing) ? [11:38] there may be - we've been a little busy with the release recently... :) [11:38] mthaddon: I'm not complaining, just checking that it has been reported correctly [11:39] mthaddon: I fully realize the help you're providing [11:39] gah, no irony intended in this :-( [11:39] none taken :) [11:42] mthaddon: it's just that I'm patch pilot this week and as such the main pqm user so I try to sync on what is needed :-/ [11:42] well, I'm also the RM so even more pqm uses... [11:43] starting with 5 submissions and getting 5 failures including 2 with no clue about what failed made me a bit... you know... surprised :) [11:51] vila: I do see three pqm log files on the server with "Conflicts during merge: Text conflict in NEWS" in them about 45 mins ago [11:51] dunno why PQM is running the test suite if there's a merge conflict though... [11:51] that seems sub-optimal [11:52] I've got mails for ~nmb/bzr/311518-apache-doc-rewrite , 551391-log-memory-usage and ~nmb/bzr/484101-default-format [11:52] but they all say: Ran 0 tests in 0.000s [11:52] so I'm pretty sure the test aren't run if the merge fails [11:52] hmm [11:53] I'm after thw two other (really the same submitted twice) where tests have failed (to the best of my understanding) [11:53] (the fact that I got mails for failures doesn't make the spam report easier to understand either :-/ But that's clearly another topic :) [11:55] what time would they have been sent? [11:56] and does this look possible - http://paste.ubuntu.com/510805/ [11:56] just before the others... 2hours before at most [11:57] that paste is the previous one to the merge failures [11:58] argh, the traceback is not supposed to lead to a failure :-( [11:59] it's a transient issue [11:59] err [11:59] sporadic issue [12:10] mthaddon: I suspect this traceback escaped the redirections, is still not leading to a failure and that we just need the redirected files.... which may not be on pqm anymore having been sent by mail :-/ [12:11] mthaddon: I assume you didn't edit that pastebin of course (just checking the 1% unlikely event ;) [12:11] nope, didn't edit it === jelmer_ is now known as jelmer [12:15] I did a push to a new location, I was expecting the source to go over but only the .bzr dir went, whats the best way to do this? [12:19] maybe I should start from beginning, I'm a lone developer, been using bazaar on my local machine. Now I have to move my stuff to the live server for the first time [12:20] should I install bazaar on the live server or am I ok with pushing the changes to server? [12:23] (disk wise) === zyga is now known as zyga-lunch [12:35] Amythang: the usual big question is: do you need the history on the server (the .bzr dir) or do you need the files themselves (the working tree) [12:36] Amythang: or both or some variant ? (Including: eerk, I certainly don't want the history to be readable by everybody on the internet, it's a web site ! I only want to publish the web site !) [12:36] yes good point, I guess I will not need the history [12:37] Amythang: in that case, have a look at the bzr-upload plugin [12:37] ok thanks :) [12:37] Amythang: and start by removing the .bzr dir on the server === zyga-lunch is now known as zyga [13:54] hi, wondering what i should use for Eclipse's /workspace/ dir. colocated repository, right? [13:54] mornin' [14:08] dOxxx: hey ! [14:09] millun: sounds right [14:10] thanks vila [14:10] millun: I assumed you mean using bzr-colo right ? [14:10] i am using the GUI thingy. yes, prolly [14:12]