[05:00] I'm just now learning about the pipeline plugin. [05:00] I'm also totally unfamiliar with “lightweight checkout”. [05:00] apparently I need to make a lightweight checkout in order to make a pipeline. [05:01] They're like checkouts, except not as heavy 8-} [05:01] what's foiling me at the moment is: [05:01] (runner-up: They're checkouts that can't hold their liquor) [05:01] ‘bzr checkout --lightweight --revision "tag:release 1.2.3" foo.upstream/ foo.patch-pipeline/’ [05:02] the result, though, is not at the requested revision; it appears to have ignored that option [05:02] what I want is to apply an old set of patches at a corresponding old upstream version; then step through each subsequent upstream version modifying the patches accordingly as I go. [05:02] is that an appropriate usage of pipelines? [05:02] Can you `branch -r [...]`? I wonder if maybe it just doesn't like spaces in tags. [05:03] shall check, hold on [05:03] However, that aside, I suspect that won't quite work anyway; with a checkout at the non-head version, you can't commit, so you'd need a branch headed there before you could move it forward. [05:04] yes, ‘bzr branch --revision "tag:release 1.2.3" foo.upstream/ foo.bzr/’ works. the resulting branch is at the specified revno, and all subsequent tags exist but don't know their referent. [05:05] okay. so, given the use case, am I wasting time trying to use a pipeline? [05:05] Well, I don't know anything about pipeline. But the issues sound orthogonal to me. [05:05] You'd just need to start the pipeline with a branch at that rev to work from. [05:06] How do you know the result [of the co --light] isn't at the requested rev? [05:06] okay, so how do I start a pipeline at that rev? I can't even seem to get a lightweight checkout to work correctly. [05:06] because ‘bzr revno’ says so, and all the subsequent revision data is in the branch. [05:07] bzr revno gives the branch revno, not the working tree revno. So of course it would say that. [05:07] (and of course all the data's in the branch; it would be Really Bad if co threw that away!) [05:07] whereas, with a ‘branch’ instead of a ‘checkout --lightweight’, the revno is as requested and the revision data isn't present. [05:07] Try revno --tree. [05:08] But at any rate, yes, you'd want a branch of the appropriate rev to start a pipeline from. [05:08] ah yes, ‘bzr revno --tree’ reports the requested revno. [05:09] I don't see why the checkout needs later revision data if I haven't asked for it yet. (seems rather un-light too!) [05:09] ENONSENSICAL [05:09] The checkout doesn't have ANY revision data. [05:09] Revision data is all through the _branch_. [05:09] it makes as much sense as for ‘bzr branch --revision NNN’, and that doesn't have subsequent revision data either. [05:10] hmm. okay, clearly this is where my knowledge of lightweight checkouts fails me. [05:10] but that may not be something I need to know yet. [05:10] A checkout is just a working tree. It's no different from a WT that happens to be colocated with a branch. [05:10] so, with the tree at the requested revno, should I then expect to be able to: [05:10] * configure it to be a pipeline [05:10] * apply patches [05:11] * commit changes [05:11] Neither has any history, or revision info, or yada yada; when you run 'revno' or 'log' or some such, it just uses the WT to find the branch, and then does the operation on the branch. [05:11] * update from subsequent revisions upstream [05:11] AFAIK, pipeline is just a layer that uses one-or-more branches to do its stuff. [05:11] * continue converting the patches [05:11] ? [05:12] My vague sense is that since abentley wrote it, he wrote it to operate in his workstyle, which is a bunch of treeless branches somewhere, and a single [light] checkout switch'd among them. [05:12] Which is where the co --light command you came across comes in. [05:12] So I'd make a branch from the upstream at whatever rev you want to start with, and then use that as the 'base' of the pipeline. [05:13] got that far. what do I need to be careful of to make sure I can merge each patch from subsequent upstream revnos? [05:13] s/each patch/each local patch/ [05:14] Well, a pipeline is just an arrangement of branches. So whatever you'd need to do with a normal branch to maintain , you'd do with pipeline. [05:14] argh, badly phrased. the patches are local, and are against a specific upstream revno. the point of the exercise is to update these local patches against later upstream revnos, one by one. [05:15] I've never used it, so I don't know how much complication it would add. [05:15] okay, thanks for your help so far. [05:23] nnngh. adding a new pipe insists on updating the checkout. [05:23] defeating the purpose. [05:27] argh. it's fiddling around making directories *parallel to* the branch where I'm operating? [05:27] this is most annoying. [05:34] Yeah, that's what I said :p [05:34] 1..N treeless branches, a light checkout switch'd among them. [10:20] vila: re bug 542400 [10:20] Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/542400) [10:21] * fullermd pats ubottu. [10:22] vila: Are you sure that's really bzr? It seems to be pretty qbzr-entangled... [10:22] fullermd: huh, how do you know about it when it's private ? [10:22] I know all and see all. [10:23] fullermd: the command itself doesn't involve qbzr and I'm pretty sure I've seen a patch by NAOKI about the subprocess parameters not being encoded as they should [10:23] given that the filename is not ascii... there are good chances that it's encoded correctly :) [10:26] Owell. Just wondering. It'll get sorted out one way or another I reckon. [10:28] fullermd: MA is 'the commonwealth of massacheussets [10:28] Same Owell here, but I trust bialix [10:28] (spelling fail but still) [10:28] hi guys [10:28] who is summon me? [10:28] great, now I know it's not saturday :) [10:29] it's saturday [10:29] lifeless: ... well, yes, but... EREF? [10:29] bonjour vila [10:29] fullermd: the other day, poolies comment 'the other commonwealth' [10:29] fullermd: and youre reply :P [10:30] Oh. Don't you go screwing up my word games with mundane facts! [10:30] bialix: do you remember a patch from naoki about encoding paths for subprocesses ? Could that apply to bug #542400 (and by the way, can you confirm that you too can read this bug ?) [10:30] Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/542400) [10:30] vila: Oh, now you're just _taunting_ ubottu. That's just cruel. [10:30] Not allowed here [10:30] Sorry, you don't have permission to access this page. [10:31] that's what I see [10:31] fullermd: I love it when it reply starts with 'Error:' :-) [10:31] The poor guy who registered that nick doesn't :> [10:31] Ok, now we know we have a lp hacker around.... :) [10:32] vila: patch from naoki? vaguely [10:32] Qt uses unicode [10:32] and I like that [10:33] we need to encode data for python standard subprocess module because it can't handle unicode [10:33] bad python [10:34] right, I think this was mentioned in the discussion and it's unclear to me if a wroking solution was found (console encoding vs fs encoding IIRC) [10:36] seriously how come fullermd can read this bug report and bialix can ? [10:36] cant [10:36] bah [10:36] seriously how come fullermd can read this bug report and bialix cant ? [10:36] babah [10:36] vila: who is subscrubed [10:36] You received this bug notification because you are a member of bzr-core, [10:36] I'm just poor boy [10:37] (of course, $DEITY knows how _that_ happened. Some fool had a moment of weakness, maybe...) [10:38] bzr-core is just bzr without plugins [10:38] its not 'core developers' [10:38] ha, of course. bialix ! Not poor, bad ! Not part of bzr-core, tsk tsk :) [10:38] yep, not part of bzr-core [10:38] 'bzr' is part of bzr-core [10:38] (technically, I'm part of bzr, which is part of bzr-core) [10:38] * bialix is bad? oh, man... [10:39] red big flashing [10:39] yeah, yeah [10:39] I was joking too [10:40] :) [10:41] Well, now that the channel's all active, must be time for me to go... [10:47] to sleep? [10:48] Perchance to dream. [10:49] hello [10:49] hi [10:50] A question: Why pushing over sftp doesn't move any files? It just creates .bzr directory under my push directory, nothing else... [10:50] because push only sends the history of your branch [10:51] if you want to copy working tree files you need to use bzr-upload plugin [10:51] oh... ok [10:52] How to check if it's installed? [10:58] run `bzr plugins` and look for the line 'upload x.y.z' where x.y.z is the version of the upload plugin' [10:59] you have to install it as upload, not as bzr-upload [10:59] koskela: ^ [11:00] 1.0.0dev is the version [11:01] check `bzr help upload` for help [11:02] Ok... Do I remember totally wrong because I think it worked earlier that bzr push command uploaded the files too... [11:03] koskela: there is also push-and-update plugin [11:03] maybe you're using that in the past? [11:04] anyway, push updates working files only for push from local disk to local disk [11:04] or just to local disk, that's more correct [11:04] Ok... [11:05] Oh, ok, now I remember... At least another situation that I was remembering, was local directory to another local directory... Thanks! === lionel_ is now known as lionel === kgoetz is now known as Kamping_Kaiser [14:24] I've got a little problem, today bzr started hanging with the sftp connection and I can't even seem to google anything sensible for the error message [14:26] what's error message [14:26] Disconnect (code 2): Protocol error: packet 5 in interactive [14:29] show the relevant part of .bzr.log [14:32] umm, where would that be in the windows version [14:32] run `bzr version` and you'll see the location [14:32] are you on windows? [14:33] are you using bzr.exe from standalone installer? [14:33] * bialix bbiab [14:37] * bialix back [14:37] yeah, on windows [14:40] do you have any special settings regarding ssh client? [15:00] bialix: nope, it used to work just fine, and it still works for other team members [15:00] do you see anything unusual in .bzr.log? [15:01] hi Bialix [15:01] heya jelmer! [15:01] How are things? [15:02] despite be busy with the main work? well, fine, thanks. today I'm trying to implement snapshots for scmproj [15:02] jelmer: and you? [15:03] bialix: Same, busy but happy :-) [15:11] bialix: this line 8.375 failed to load system host keys: [Errno 2] No such file or directory: 'C:\\/.ssh/known_hosts' [15:11] but, I don't know if that is it [15:11] Gnx: it's harmless [15:11] because it asks for my pwd anyway [15:11] Gnx: are you using pageant? [15:11] bialix: nope [15:12] can you pastebin the relevant part of .bzr.log? [15:13] Gnx: if you're using paramiko for sftp (which I believe is the default) you can set your password in the authentication.conf file [15:13] so you don't need to type it everytime [15:13] oh, well didn't really mind doing that === marienz_ is now known as marienz [15:15] doing that what? [15:18] entering the password [15:20] np [15:28] Gnx: if you still encounter this problem try to ask in bzr ML or file a bug [15:28] * bialix disappears [16:37] hi all [16:38] how to setup enviornment using bzr [16:38] anyone live [16:38] ? [16:45] Conflict adding file website. Moved existing file to website.moved. [16:45] how can I use the existing website.moved file? [17:01] any one can tell me how i can start work on bzr for mixxx software [17:01] i've python 2.6.4 as well as bzr also [17:01] it's installed in my system [17:31] I am looking for a bazaar equivalent of statsvn (http://www.statsvn.org/). Any suggestions? [17:50] zini, the best I canthink of is bzr-stats [17:52] I think I saw that while searching for a replacement. But it gives only stats about commiters, right? [17:55] Well, I am off. Thanks anyway. === radoe_ is now known as radoe === james_w` is now known as james_w [20:41] bzr: ERROR: Operation denied because it would change the main history, [20:41] how to fix ? [20:41] I did unbind, commit commit push [20:41] then pull, merge, commit [20:41] and got lost :'( [20:54] strk: you need to checkout the branch, merge your branch into the checkout, and commit === Adys is now known as Adys` === Adys` is now known as Adys === Garen_ is now known as Garen