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