[00:00] <blueyed> abentley: why have you silently duplicated bug 195578? - it's not the same
[00:00] <ubotu> Launchpad bug 195578 in bzr ""bzr revert" does not backup symlinks and empty directories (dup-of: 87548)" [Undecided,New] https://launchpad.net/bugs/195578
[00:00] <ubotu> Launchpad bug 87548 in bzr "bzr add and revert on symlink deletes symlink" [Undecided,Invalid] https://launchpad.net/bugs/87548
[00:05] <poolie> lifeless: bad tab completion?
[00:07] <lifeless> poolie: yes
[00:07] <lifeless> Prodoc: np
[00:08] <Prodoc> :-)
[00:09] <Prodoc> time for a nap again, goodnight all
[01:30] <bob2> is bzr+http support on launchpad planned anytime soon?
[01:30] <poolie> yes, thumper would know more
[01:31] <thumper> bob2: yes, real soon now
[01:31] <poolie> lol
[01:31] <poolie> thanks for the more precise answer :)
[01:34] <bob2> heh, great
[01:36] <lifeless> argh
[01:37] <lifeless> run_bzr working_dir=xxx breaks our test HttpServer
[01:37] <lifeless> _now_ that that is sorted, I just now need to fix it :|
[01:57] <lifeless> yay test passing. what a waste of time that was
[01:58] <AfC> Hooray for time wasters!
[02:05] <blueyed> yay.. I'm finished for today restoring my symlinks, empty directories (including svn checkouts) in /etc.
[02:15] <lifeless> blueyed: I really regret that you had that experience
[02:31] <lifeless> is there a command line to set the public_location of a branch ?
[04:03] <Odd_Bloke> So I notice that there are two formats of name/bug number for fixes, namely "(#123456, Foo Bar)" and "(Foo Bar, #123456)".  Which should I use?
[04:04] <lifeless> Odd_Bloke: where
[04:05] <Odd_Bloke> lifeless: In NEWS (to clarify).  Everything under IN DEVELOPMENT uses the former, and BUGFIXES of 1.2 has examples of both.
[04:13] <Peng> I've always thought the correct one was the former.
[04:14]  * Odd_Bloke would've opted for the latter.
[04:15] <fullermd> Sad that your choices are limited to orderings in only one dimension...
[04:17] <johnny> ?
[04:25] <lifeless> Odd_Bloke: hmm, Look at 1.1's area, that will probably make it more clear :)
[04:27] <Odd_Bloke> lifeless: It does, thanks. :)
[04:28] <pooli1> thanks
[04:28] <pooli1> Odd_Bloke: are you all set for london
[04:33] <Odd_Bloke> pooli1: Yup, should be turning up early afternoon.
[04:52] <Peng> Err, wait.
[04:53] <Peng> I like the latter, not the former.
[04:53]  * Peng checks.
[04:53] <Peng> Yeah. (The Name, #1234).
[04:53] <Odd_Bloke> Sanity is restored! :)
[05:03] <igc> bbiab
[05:07] <kohwj> ok, branching and merging are good things, but what happens when a user branches and makes changes to the branch, while another user makes changes to main, and then a merge is attempted?
[05:07] <bob2> depends if they texttually conflict or not
[05:07] <bob2> if they're different files, merge just works without intervention
[05:09] <kohwj> bob2: i see. if the same file is changed in the branch and main, manual intervention is needed?
[05:10] <bob2> depends if the changes overlap or not
[05:12] <johnny> two seperate changes to two seperate areas of the file shouldn't cause a problem
[05:13] <kohwj> that's nice!
[05:13] <kohwj> thank you!
[05:13] <bob2> (same as every revision control system I've ever heard of)
[05:14] <kohwj> i'm new to vcs
[05:20] <johnny> kohwj, it's an interesting area
[05:20] <AfC> kohwj: you're lucky. Most of us started with RCS, SCCS, or CVS. Those were dark days indeed :)
[05:20] <johnny> kohwj, if you want your mind blown, read the revctrl mailing list
[05:21] <johnny> unless you have a degree in graph theory..
[06:03] <kohwj> johnny: heh
[06:04] <johnny> luckily we can just let the smarties do it :)
[06:37] <lifeless> win 20
[06:37] <bob2> lose all
[06:37] <lifeless> tie nothing
[06:38] <lifeless> bob2: thanks for the patch
[06:38] <bob2> did it work?
[06:50] <lifeless> haven't applied it yet
[06:50] <lifeless> will do so on the plane tomorrow
[06:50] <lifeless> bob2: did you write a test for it ? :)
[06:50] <bob2> ah, have a nice trip
[06:50] <bob2> lol
[06:51] <bob2> what do you take me for ;)
[06:52] <lifeless> just asking!
[06:55] <abentley> bob2: You know, some guy's been using your name on a blog about ODF
[06:56] <bob2> haha
[06:57] <lifeless> abentley: the guy with the scyth?
[06:57] <lifeless> bob2: you _so_ have to get a job with ibm
[06:57] <abentley> lifeless: eh?
[06:58] <bob2> I'd love an exciting job at ibm working on office file formats!
[06:59] <lifeless> abentley: http://www.robweir.com/blog/rob.html
[06:59] <lifeless> abentley: not bob2
[07:00] <abentley> Ah, I'd forgotten about the scythe bit.
[08:32]  * igc dinner
[08:46] <lifeless> spiv: cool thanks
[08:53] <visit0r> why is bzr outputting basic output to stderr?
[08:53] <visit0r> any way to change this so it would output only if something's wrong?
[08:59] <lifeless> output to stdout is the requested output, not status or debug or error info
[08:59] <lifeless> output to stderr can be reduced/made quiet by -q
[09:00] <lifeless> though we don't claim to have audited all commands yet
[09:00] <visit0r> hmm ok, always tought it's primarily for error messages
[09:00] <visit0r> but thanks anyways
[09:09] <lifeless> visit0r: we want e.g. 'bzr diff | less' to only ever have the content of the diff
[09:12] <visit0r> lifeless: ok, sounds reasonable
[11:34] <liw> how do I make bzr forget the parent branch (set by "bzr pull")?
[11:39] <quicksilver> I know how to make it remember a new one
[11:39] <quicksilver> does that help?
[11:40] <quicksilver> I don't know how to make it forget without that though
[11:40] <quicksilver> bzr pull --remember new://url
[11:41] <liw> hmm, I can make it remember the empty string, which it translates to the current working directory -- ugly, but at least a partial solution
[11:41] <bob2> you can delete the line from .bzr/branch/branch.confg, as a last resort
[11:42] <liw> bob2, yep, that worked -- slightly ugly to do, but good enough for now
[11:43] <liw> thanks
[12:20] <Bronger> Is there another GNU program of the size of Bazaar written in Python?
[12:21] <bob2> mailman, maybe?
[12:22] <TFKyle> Bronger: don't think so (can't think of any Version Control Systems created by GNU offhand)
[12:22] <Bronger> I didn't only think of VC software.  Mailman, yes, this is also large.  Didn't know that it is part of GNU, but you're right.
[12:23] <bob2> at least rcs and cssc are gnu vcs (and not in python)
[12:23] <TFKyle> ah, just in general
[12:24] <Bronger> ... and GNU arch.
[12:24] <bob2> touche
[13:02] <lifeless> Bronger: I'm not sure how 'big' bzr is to really answer that ;)
[14:18] <Prodoc> good afternoon
[14:20] <Prodoc> how do I commit and push using the bazaar eclipse plugin?
[14:24] <Prodoc> I've created a bazaar snapshot of an existing eclipse project (local), now I'd like to commit the changes to the branch and push them to the ftp server (php project)
[14:24] <Bronger> lifeless, I don't undertand what you say, sorry.
[14:27] <beuno> Verterok, ^
[14:55] <awilkins> Prodoc: Pushing is not deploying, if that's what you want
[14:55] <awilkins> Prodoc: Pushing only updates the remote branch, not the working tree of the remote branch
[15:02] <Prodoc> awilkins: the only thing I've got remote is simply a FTP server to access the hosted website. This is what I want to update after changes have been commited
[15:02] <jdong> Prodoc: bzr will not update the user-visible contents on a push. It only updates the stuff inside .bzr
[15:04] <Prodoc> aha, so what is it what I should do to update the site and (how) can this be done in eclipse?
[15:12] <jdong> Prodoc: the only form of access you have is FTP?
[15:12] <Prodoc> yes
[15:13] <jdong> Prodoc: AFAIK bzr won't have a way to do this for you. My suggestion would be to "bzr export" to some directory, then use an uploader like ncftpput to upload that exported directory up to your website
[15:13] <jdong> you could script those two actions so that it's less of a pain
[15:15] <Prodoc> But that would be a simple overwrite, wouldn't it? What if someone else made changes to the online content?
[15:16] <Prodoc> ah, it appears to be possible: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id40 now the only thing that remains is to find out how this is handled in exclipse by the bazaar plugin
[15:17] <luks> branching?
[15:17] <Prodoc> sorry, one down: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id41
[15:17] <Prodoc> he, luks?
[15:17] <Prodoc> :-D
[15:17] <luks> :)
[15:17] <luks> merging works with branches, not files
[15:18] <luks> the fact that you have some files on the server is completey unrelevant to bzr
[15:18] <luks> the only data it needs are under the .bzr dir
[15:19] <Prodoc> aha
[15:19] <luks> also, it's probably not a good idea to have published .bzr dirs on a public http server
[15:20] <luks> so what you want if you work with some other people is to have a common location to push/pull/merge from bzr, and a way to update the live site from that location
[15:20] <Prodoc> true, I wanted to address that issue once I got it working ;-)
[15:20] <luks> bzr is only a version control tool, not a deployment tool :)
[15:22] <Prodoc> too bad ;-)
[15:25] <Prodoc> my only option is to use FTP, live or not. What if I simply upload a branch, could that work?
[15:26] <luks> you can simply push to FTP
[15:26] <luks> but it will push only the .bzr dir
[15:26] <luks> then if somebody else already pushed to the branch, it will complain
[15:27] <luks> so you know you have to merge the changes
[15:27] <luks> but after you do all this, you need a way to upload the actual files
[15:28] <Prodoc> creating an export of the branch
[15:29] <Prodoc> no?
[15:30] <luks> that's one way
[15:30] <Prodoc> hmm, not really handy if I only have FTP access to the server
 also, it's probably not a good idea to have published .bzr dirs on a public http server <-- why's that? just because he might have private config stuff in the branch or?
