[00:00] ok, thanks for your help so far jelmer , suspect i might be back with more another day :) === mw is now known as mw|out [00:14] hey hey [00:14] anyone have a moment to look at https://bugs.edge.launchpad.net/bzr/+bug/195217 [00:14] Launchpad bug 195217 in bzr-lpreview "ReadOnly error when running bzr review-submit" [Undecided,Fix committed] [00:15] nigth all [00:22] kiko-afk: What's to look at? I've already submitted a fix and attached it as a patch. [00:26] jam: good night [00:29] and i've merged and pushed said patch [00:32] mwhudson: So we can mark it fix released, then? [00:32] abentley: i guess so [00:33] abentley: bundle buggy is giving 'database is locked' errors for me [00:33] Or are there actual releases of that plugin now? [00:33] spiv: Apologies. It's having trouble digesting your patch. [00:35] abentley: ah [00:35] Of course, it *shouldn't* be. [00:35] abentley: I should have guessed that my patch-bombing had something to do with it :) [00:40] abentley: i certainly haven't released it === BasicMac is now known as BasicOSX [01:01] mwhudson: Well, the bug statuses are problematic this way. If there's nothing left to do, we have to say it's at the end state, i.e. fix released. [01:15] abentley: getting connection failed from bb now -- is that a good sign or a bad sign? :) [01:15] Sign of desperation. [01:16] The last time it tried to handle your message, it got hung up on a lock error. [01:16] Which appears to be due to the visitor thread. [01:16] Which shouldn't run if there are no visitors. [01:17] Ah :) [01:17] A good sign then (in the short term). [01:18] Maybe. There's all kinds of things wrong here. [01:18] It seems odd that it would take so long to process my message. It's just a patch (not a merge directive w/ bundle). [01:18] Starting with my virtual server being so slow. [01:18] Yes, I agree wholeheartedly. [01:19] And there's also the issue that I can't reproduce these lock errors locally. [01:23] Well, it took 5 minutes, but it managed to process one of your messages. [01:24] abentley: hooray! [01:51] spiv: We now return you to your regularly-scheduled bundle buggy [01:51] abentley: thanks! [01:51] btw, why did you send those as patches? [01:53] Because they're in a great big branch, and I decided just slicing the final patch by file was a good way to break it up. [01:54] spiv: what, exactly, did you use to do that? `bzr merge --overwrite .../path/to/other/branch ? [01:54] Ah. I was thinking you'd done it as a loom and were firing off per-branch diffs. [01:55] abentley: I did, but I've already merged the other bits in the loom :) [01:55] I wasn't aggressive enough about making threads, perhaps. [01:57] AfC: Just "bzr diff -r submit: > everything.patch", then by hand broke it into pieces (pretty easy, given that I was just splitting by file rather than trying to edit hunks). [02:02] by hand? [02:02] Ah [02:02] * AfC was harbouring the hope that effective cherry picking support had arrived. [02:02] "vim everything.patch", and remove everything except e.g. message.py + client.py, save as a new patch, send to the list. [02:03] And repeat until I've sent everything. [02:03] I was going to try break it down into a series of logical steps from the commit history until I realised that with this code, the individual files are actually pretty independently reviewable. [02:08] lifeless: around? [02:16] abentley: hi [02:17] So I went to start adding the checks pack-1.5, so that it wouldn't accept a revision whose inventory SHA1 didn't match the actual inventory sha1. [02:17] And it seems that it was already clobbering the inventory sha1. [02:17] The one in the revision, I mean. [02:17] *blink* [02:18] I didn't think I merged anything to fix them up [02:18] repository.py:551 [02:18] and checking bzr.dev it still looks to be missing any fixup [02:19] abentley: ah yes, thats not the fetch code path :) [02:20] abentley: I think jelmer fixed this a couple of releases ago [02:20] It's one of them. [02:20] This should be the codepath used when serializers differ. [02:21] And also for old bundles. [02:21] abentley: so this function looks correct to me: supply an inventory and revision, and the inventory is serialised and its sha put into the revison [02:22] supply just a revision and the revision is assumed to be fully populated [02:22] Well, it looks like it does what you think we should be doing. [02:22] *IF* the plain to rich root fetch used this code path it would [02:23] however, if you look at fetch.py [02:23] Model1toKnit2Fetcher [02:23] and Inter1and2Helper [02:24] fetching does a regular join of all the file knits [02:24] They use GenericRepoFetcher, which uses the Store directly? [02:25] then adds a empty text for the root directory for all revisions [02:25] then reserialises the inventories (via iter_rev_trees) [02:25] and finally bulk copies the revisions and signatures [02:27] So the thing I didn't understand until now is that we were already mutating revisions all over the place. [02:29] So you can easily have wrong SHA1s in a rich-root-repo, but you can also have right ones. [02:29] yup [02:29] And when you create a bundle and send it to a friend, they may wind up with different SHA1s from you, even with the same inventory format. [02:30] So it seems like the referential integrity I was trying to preserve is already hopelessly lost. [02:30] jam: sweet, I got it working, so now I have a status page with error reporting, and mostly reliably failing commits [02:33] jam: http://sei.meidokon.net/ for a success page, http://sei.meidokon.net/status-fail.html for a fail page (except that it was deliberately triggered for non-diverged trees, so the revisions on both sides are the same) [02:33] jam: I'm really happy now, thanks for your help :) [02:34] Verterok, :) [02:35] beuno: Hi [02:36] abentley: I think we're both trying to preserve a form of referential integrity [02:37] abentley: but xml8 should make both of us happy [02:37] xml8 would, but I'm not sure I see the point anymore. [02:38] If we're already rewriting SHA1s all the time, why shouldn't reconcile do it? [02:38] well, I don't really like the idea of reconcile doing it [02:39] it just seemed expedient to have the ability to repair a repository [02:39] But if we did address that issue, you'd feel good about making rich-root-pack the default, right? [02:40] And since it's been supported since bzr 1.0, we could do that in the next release, right? [02:40] I think we have a convesion bug [02:40] but modulo that, yes [02:41] Should we rename 'reconcile' to 'repair'? [02:41] spiv: How about "refurbish"? [02:41] spiv: possibly; I was thinking sha1 changes would need an option anyhow [02:41] abentley: renovate! [02:42] "bzr renovation-rescue" [02:43] Seriously, I'd prefer a term that connoted "maintenance" rather than "data recovery". [02:44] lifeless: I wish I'd understood in London that we were already rewriting SHA1s. [02:44] So much time and stomach lining wasted. [02:46] abentley: :(. [02:47] I clearly failed to communicate the knowledge I had effectively [02:47] Or maybe I didn't listen clearly. [02:48] Oh well. [03:01] lifeless: What's the current state of stacking? [03:01] abentley: the prototype works on sftp only; [03:02] I'm rapidly closing in on the migrated versionedfiles logic [03:02] which enables making it work on bzr+ssh [03:02] by breaking the dependency on format-matching [03:03] Do you plan to update the prototype? [03:05] oh yes [03:05] and polish it [03:05] its just an ordering thing [03:05] The last version I have doesn't pass the test suite, and doesn't merge bzr.dev cleanly. [03:06] I'll send you my test suite fixes at least. [03:07] please [03:13] spiv, abentley: how about 'bzr defrag' [03:14] yay, no more use of KnitVersionedFile.join() from within the knit internals [03:15] jml: that is 'pack' [03:15] jml: pack rearranges. reconcile cross-checks indices, graphs etc [03:53] hey guys, i can reproduce https://bugs.edge.launchpad.net/bzr/+bug/217701 with bzr.dev at both ends [03:53] Launchpad bug 217701 in bzr "attempt to add line-delta in non-delta knit" [Critical,Fix committed] [03:53] i thought the fix was in bzr.dev by now [03:59] oh er, maybe not [03:59] hm [04:05] * igc lunch [04:37] igc: Your vote on the send documentation wasn't captured by BB because you didn't reply to the right message. [05:31] spiv: ping [05:43] meh codeslinger is spamming a huge number of bugs with a fairly aggressive tone [05:44] Odd_Bloke: I'd like a chat at some stage when you're around [05:45] What's the right way to fix files that bzr resolve put "<<<<<< tree" into? [05:49] bzr resolve won't do that [05:49] you run bzr resolve on the file once you remove those lines [05:50] so is it a hand prune situation? [05:51] yes, you get to choose which side you want to keep [05:51] or if you want to merge the sides [05:51] gotcha [05:51] merge or pull produced conflicts (the command will tell you), then you edit the files to resolve it the way you want, either picking a side or combining them [05:59] thanks abentley === mbp_ is now known as poolie [06:34] sorry for asking all of these questions, I've created a bundle, now what can I do with it if my project doesn't have an email associated with it [06:34] can I assign one? [06:35] you can send that to whoever would review and potentially merge your changes - the project author or the developers list or wherever [06:35] A[A[A[Abzr: ERROR: No mail-to address specified. [06:35] sorry for the preceding garbage [06:36] how do I specify an email for the project? [06:36] oh, right - you can use 'bzr bundle -o somefile.bundle' to get it into a file [06:36] ah ok [06:36] You should use "bzr send -o foo.patch" instead of bundle now, I think. I dunno if there's a benefit... :P [06:36] send takes a --mailto option [06:37] I should really rtfm [06:37] hrm, me too it seems [06:37] hehe [06:38] poolie: mail sent [06:39] so that little hash is my patch? [06:39] maybe I didn't do bundle right [06:40] bob2: 'bundle' is not meant to be used these days [06:41] what do we use today? [06:41] bzr send [06:41] send [06:41] just send? it takes care of everything? [06:41] including making the patch? [06:41] yes [06:41] you can give it various parameters [06:41] So I just want to submit a patch for 1 file foo [06:42] lifeless: ah, right [06:42] lamalex: make the change, commit it, then run bzr send --mail-to=xxx [06:42] lamalex: (or instead of --mail-to, you can use -o- to get it on the console) [06:43] is there a way to say only make a patch for file X? [06:43] yes [06:43] do I just give it that file as an argument? [06:44] 'bzr diff -r -X FOO' [06:44] lamalex: but this discards your commit history [06:44] hm, it doesn't like -X [06:45] lamalex: well, the X should be a number for how far back in history to go [06:45] ahh [06:45] ok [06:45] ou can use the send logic by doing 'bzr send -r submit: FOO' [06:45] maybe I'll just do this the old fashioned way with GNU diff... [06:46] lamalex: perhaps you could tell me the whole use case, I feel like I'm playing catchup here [06:46] :) ok [06:46] So I fixed a bug, I need to make a patch, but it's not the only file that changed in the tree [06:46] did you commit the bugfix on its own? [06:47] well the other files that changed are IDE files that we keep in the tree [06:47] e.g. 'bzr commit -m 'fix bug' somefile.c' [06:47] oh snap I had no idea you could commit a single file [06:47] send can send a single commit [06:48] or if you have just made a single local commit, just a normal send will do the right thing [06:48] you can use 'bzr uncommit' to pop the most recent commit [06:48] yeah [06:48] this does not alter the files in your tree, it only changes a pointer to the history [06:48] I know that one [06:48] so I commited just that file [06:49] now I want to bzr send --mail-to ... [06:50] right? [06:50] oh suddenly it's a lot louder [06:50] :P [06:50] sorry for waking the baby [06:50] (not calling you a baby, referring to an imaginary infant) [06:52] ahh ok, this calls your mail client to send an email. hmm [06:54] So how does a project do code review on this? It just looks like a hash and nothing else? [06:54] lamalex: by default it should have the diff [06:55] hrm [06:55] I wonder what I'm doing wrong [06:55] lamalex: what options did you give 'bzr send'? [06:55] --mail-to -o [06:55] with arguments [06:55] what arguments [06:55] what does it diff against? the version in the parent branch? [06:56] bzr send --mail-to gnome-do@googlegroups.com -o RenameTo.patch [06:56] it picks the least common ancestor to diff against [06:57] --mail-to and -o are exclusive options I thought [06:58] and by default (unless you have told bzr otherwise) it does that comparison against the parent branch [06:59] bzr didn't give me any erros for using both [06:59] indeed; we may have a bug there [07:00] and it's not giving me any diff [07:01] lamalex: so, lets do a quick diagnostic [07:01] lamalex: what does 'bzr missing' tell you [07:01] (just that, no options) [07:02] my last commit of just the 1 file [07:02] and it says you have that locally? [07:03] http://www.paste2.org/p/22706 [07:06] anything look out of place? [07:07] lamalex: ok, thats good. Now lets check the commit [07:07] lamalex: 'bzr diff -r -2' [07:08] lamalex: does that show the expected diffs [07:08] it shows more than it should actually [07:08] lamalex: oh, do 'bzr diff -r -2..-1' [07:11] looks ok [07:12] ok [07:12] now 'bzr send -o-' === mtaylor is now known as mtaylor|zzz [07:13] -o-? [07:13] like a little airplane? [07:13] :P [07:13] yes [07:14] (holding your arms out and making "vrrrrm!" noises is optional) [07:14] lifeless: thanks, nice draft [07:14] you could send the whole thing with take 1 and take 2 [07:14] :> [07:14] haha [07:14] lamalex: so did it look better? [07:15] no! [07:15] wtf [07:15] http://www.paste2.org/p/22707 [07:16] lamalex: looks like during learning about send you have overriden its heuristics [07:16] lamalex: try [07:16] ha [07:16] 'bzr send http://bazaar.launchpad.net/~do-core/do/devel/ -o-' [07:17] no that's an A+ [07:17] so now I want to do bzr send .... -o RenameTo.patch [07:17] if you add --remember it will remember that url for you [07:17] great [07:17] if you want to send it to the list, just replace -o- with --mail-to= ... [07:17] Oh, while you're on the topic of bundles, [07:18] I'm updating the HACKING instructions for the project I maintain, [07:18] and I'm trying to formulate a better description of the SUBMIT_BRANCH and PUBLIC_BRANCH arguments [07:18] ... I had been telling people to do [07:18] $ bzr bundle ../mainline [07:18] yeah that is a bit confusing [07:18] needs better names [07:19] which was working fine until one day I attempted to merge that bundle in a place that didn't _have_ a ../mainline [07:19] afc, i think they should set submit_branch in locations.conf rather than typing it every time [07:19] it can be remote [07:19] poolie: so, it seems to remember it [07:19] AfC: their ../mainline should have a 'public_location' set [07:19] poolie: or sorry, rather, something (not necessarily bundle) sets it [07:19] AfC: if it has that then the resulting bundle will reference http://..... [07:19] lifeless: that's what I figured, Rob, so what I was going to change it to was [07:20] Hi. I can't seem to get push to work to a remote server via ssh. Isn't 'bzr push bzr+ssh://user@server.tld/some/path correct? [07:20] bzr bundle ../mainline bzr://research.operationaldynamics.com/bzr/java-gnome/mainline > /tmp/name-that-tune.patch [07:20] dennda: that looks fine [07:20] hm [07:20] lifeless: ... but I wasn't sure if that was actually correct [07:20] AfC: several things can be improved there [07:20] (in terms of me not getting a branch not found error at the other side) [07:21] AfC: if you set the public location of ./mainline, then the user does not need to specify the full url [07:21] lifeless: I get this: [07:21] http://paste.pocoo.org/show/43412/ [07:21] thanks a lot lifeless [07:21] see you guys [07:21] (And yes, of course I got bzr installed) [07:21] dennda: that's correct, but note that "some/path" is relative to the root of the filesystem (not your home dir) [07:21] AfC: if you use send, better data is chosen and sent. -o /tmp/name-that.patch will output to a named file [07:21] spiv: yes, I know [07:21] dennda: you know that /some/path is from system /, not some hypothetical DocRoot [07:21] dennda: ah, it seems "bzr" isn't on your path on the remote system [07:22] spiv: I need to install bzr remotely? [07:22] dennda: to use bzr+ssh - alternatively you can use sftp://, which doesn't require bzr on the server [07:22] AfC: lastly, send will remember the submit branch, and by default uses the parent branch. so generally 'bzr branch; bzr commit; bzr send --mail-to=xxxx' is all that is needed for correct operation [07:22] confusingly, sftp urls are relative to your homedir, iirc [07:22] To use bzr+ssh, yes. bzr+ssh works by running bzr on the remote end and sending commands to it. [07:23] bob2: they are not [07:23] bob2: the expired I-D on sftp urls had them homedir relative, but its expired, and the gnome folk, like bzr, thought that that was crack [07:23] bob2: the difference you are thinking of is that our sftp URLs can have /~/ at the start of the path to make them relative to your homedir. [07:23] AfC: I hope that helps [07:23] lifeless: investigating... [07:24] lifeless: (ie, comparing the various permutations) [07:24] lifeless: I supposed one assumption I should have stipulated is that the public URL isn't available (due to disconnected operation) at time of creating the bundle. [07:24] dennda: as bob2 says, you can use sftp:// instead of bzr+ssh://, and it works quite well [07:24] lifeless: else [07:24] bzr bundle bzr://research.operationaldynamics.com/bzr/java-gnome/mainline [07:25] alone would have done it [07:25] AfC: thats why setting public_url is useful [07:25] AfC: it just tells bzr the url to use when generating a reference to the branch [07:25] lifeless: which the full form _does_ seem to do.... [07:26] (even remembers on first use) [07:26] most bzr commands that take optional urls remember them the first time they are supplied [07:26] yeah [07:26] poolie: I think I'll just send take 2. [07:26] (one of the nice things about what you guys do) [07:27] spiv: ah, oops [07:27] Anyway, that brings me back to thinking I should recommend the full form for first use. [07:28] AfC: I would recommend that ../mainline have a public url set. And that users specify ../mainline on first use. [07:28] ah great, thanks lifeless, AfC, bob2 and spiv :) [07:28] installing bzr remotely would've been an issue... (debian etch with bzr 0.11) [07:28] lifeless: as in, me going to the server and hacking something into the branch.conf there? [07:28] but sftp works [07:29] AfC: no [07:29] bzr help configuration [07:29] dennda: installing bzr manually from source is quite trivial, so don't think there is a big barrier to getting current code. [07:29] look for public_branch [07:29] lifeless: I-D? [07:29] bob2: Internet-Draft [07:29] dennda: (fwiw, having bzr 0.11 is technically new enough to work with bzr+ssh://, but it's not really any better than using sftp://) [07:30] AH that's what I was looking for the other day. Couldn't really sniff it out of the topic list. [07:30] oh, right, that is cracktastic [07:30] AfC: as long as there's sftp:// I'm happy [07:30] no need to install it remotely [07:31] lifeless: ... right, but `bzr bundle ../local bzr://public` sets/remembers/whatever public_branch [07:32] lifeless: maybe we're violently agreeing with each other [07:33] AfC: we're not [07:34] AfC: I was saying that ../local needs *its* public branch set [07:34] lifeless: right. But I cannot impose that on someone who has already cloned. [07:34] AfC: sure you can, its easy for them to do [07:35] _them_? You expect me to tell newbies to hand edit some internal configuration file? [07:35] AfC: that said, the target branch shouldn't matter to you when you apply the bundle [07:36] lifeless: ... it did {somehow, due to my ignorance, my not doing something right, or my being able to do the wrong thing in the fists place), which is why I raise the topic [07:36] AfC: if you expect them to have a local mainline mirror [07:36] AfC: well, if you can reproduce it, I'll happily assist debugging it for you, or at least explaining it if its not a bug [07:37] lifeless: I imagine it'll happen each time I do a merge now, as I'm attempting to use checkouts and switch. [07:37] lifeless: I'll keep an eye out and report back. [07:37] thanks [07:38] As for the other side of the coin, you are recommending that I _not_ adjust branch.conf on the publicly hosted branch? [07:38] AfC: I don't think that setting it in the branch.conf of your public mainline would be a good idea. [07:39] Really. Huh. Puzzling. [07:39] I guess I'll go and see if I can figure out why not. [07:39] AfC: either it won't propogate, in which case its pointless, or it will propogate, and all your new branches would claim to be your mainline. [07:39] Hm [07:40] Well, I was aware of the former. The later is a bit of a surprise, but ok. [07:40] Fair enough. [07:40] 29 errors to go... [07:41] AfC: if it propogated, then each new branch would think that when its pushed, the regular url other folk should use would be your mainlines url. [07:42] lifeless: yeah, I get it now [07:42] lifeless: so is http://rafb.net/p/KxYMcB25.html wrong? [I realize you have better things to do be doing than reading stuff from me, sorry] [07:44] afc, that looks useful [07:44] i thought we were encouraging people to use send -o instead of bundle? [07:45] AfC: the bundle command is problematic [07:45] AfC: the 'public_url' parameter is the public url of the branch being submitted [07:45] and i think that patch would be even better with a sentence or tw oabout what the urls are for [07:45] AfC: and in general you *don't have one* [07:45] So we had a big fight about this 6-8 months ago. I was on the side of "bundle is good" for numerous reasons, but [07:46] the one that remains a big factor for me is that I am really tired of people going to the trouble of sending emails with empty bundles in them [07:46] AfC: irrespective of command used. 'bzr bundle ../mainline' is fine. [07:46] 'bzr bundle ../mainline bzr://research.operationaldynamics.com/bzr/java-gnome/mainline' is wrong [07:46] by forcing them to glance at the file they _really_ review the diff they are proposing, and it avoids the "you didn't actually specify what branch you're comparing to" problem [07:46] because the branch being submitted is *not* bzr://research.operationaldynamics.com/bzr/java-gnome/mainline [07:47] if you want to force them to look at it, try 'bzr send ../mainline -o /tmp/name-the-patch.patch' [07:47] personally, I use 'bzr diff -r submit:' to preview a submissiom [07:48] Not to mention using stdout is good™ [07:48] * spiv uses "bzr cdiff -r submit: | less -R" [07:48] bzr send -o- does that [07:48] Well, until you remove it from bzr, we'll keep using it. [07:49] I'm not really interested in a debate about send vs bundle right now. I have a patch to finish. Helping you debug your docs is something I'm happy to do. [07:49] spiv: you're assuming that they have any clue what -r submit: is and why they should use it. That's a pretty advanced topic. [07:49] lifeless: I'm just explaining why it is that we're using bundle, since you noted it. [07:50] AfC: fair enough [07:50] AfC: I'm not suggesting that you recommend it, just mentioning what I use in case it's of interest. [07:50] I'm willing to trust you know more about your community than I do :) [07:51] It doesn't really strike me as the sort of thing to suggest to people when I'm busy trying to encourage them to tolerate my using Bazaar at all in the first place. The whole repository setup malarkey is bad enoug. [07:54] afc, so if the core issue is that people should read their diff before sending it [07:55] poolie: indeed [07:55] that sounds like a pretty reasonable thing, and orthogonal to internal concerns about bundle vs send [07:55] poolie: I've sent the bug-activity mail off [07:55] in the way i use send, i see the diff in the editor asking me for a description [07:55] however i think this won't happen if you're using an external mail client [07:56] AfC: anyhow, my key point is that for someone that hasn't published their branch using the two-parameter form of bundle is *always* wrong [07:56] AfC: and specifying a different branch as teh public branch is also always wrong/ [07:56] well, depending on the client it may or may not be able to open or see files attached to your draft [07:56] AfC: it seems to be all your users will fail on both tests with the draft doco you pastebinned [07:56] AfC: which is why I am saying use one-parameter form [07:58] poolie: judging by the fact that I got empty bundles, I'd have to say that's the case [07:58] ok [07:59] i would think we should not generate empty bundles without warning or forcing [07:59] but, it is exactly that kind of case that i think robert and aaron are saying is problematic in bundle [08:00] poolie: (it was send that was generating the empty merge requests) [08:02] lifeless: so, transposing what you're saying, I should revert to telling people to do `bzr bundle ../mainline` or whatever and do $something different when I merge to avoid the problem that _I_ have no ../mainline for it to refer to (assuming I can duplicate that scenario and that it is indeed a problem) [08:02] AfC: *and*, have them set the public url for their copy of mainline [08:04] lifeless: Ok. One last question, then: how is that different than them inheriting public_branch from the internet hosted 'mainline' they branched from in the first place? [08:05] lifeless: which you indicated would result in all branches thinking they were 'mainline' (a statement I find weighty though, I must admit, a bit strange given all branches are peers more or less) [08:09] AfC: because it doesn't propogate when set in ~/.bazaar/locations.conf [08:10] thumper: Sure. I'm around now, if you still are. [08:10] Well, I'm pretty sure it doesn't propogate when set in branch.conf either. [08:10] (Morning all.) [08:11]