[15:31] <luks> if it's html only site it doesn't matter
[15:32] <luks> but you usually don't publish the source code of your websites
[15:32]  * TFKyle tends to :)
[15:32]  * luks tends to work on commercial ones
[15:33] <luks> and for the free ones, there are better ways to push the source code :)
[15:33] <luks> er, publish
[15:53] <jdong> Prodoc: another way to handle changes in content involves "getting" all of the website, locally doing a 3-way merge, then pushing back the merged results
[15:53] <jdong> this assumes during that time, nobody writes to the website, of course...
[15:53] <jdong> Prodoc: ultimately having only FTP access really cripples what you can do
[16:01] <awilkins> If you're using Windows you can do worse than Beyond Compare 2 for deploying webs over FTP
[16:02] <awilkins> It even utilises the remote CRC function if your FTP server supports it, cuts down your transfer times
[16:03] <awilkins> Will also note which files on either side are newer
[16:46] <Prodoc> I think I'll search for a better solution. In the mean time, how to I commit changes to my local branch using Exclipse?
[17:59] <shaya> in bazaar, how does one revert a patch in the middle?
[17:59] <shaya> i.e. revisions 1 2 3 4 5, want to undo revision 3?
[18:00] <shaya> is there an automated way, or does one have to do it manually (make a patch that is version 3, patch in reverse, commit)
[18:00] <LeoNerd> bzr merge -r 3..2
[18:00] <LeoNerd> ((or maybe 4..3   I forget offhand))
[18:01] <shaya> I'd assume 3..2 probably
[18:01] <LeoNerd> It's the reverse of the change from rev2 to rev3, so I guess that sounds right
[18:02] <shaya> thanks
[18:10] <shaya> here's a bigger issue
[18:10] <shaya> on my feisty box
[18:10] <shaya> ImportError: No module named bzrlib
[18:10] <shaya> this is using the unbuntu package
[18:11] <shaya> do I really need a PYTHONPATH on ubuntu?
[18:28] <Stavros> hello
[18:29] <Stavros> is there a good bzr plugin for eclipse?
[18:37] <Prodoc> Stavros : are there more then one?
[18:37] <Prodoc> http://bazaar-vcs.org/BzrEclipse
[18:37] <Stavros> Prodoc: no idea
[18:37] <Stavros> is it good?
[18:38] <Prodoc> can't tell yet, just started playing with it but I it's a bit confusing
[18:38] <Prodoc> and it's far from complete
[18:38] <Stavros> ah, hmm
[18:38] <Prodoc> (see the website)
[18:38] <Stavros> well, i just installed subclipse and i have no idea how even that works
[18:38] <Prodoc> haha
[18:39] <Stavros> eclipse is confusing :/
[18:39] <Stavros> where IS everything :(
[18:39] <Prodoc> it's a bit of getting used to yes
[18:39] <Prodoc> too many options
[18:39] <Stavros> yeah
[18:39] <Prodoc> too many shortcutsd
[18:39] <Stavros> but pydev is great
[18:39] <Prodoc> -s
[18:39] <Prodoc> -d
[18:39] <Prodoc> darn
[18:39] <Stavros> haha
[18:40] <Stavros> hortcuts?
[18:40] <Stavros> i looked into buying pydev but you can only rent it, apparently
[18:40] <Prodoc> shortcutsd -d
[18:40] <Prodoc> typo
[18:40] <Stavros> i know :P
[18:41] <Prodoc> let me know if you manage to find a BzrEclipse manual ;-)
[18:41] <Stavros> will do
[18:41] <Stavros> but first i must find bzreclipse :P
[18:41] <Prodoc> http://bazaar-vcs.org/BzrEclipse
[18:42] <Stavros> no, i installed it
[18:42] <Stavros> i need to find it in eclipse :p
[18:42] <Prodoc> haha
[18:42] <Odd_Bloke> Stavros: PyDev is under the Eclipse Public License.
[18:42] <Stavros> Odd_Bloke: pydev extensions isn't, though
[18:43] <Odd_Bloke> Stavros: Ah, I see.
[18:43] <Prodoc> Stavros: finding the settings is the easy bit, as far as I can tell all the rest is in the file context menu
[18:43] <Stavros> oh hmm
[18:43] <Prodoc> in the explorer
[18:44] <Stavros> aha
[18:44] <Prodoc> but that might only appear if you're viewing an actual branch
[18:44] <Stavros> oh hmm, let me create a project then
[18:45] <Stavros> damn its eyes, i can't create a project in an existing folder
[18:45] <Stavros> anyway this isn't #eclipse, so i'll keep my ranting to myself :p
[18:46] <Prodoc> Stavros: I assume you'll get less help for bazaar in exclipse in that channel than here
[18:46] <Stavros> haha, true
[18:47] <Stavros> it's ok though, i found the file browser so it should be there
[18:47] <Stavros> i have to go now, thanks for your help
[18:47] <Prodoc> np
[19:59] <thatch> I'm using bzr 1.2 with a 1.1 server over bzr+ssh... I got the "Server is too old for fast get_parent_map", is that supposed to break locks itself before reconnecting?
[20:01] <thatch> I ctrl-c'd the second password prompt, then had to break the lock myself even though the process had exited when the first ssh session was over (I think)
[20:05] <james_w> thatch: I imagine it might hold the lock so that it knows no-one else nipped in while it was reconnecting.
[20:06] <james_w> I don't know how it works though, so I'm just speculating.
[20:06] <lifeless> hi james_w
[20:07] <lifeless> thatch: it won't break the lock before reconnecting
[20:07] <lifeless> thatch: the server is stateless
[20:07] <james_w> hi lifeless
[20:08] <mib_oa5m0u19> having an issue with merging where I get "nothing to do" even though there are changes - anyone able to help?
[20:08] <lifeless> mib_oa5m0u19: what do you mean
[20:09] <mib_oa5m0u19> if I create a feature branch off a main branch and make some changes, then try to merge those changes into the main branch using bzr merge, I just get "nothing to do"
[20:10] <lifeless> mib_oa5m0u19: are your changes visible in 'bzr missing $feature_branch_url' or 'bzr log $feature_branch_url'
[20:10] <Odd_Bloke> mib_oa5m0u19: You need to have commited the changes in the feature branch.
[20:11] <mib_oa5m0u19> ok, so when I am in the feature branch
[20:11] <mib_oa5m0u19> I type bzr commit?
[20:11] <mib_oa5m0u19> (this is my first time using bzr, btw....)
[20:11] <Odd_Bloke> mib_oa5m0u19: 'bzr commit -m "<message>"', where <message> describes the changes you've made.
[20:12] <mib_oa5m0u19> great thanks
[20:12] <mib_oa5m0u19> that was the issue - i just didn't realize i had to had the -m option
[20:12] <mib_oa5m0u19> works now
[20:18] <Vadi> This is purely a cosmetics question, but when I do bzr branch <link>, it makes a folder with the branch name (ie, if my project name is vadi-mapper and branch is main, it'll make a folder called main). Is it possible to name the folder after the project name instead, not the branch?
[20:18] <Odd_Bloke> Vadi: 'bzr branch <from> <to>'
[20:19] <Vadi> So instead of "bzr branch http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main", try "bzr branch http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main vadi-mapper" ?
[20:20] <Odd_Bloke> Vadi: Yup.  Or you can just 'mv main vadi-mapper'. :p
[20:21] <Vadi> That would be like... whole 2 commands. Too much!
[20:21] <Odd_Bloke> This is true, but if you've already branched it once, then branching it again is almost certainly slower. :)
[20:22] <Vadi> -grin- thanks for the help
[20:24] <Vadi> Can I make bzr remember what location to push to, instead of asking everytime?
[20:24] <Odd_Bloke> Vadi: Have you tried pushing without specifying a location?
[20:25] <Vadi> Yes, and it complained - "No push location known or specified."
[20:25] <Odd_Bloke> Vadi: Sorry, have you tried pushing once with a location and then again without?
[20:26] <Vadi> Oh, that worked. Okay, excellent.
[20:27] <james_w> Vadi: if you are using launchpad then bzr branch lp:vadi-mapper will probably do what you want.
[20:28] <Vadi> Yes, I was told that wouldn't work on non-ubuntu though and the link is a better way to go
[20:28] <james_w> it should work on non-ubuntu, unless the launchpad plugin is disabled on whatever platform you are on.
[20:29] <thatch> lifeless: I put 1.1 back on the server and I'm able to reproduce the lock-left-open situation
[20:29] <Vadi> Is it enabled by default in mac/windows too?
[20:29] <lifeless> thatch: if you are hitting control-C rather than putting your password/key in again, then this is expected
[20:30] <lifeless> thatch: because at the point of reconnect we have a held lock. Then we drop the link. Then you interrupt bzr before it gets a new link.
[20:30] <lifeless> thatch: there is no way to remove the lock at that point :)
[20:31] <thatch> lifeless: hmm. so if users go "Oh! Yeah, I forgot to update bzr on the server" they must proceed to completion instead of stopping now to upgrade?
[20:31] <lifeless> thatch: or break the lock
[20:32] <lifeless> thatch: Its not beautiful, but really - what can we do about it that is both correct (dropping the lock isn't) and robust (asking for *another* password to break the lock when you hit enter is going to be confusing)
[20:32] <lifeless> when you hit ctrl-C I mena
[20:33] <thatch> lifeless: Yeah, you're between a rock and a hard place there.  The "entering the password twice" situation didn't actually get to me until after I'd entered the first of the pair though :)
[20:34] <Vadi> Odd_Bloke: I got a bit stumped on the push isntructions. The first time I'd do it it would be "bzr push b zr+ssh://vperetokin@bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main" - but that has my username in it. I'd tell the user to use their own launchpad name, yeah?
[20:35] <Odd_Bloke> Vadi: Probably.
[20:35] <Odd_Bloke> It does depend on your workflow.
[20:36] <Vadi> Well, the vadi-mapper-dev is a team I made.
[20:37] <Vadi> So people join in the team. Theoretically. So far someone has joined who I have no idea they are
[20:37] <lifeless> Vadi: the bit USER@bazaar...
[20:37] <lifeless> Vadi: that is who *you* are, so launchpad will allow you access to your teams etc
[20:37] <Vadi> ahh
[20:38] <lifeless> for instance, if I was a collaborator that you allowed into the vadi-mapper-dev team
[20:38] <lifeless> then I would use bzr+ssh://myname@bazaar.launcpad.net/~vadi-mapper-dev/vadi-mapper/main
[20:39] <Vadi> right, okay
[20:39] <Vadi> Um, be right back, something is really wrong with my X - it's been hogging the both cpu's at 50% for a while now and even the fans turned on.
[20:51] <lifeless> beuno: ping
[20:58] <bialix> hi, I have question about loom plugin
[20:59] <james_w> hi bialix
[20:59] <bialix> hi james_w
[20:59] <lifeless> hi bialix
[20:59] <lifeless> bialix: ask away
[21:00] <bialix> why for 'record' command is needed
[21:00] <bialix> ?
[21:00] <lifeless> to version the loom
[21:01] <bialix> I'm using loom for versioning my own package for our custom Slackware Linux. I did commit, but not record. Is it wrong?
[21:01] <lifeless> bialix: cool
[21:02] <bialix> record seems strange for me
[21:02] <lifeless> bialix: its not wrong; but you can't share the loom with other people - merge at the loom layer - without recording
[21:02] <lifeless> bialix: imagine that you had each thread as a separate directory on disk
[21:02] <bialix> what do you mean 'merge at the loom layer;'?
[21:02] <lifeless> bialix: for me to get the same directories, I would need to list-dir, then branch each one
[21:03] <lifeless> bialix: the loom is a text file that lists branch names & revision ids.
[21:03] <bialix> but commit did update loom references for heads
[21:03] <lifeless> bialix: commit updates the revision ids yes.
[21:03] <bialix> why I need record?
[21:03] <lifeless> bialix: if you want to give me a copy of the loom
[21:04] <lifeless> bialix: or if you want to see what the loom looked like some days ago
[21:04] <lifeless> as bzr help loom says -
[21:04] <bialix> I thought the loom is just metaphor around several heads in one branch. Is it not?
[21:04] <lifeless> its more than that
[21:05] <bialix> when I do bzr log I see ordinal bzr history with merges
[21:05] <lifeless> it can also _version_ that list
[21:05] <bialix> how can I see the version from record?
[21:05] <bialix> I mean log?
[21:05] <lifeless> I haven't written a command to do that yet ;)
[21:06] <bialix> there is no loom-log
[21:06] <lifeless> if you do a record
[21:06] <lifeless> and then do bzr heads --dead-only
[21:06] <bialix> so it should be additional command?
[21:06] <lifeless> yeah, or perhaps an option to 'bzr log'
[21:07] <lifeless> perhaps bzr log should just annotate the output with thread details; and have an option to only show the history of the loom
[21:08] <bialix> something odd in my head. loom have 2 different histories?
[21:08] <lifeless> yes. history of the _loom_, and _history of the source code_
[21:09] <lifeless> normal branches only have _history of the source code_
[21:11] <bialix> can you point me to actual code?
[21:12] <bialix> loom history goes to repository storage?
[21:14] <bialix> at first I thought that loom islike named branches in hg. but then I understand it's not. but I have no experience with Mercurial Queue though.
[21:15] <lifeless> branch.py - LoomMetaTree, and record_loom
[21:15] <beuno> lifeless, pong
[21:15] <lifeless> and pull sa well
[21:15] <lifeless> pull *as well*
[21:15] <lifeless> beuno: hi, re debian packages and bazaar/bzr
[21:16] <lifeless> beuno: will you be doing the packaging patches and sending to BTS ?
[21:18] <beuno> lifeless, for Ubuntu?  I'm neither DD nor UD, so I can't really upload to anywhere. I'll be more than glad to help out doing the heavy lifting though
[21:19] <bialix> lifeless: record is calling regular commit under the hood?
[21:19] <lifeless> beuno: please do :)
[21:20] <lifeless> beuno: for me its just time, if we have patches in the BTS its a big help
[21:20] <lifeless> beuno: (and I'm ubuntu-dev, but not ubuntu-core-dev, so can't upload some of it anyhow)
[21:20] <lifeless> bialix: yes, for a separate tree
[21:20] <lifeless> bialix: the separate tree contains one file
[21:20] <bialix> separate tree?
[21:21] <lifeless> called 'loom' with fileid 'loom_meta_tree'
[21:21] <lifeless> bialix: yes, the loom project
[21:21] <beuno> lifeless, alright, sounds good, we'll find someone to bug. This would basically be making "bazaar" install baz and bzr, right?  The first step
[21:21] <lifeless> bialix: really, try doing heads --dead-only after a record
[21:21] <lifeless> beuno: yeah, whatever we said the other day :>
[21:22] <bialix> lifeless: ok will do
[21:22] <lifeless> bialix: then branch the revision you file to /tmp/whatever
[21:22] <lifeless> bialix: and have a look at whats there :)
[21:23] <beuno> lifeless, hehe, alright. I'm getting on a plane in a few hours towards Madrid, so I'll be offline for a day or so. I'll take a look at it and see if we can have that done during the sprint. Sound good?
[21:23] <bialix> ok, I think separate tree is a bit of hack. But if I need commit additional file along with dirstate. How I should do it?
[21:23] <james_w> lifeless: confirmed status still exists doesn't it? Or has it been removed on edge?
[21:24] <lifeless> james_w: I was whinging because confirmed is useless now
[21:24] <lifeless> james_w: if its not triaged it will get deleted.
[21:24] <lifeless> bialix: cool
[21:24] <lifeless> bialix: sorry, wrong nickname
[21:24] <lifeless> beuno: cool
[21:24] <james_w> beuno: I'll be happy to work on it during the sprint if it's not done by then.
[21:25] <james_w> beuno: with you of course, I forgot those two words :)
[21:25] <lifeless> bialix: separate tree is for the loom metadata only; I'm trying to make the guts visible to you.
[21:25] <james_w> lifeless: that does sound wrong to me.
[21:25] <lifeless> bialix: anything for your normal source code just do what you do with bzr commit
[21:26] <beuno> james_w, great, thanks. Glad that's getting done in time.
[21:26] <bialix> lifeless: yes, I understand intend
[21:26] <mwhudson> lifeless: it's only incomplete bugs that get expired, and only if the project switches that feature on
[21:26] <lifeless> mwhudson: its incomplete if its < triaged is it not ?
[21:26] <lifeless> mwhudson: that was my understanding
[21:26] <mwhudson> incomplete is a separate status
[21:27] <lifeless> mwhudson: anyhow, write this up to 'user got bitten, user remembers workaround _forever_'
[21:27]  * beuno goes continue packing
[21:27] <mwhudson> lifeless: thus, we must never make mistakes
[21:28] <mwhudson> lifeless: it's even documented! https://help.launchpad.net/BugExpiry
[21:28] <lifeless> mwhudson: righto, so it has changed :)
[21:29] <lifeless> mwhudson: never making mistakes is not a corollary to what I said :)
[21:29] <mwhudson> the fact that so many bugs got expired the first time it run was a bad bad bug
[21:29] <lifeless> mwhudson: indeed
[21:30] <lifeless> mwhudson: I simply had remember the workaround for the initial implementation
[21:30] <lifeless> mwhudson: because that got rather effectively burnt in
[21:36] <bialix> does launchpad means 'area where rockets launch to outer space'?
[21:36] <lifeless> yes
[21:36] <bialix> thanks
[21:44] <ig1> morning all
[21:49] <abentley> lifeless: mats is specifically complaining that wget -c doesn't skip files he's already downloaded.
[21:53] <Verterok> Prodoc: I'm working in bzr-eclipse, there is no Manual (yet)
[21:55] <Verterok> Prodoc: in the meantime shoot any question you have about it :-)
[21:55]  * Verterok says Hi to everyone 
[21:56] <Prodoc> yeah, I noticed :-( It took me some time to figure it out being new to eclipse and bazaar but I finally found out how to use it. I took the liberty to add the very basis to the installation page if you don't mind ;-)
[21:58] <Prodoc> (http://bazaar-vcs.org/BzrEclipse/Installation Kick-start section) though it might need some more clarification, like I said, I'm new to both so this only counts for a clean setup
[21:59] <Prodoc> so additional steps might be required and there might be different methods as well
[22:00] <Prodoc> at least this actually gave me the all the actions like commit, etc.
[22:01] <Verterok> Prodoc: great, thanks! it's a wiki, y're wellcome to edit it :-)
[22:01] <Verterok> it's looks good :-D
[22:02] <Prodoc> This should be sufficient for the new users, other don't really need it, more should go in a separate manual
[22:02] <Prodoc> others
[22:03] <james_w> hi Verterok
[22:04] <james_w> hi igc
[22:04] <Verterok> sure, it was my mistake to assume that everyone using bzr-eclipse will know eclipse :)
[22:04] <Verterok> Prodoc: I'm planing to add Help integrated in the Eclipse help system, but first it must be written :P
[22:04] <Verterok> james_w: hi
[22:05] <Prodoc> Verterok: what is the opposite of the 'Share Project...' action? First I thought it was Disconnect but I've got the feeling that this applies to the branch, not just the removal of the Bazaar stuff in Eclipse because of the confirmation dialogue
[22:05] <Prodoc> to get rid of the Bazaar stuff again
[22:05] <Prodoc> in Eclipse
[22:06] <Verterok> Prodoc: for the moment Disconnect only remove bzr-eclipse support from the Project, but it'll let you choose to completely wipe bzr control files
[22:08] <Verterok> I take a conservative approach on this, mainly because I usually kill the branch (and the working tree) when I merge it in trunk
[22:08] <Prodoc> ok, so it's save to use it? It won't kill the branch?
[22:09] <Verterok> Prodoc: sure :). For the moment bzr-eclipse maps each command with the corresponding CLI one.
[22:10] <Verterok> it only removes bzr-eclipse support
[22:10] <Prodoc> ok, cool :-)
[22:15] <Prodoc> It might be an idea to change the message from 'Are you sure you want to disconnect Bazaar from '<project name>'' to something like 'Are you sure you want to disconnect Bazaar from the Eclipse project '<project name>'?' With or without including 'Eclipse' (note the question mark as well ;-) ) to make it clear that it doesn't do anything to the files/branch but only to the Eclipse project.
[22:16] <Prodoc> e.g. the project name and containing folder name are identical, hence the confusion
[22:17] <Verterok> Prodoc: it's sound ok. could you fill a bug about this?
[22:18]  * Verterok brb
[22:18] <Prodoc> Verterok: or maybe Bazaar should be changed to something else as well make indicate that it's the plugin we are dealing with, not an actual bazaar action
[22:21] <ubotu> New bug: #195927 in bzr "bzr commands not available after suspend-to-disk" [Undecided,New] https://launchpad.net/bugs/195927
[22:36] <lifeless> hi poolie
[22:36] <lifeless> do you want a lift to the airport?
[22:38] <poolie> hello
[22:38] <poolie> that would be nice
[22:39] <poolie> i think you said you were aiming to get there at 4 - the flight is at 6 so that's a bit tight...
[22:43] <mwhudson> this code raises an exception: http://paste.ubuntu-nl.org/57523/
[22:43] <mwhudson> is it doing something silly?
[22:43] <mwhudson> (this is what prevents viewing an empty branch with loggerhead right now)
[22:44] <poolie> hm
[22:45] <poolie> i kind of think you're meant to create a memoryserver and get a transport from that
[22:45] <poolie> but presumably that's not what's breaking
[22:45] <poolie> so presumably the problem is that get_revision_graph doesn't like being given the null revision?
[22:45] <poolie> that would probably be a bug
[22:46] <mwhudson> no, it's the merge_sort that fails
[22:46] <mwhudson> sorry, perhaps i should have been more clear
[22:47] <poolie> it doesn't like being given an empty graph?
[22:47] <mwhudson> b = "get me a branch with no revisions in it"
[22:47] <mwhudson> right
[22:47] <Prodoc> time for a nap again, goodnight all
[22:47] <poolie> just a bug, presumably
[22:47] <poolie> should be trivila
[22:47] <mwhudson> poolie: ok
[22:47] <poolie> could you try to write a test for it?
[22:47] <poolie> it may just need an adjustment to an 'if' in tsort
[22:49] <mwhudson> hm, maybe this is a fallout from the move to using "null:" for the null revision
[22:53] <mwhudson> oh grr, i can't import NULL_REVISION in tsort.py :/
[22:55] <mwhudson> poolie: this seems to suffice http://paste.ubuntu-nl.org/57525/ but it's not clean at all
[22:56] <poolie> you can't import it because of circular dependencies?
[22:58] <mwhudson> yeah
[22:58] <mwhudson> revision imports deprecated_graph imports tsort
[22:58] <poolie> well, just import the module then and do mod_revision.null_revision
[22:58] <poolie> thisi s done elsewhere
[22:58] <poolie> if you could also just add a test you have my +1
[22:59] <mwhudson> that doesn't work either
[22:59] <mwhudson> poolie: i did add a test, or a line to a test
[22:59] <mwhudson> maybe something to do with lazy imports?
[23:03] <poolie> yes could be
[23:03] <igc> poolie: call on today?
[23:04] <poolie> yes
[23:04] <mwhudson> seems not, found a workaround though
[23:04] <mwhudson> (sometimes it amazes me that any python program manages to import anything at all)
[23:18] <mwhudson> boy, there seem be a lot of unused imports in bzrlib
[23:18] <johnny> you guys using pylint or pychecker ?
[23:20] <bob2> lazy_import breaks them
[23:20] <johnny> fun...
[23:25] <spiv> Yeah, there are a few.
[23:25] <spiv> johnny: I use pyflakes sometimes, but lazy_import gets in the way.
[23:26] <spiv> pyflakes works a module at a time though, so it's fairly easy to comment out the lazy_import magic in a single module, run pyflakes on it, and then uncomment the magic.
[23:31] <mwhudson> spiv: "a few"?
[23:31] <mwhudson> you must have not looked recently :-)
[23:34] <spiv> mwhudson: I have a hackish branch at http://people.ubuntu.com/~andrew/bzr/faster-startup that removes some unused imports, among other things.
[23:35] <spiv> mwhudson: but I haven't tried checking many modules, just those that tend to be imported all the time.
[23:36] <mwhudson> spiv: well, i started alphabetically and spent 10 minutes on "branch.py" :)
[23:36] <mwhudson> (after option.py which was where i first noticed some silliness)
[23:49] <bignose> I'm getting an error <URL:http://pastebin.ca/919766> trying to 'bzr upgrade'
[23:49] <bignose> the upgrade is prompted by a 'bzr commit' giving "Repository KnitPackRepository('sftp://bzr@fs/%7E/.bzr/repository/') is not compatible with repository KnitRepository('file:///home/bignose/Projects/.bzr/repository/')"
[23:49] <bignose> when I attempt to upgrade, I get the error shown at the pastebin URL above.
[23:50] <bignose> how can I get the commit to succeed?
[23:50] <bob2> bzr upgrade --rich-root
[23:50] <bignose> why, then, is that not the default?
[23:50] <spiv> bzr upgrade --rich-root-pack
[23:50] <bignose> or rather, why is something not-default actually necessary for this commit to succeed?
[23:51] <jamesh> bignose: because you're using bzr-svn?
[23:51] <bob2> does the repository you're commotting to have svn branches in it?
[23:51] <spiv> bignose: it's a bug, really.  What's happened is that you have a repo that is in a format that was never the default.
[23:52] <bignose> jamesh: I'm not.
[23:52] <jamesh> hmm
[23:52] <jamesh> then I wonder how your repo got into a richroot format?
[23:53] <spiv> bignose: and the default "bzr upgrade" doesn't have the smarts to pick a compatible (and again, non-default) format to upgrade to.
[23:55] <bob2> which non-default repo format?
[23:55] <bignose> okay. so, again, what do I need to do to fix this?
[23:55] <ubotu> New bug: #195962 in bzr "send -f (using bzr-svn): 'FakeControlFiles' object has no attribute 'put'" [Undecided,New] https://launchpad.net/bugs/195962
[23:56] <bignose> bob2: I don't know. either of the ones that has been suggested here, which clearly aren't the default otherwise I wouldn't need to give an option to use them.
[23:56] <spiv> bob2: IIRC, bzr upgrade tries to upgrade pack-0.92 atm, but this needs rich-root-pack.
[23:57] <bignose> I vaguely recall performing a non-default 'bzr upgrade --foo-bar' suggested by someone in this channel to fix some earlier bug
[23:58] <bignose> so that may explain why it's currently in a non-default format
[23:58] <bignose> I'd be very happy to get the repo to a state where everything will work, including default 'bzr upgrade' in future.
[23:59] <bignose> but my immediate problem is to get this commit working
[23:59] <bignose> so, what do I need to do in order for a commit to this branch to succeed?