[01:00] <igc> so my focus for today is reviews, namely poolie's ones on LockableFiles and jam's ones on graph ops
[01:16] <poolie> igc, any opinion on 'agile' vs 'adaptive version control'?
[01:27] <igc> poolie: I'm ok with Agile version control
[01:27] <beuno> agile seems a bit complicated for non-english speakers, doesn't it?
[01:28] <igc> I prefer adaptive but that's because I wrote a blog article on what that is :-)
[01:29] <beuno> agile is a good word, but most people won't know what it means
[01:29] <beuno> might not be a good reason to reject, but I thought I'd throw it out there
[01:30] <igc> beuno: it means something very specific in this content i.e. the Agile Development movement
[01:31] <igc> I see open source as being the next generation of process beyond Agile - there's a large focus in SCRUM/XP on all being in the same room
[01:31] <poolie> i wonder if "agile" will be out of fashion in a few years
[01:31] <poolie> oh well
[01:33] <igc> Adaptive takes more explaining - that's true - so Agile is good enough
[01:34] <igc> I don't think Agile will go out of fashion any more than OO went out of fashion
[01:35] <igc> Like OO, I think it will get incorporated into most approaches over time and there will something more fashionable in a few years
[01:40] <igc> poolie: Hmm - let me respond to the email and I'll plug adaptive for one last time :-)
[02:01] <poolie> igc, i'm happy with either
[02:28] <poolie> spiv, i thought you fixed bug 220806, but it's still marked open
[02:29]  * spiv looks
[02:31] <poolie> if not you don't need to do it right now, it was just still flagged in my mail
[02:32] <spiv> Oh, I see the root cause.
[02:32] <spiv> The attribute is defined on SmartClientStreamMedium rather than SmartClientMedium
[02:32] <spiv> Fixing that is trivial.
[02:40] <beuno> vila, docs for bzr-upload committed  :)
[02:44] <spiv> poolie: http://rafb.net/p/5bJz9I27.html is the fix
[02:45] <spiv> poolie: is it ok with you if I merge that, even without adding tests?  We don't have any "medium-implementations" tests unfortunately :(
[02:48]  * spiv sends it to the list
[03:55] <libwilliam> I am having an issue with WorkingTree.get_ignore_list() and I was hoping someone might realize what I am doing wrong. I think the main problem is my lack of knowledge on Python Lists and Tuples. Here I am passing in a working tree and trying to print out the list of ignored files. http://pastebin.com/m7fb33e08
[03:56] <libwilliam> SystemError: ../Objects/listobject.c:137: bad argument to internal function
[03:56] <libwilliam> I end up with that error on the size function, which is making me think the get_ignore_list isn't returning a list
[03:57] <libwilliam> Atleast a list in the C/Python way of being a list.
[04:00] <Odd_Bloke> libwilliam: get_ignore_list returns a Python set.
[04:01] <libwilliam> ok, i'm going to tweak the code for a set and see if I have any luck, thanks Odd_Bloke
[04:01] <pickscrape> Is there some way to debug authentication.conf? i.e. to find out if the file is being picked up, which rules are being applied etf.
[04:01] <pickscrape> etc
[04:03] <spiv> libwilliam: rather than assuming get_ignore_list returns a specific type, you ought to just treat it as a generic iterable I think.
[04:04] <spiv> libwilliam: see http://docs.python.org/api/iterator.html
[04:06]  * pickscrape tries -Dauth, but it does nothing :(
[04:08]  * spiv -> lunch
[04:08] <libwilliam> ill try that out spiv, thanks
[04:08] <spiv> pickscrape: have you looked in ~/.bzr.log after using -Dauth?
[04:08]  * spiv -> really lunch
[04:10] <pickscrape> I hadn't, but having done so I see no difference in the output...
[04:35] <pickscrape> Grr. -Derror and -Dhpss are doing things, but -Dauth is doing absolutely nothing. :(
[04:39]  * igc lunch
[05:17] <spiv> PQM is still surprisingly slow.
[05:17] <spiv> Output like this looks particularly weird: [ascii] ..._converged_merge_dir_changes(RepositoryFormat5)   OK                  86ms
[05:17] <spiv> [ascii] ..._converged_merge_dir_changes(RepositoryFormat6)   OK                  88ms
[05:17] <spiv> [ascii] ...erged_merge_dir_changes(RemoteRepositoryFormat)   OK               16261ms
[05:24] <poolie> spiv, yes, john mentioned that this morning
[05:24] <poolie> will send mail
[05:28] <poolie> done
[05:38]  * igc pick up kids
[06:05] <poolie> igc, are you back?
[06:10] <igc> yep
[06:10] <igc> poolie:^
[06:17] <lifeless> moin
[06:32] <vila> morning all
[06:32] <demod> morning
[06:33] <vila> pickscrape: if -Dauth outputs nothing, it means it's not involved, what is your use case ?
[06:33] <vila> beuno: you rock :)
[06:51] <poolie> hello vila
[06:57] <igc> poolie: you dropped out
[07:03] <chandlerc> anyone able to help me with a data loss issue?
[07:07] <Peng> Not me, but what's going on?
[07:09] <chandlerc> i did a bzr upgrade, which failed, and upon restoring backup.bzr, bzr refuses to acknowledge the repository as existing
[07:10] <chandlerc> obviously, this is extremely bad, and seems to have erased a large portion of my history
[07:10] <chandlerc> =[
[07:11] <chandlerc> namely, everything that didn't happen to get shoved into subversion for ohloh.net and other tools to aggregate... all the move information and a lot of the other important VCS info was in the bzr repository, along with several un-pushed commits
[07:11] <spiv> chandlerc: maybe https://bugs.edge.launchpad.net/bzr/+bug/145812 ?
[07:11] <beuno> vila, :)
[07:12] <spiv> chandlerc: is there a repository.backup in the .bzr ?
[07:12] <chandlerc> yes
[07:12] <spiv> But no repository?
[07:12] <spiv> If so, move the 'repository.backup' to 'repository' and that is likely to fix it.
[07:13] <spiv> Probably safest to manually copy the whole thing first, though.
[07:13] <spiv> Just in case.
[07:13] <chandlerc> is there any chance to damage? ok
[07:13] <chandlerc> yea, i moved backup.bzr to .bzr hurridly assuming it would get me instantly back to a working state
[07:13] <chandlerc> paying for that now
[07:13] <spiv> It should be safe, but if nothing else typos are far too easy to make :)
[07:14] <chandlerc> it would be _really_ awesome if --upgrade were less fragile, and the restoration process a bit more fool-proof... it appears i'm adding to the number of fools in the world here
[07:14] <spiv> It'd be great if you could add a comment to that bug after you've repaired your repo.
[07:14] <chandlerc> ok
[07:15] <spiv> Assuming it looks like the same bug, of course.  Otherwise, file a new bug :)
[07:15] <beuno> hey james_w  :)
[07:16] <james_w> hi beuno. How are you?
[07:16] <beuno> great video you recorded on bzr and ubuntu, congrats
[07:16] <chandlerc> that bug isn't very informative sadly, so i'm not sure if its the same as what i'm hitting
[07:16] <spiv> chandlerc: fair enough, file a new one then
[07:16] <spiv> chandlerc: it's easy to combine them later if it turns out to be a duplicate
[07:17] <beuno> james_w, pretty good, you?
[07:17] <james_w> beuno: good thanks, though UDS is pretty tiring.
[07:18] <james_w> the video is out?
[07:18] <beuno> james_w, your first one?
[07:18] <beuno> james_w, http://www.youtube.com/ubuntudevelopers
[07:18] <james_w> second
[07:18] <beuno> 145 views already  :p
[07:18] <james_w> oh :-(
[07:18] <james_w> not sure I want to watch it.
[07:18] <beuno> that's a good thing, isn't it?
[07:19] <james_w> it's quite embarrasing
[07:19] <spiv> chandlerc: did moving that directory fix things?
[07:19] <chandlerc> sorry, making copious backups
[07:20] <spiv> Ah, right :)
[07:20] <beuno> james_w, not at all. It's a great explanation on where Ubuntu is going package-wise, and a great plug for bzr  :)
[07:20] <lifeless> poolie: igc: ping
[07:20] <chandlerc> spiv: brilliant... it seems to have fixed it
[07:21] <spiv> chandlerc: great!  Glad I could help.
[07:21] <chandlerc> so i should file a bug asking for a better recovery process?
[07:21] <chandlerc> ;]
[07:22] <spiv> chandlerc: well, just for upgrade not to break, or at least fail safely.
[07:22] <chandlerc> it failed safely, just with no obvious path to recover it. ;]
[07:22] <chandlerc> its more of a UI bug then a functionality bug
[07:23] <spiv> Well, fail gracefully :)
[07:23] <chandlerc> hehe
[07:23] <chandlerc> yea
[07:23] <chandlerc> i'd like large and detailed instructions about what to, and not to do in the event of a failure to maximally protect the history
[07:23] <spiv> Backup .bzr of the branch (and of the shared repository, if any).
[07:24] <chandlerc> sorry, i meant in the error message from the failed upgrade
[07:24] <spiv> Ah, right.  Well the right thing is to stop upgrade from leaving things in a damaged state.
[07:24] <chandlerc> basically, i felt like i understood the recovery process, and i apparently didn't
[07:25] <spiv> A message with recovery instructions might be an ok band-aid in the short term, but we really shouldn't require users to poke in .bzr.
[07:25] <lifeless> spiv: is poolie are your place?
[07:25] <chandlerc> that first part being the far more dangerous component... ignorence is fine, i'll come here and find wonderful people like you... it was my rash early attempt to fix it that scared me
[07:25] <spiv> lifeless: not today, no
[07:25] <chandlerc> fair enough
[07:25] <lifeless> spiv: kk
[07:25] <chandlerc> i'll just tack on a message to that bug since its already in the same ballpark
[07:25] <lifeless> spiv: I want to grab him and Ian to talk about this 'is a format required' thing
[07:26] <lifeless> it seems to be generating angst; and thats sad
[07:27] <chandlerc> with a more tricky (but less upsetting) question, anyone around familiar with bzr-svn?
[07:27] <chandlerc> got a weird assertion pushing my latest batch of changes over to the svn server
[07:28] <lifeless> somewhat familiar
[07:28] <chandlerc>   File "/home/chandlerc/.bazaar/plugins/svn/transport.py", line 149, in add_file
[07:28] <chandlerc>     assert self.recent_baton[-1] == parent_baton
[07:29] <lifeless> so presumably either the baston as been popped; or was not added
[07:29] <chandlerc> ??
[07:29] <lifeless> I would probably add some more logic there to try and be more precise in the error
[07:29] <lifeless> baton's are callbacks used by the svn library to obtain commit messages and so on
[07:30] <spiv> like 'assert self.recent_baton[-1] == parent_baton, "recent_baton: %r, parent_baton: %r" % (self.recent_baton, parent_baton)'
[07:30] <chandlerc> is it because a moved A -> B, and added a new file A, within the same commit?
[07:31] <spiv> (Although that probably won't be hugely revealing.)
[07:32] <lifeless> chandlerc: I don't have enough to speculate on the cause yet
[07:32] <lifeless> chandlerc: I wouldn't assume that that is the cause; though it may be :P
[07:32] <chandlerc> assert self.recent_baton[-1] == parent_baton, "recent_baton: %r, parent_baton: %r" % (self.recent_baton, parent_baton)
[07:32] <chandlerc> AssertionError: recent_baton: [<libsvn.core.GenericSWIGWrapper instance at 0x15e2ea8>, <libsvn.core.GenericSWIGWrapper instance at 0x17c7290>, <libsvn.core.GenericSWIGWrapper instance at 0x17c7248>, <libsvn.core.GenericSWIGWrapper instance at 0x17c7560>], parent_baton: 'https://inc.googlecode.com/svn/parser/trunk/test/expression_node_test.cpp'
[07:33] <chandlerc> happy to keep shoving code in here. =]
[07:33] <chandlerc> i can also provide access to the bzr repository if it helps
[07:33] <lifeless> wheeee parent_baton is invalid
[07:33] <spiv> Well, that was surprise :)
[07:33] <chandlerc> expression_node_test.cpp is one of the files i added...
[07:35] <chandlerc> specifically thats the A file i added, after moving the existing file of that name to B
[07:35] <chandlerc> ;]
[07:35] <lifeless> first step; file a bug
[07:36] <spiv> I suspect the add_file call around line 255 of commit.py is missing a 'baton' parameter after the 'full_new_child_path' parameter.
[07:36] <spiv> (judging from the invocation 10 lines higher up)
[07:36] <spiv> But there's a large degree of guesswork in that, so filing a bug is probably best :)
[07:37] <uniscript> dummy question: if I branch base to tidyup and cd tidyup, what command do I need to do to merge such that I can remove a particular revision from tidyup?
[07:38] <uniscript> merge -r 80..79 ../base ?
[07:38] <uniscript> (to remove r 80)
[07:38] <beuno> uniscript, bzr uncommit?
[07:38] <lifeless> yes
[07:38] <uniscript> thanks
[07:46] <lifeless> q
[07:46] <poolie> lifeless: hi
[07:46] <lifeless> hi
[07:46] <lifeless> psting you
[07:59] <vila> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
 some lp hacker around ? :-)
[08:00] <Peng> Protocol 3 is only in bzr.dev, right?
[08:00] <spiv> RIght.
[08:00] <Peng> We'll have to wait for 1.6 to be released, and Launchpad to do their what, weekly or monthly upgrades, then.
[08:01] <vila> Peng: could be ;-) Was kidding.
[08:01] <spiv> Yeah, I expect LP will be upgraded quite soon after the 1.6 release.
[08:03] <chandlerc> spiv: bug filed (#232125), would it be safe to add the baton parameter and see what happens?
[08:05] <spiv> chandlerc: My guess is that it would be safe (i.e. it'd either work or fail very quickly), but to be honest I don't know.
[08:05] <chandlerc> i'm willing to try it -- i just made several backups! =]
[08:06] <chandlerc> and the subversion repo isn't my authoritative VCS... if it gets weird, its not a tragedy
[08:06] <spiv> chandlerc: actually, looking a second time, I'm more confident that that is the problem.
[08:06] <chandlerc> it makes sense
[08:06] <chandlerc> especially with what is showing up as parent_baton in add_file
[08:07] <spiv> So feel free to try that fix... but if it breaks you get to keep both pieces! ;)
[08:07] <chandlerc> tried it, and it worked
[08:08] <chandlerc> http://code.google.com/p/inc/source/detail?r=121
[08:08] <chandlerc> the SVN commit successfully appears
[08:08] <spiv> chandlerc: woo!
[08:08] <chandlerc> i'll post the patch to the bug
[08:08] <spiv> chandlerc: it's nice of jelmer to leave easy bugs for us ;)
[08:09] <chandlerc> =]
[08:12] <chandlerc> thx for the help spiv! =]
[08:14] <gour> hi, i'm trying to 'fix' fish-shell's script to include support for bzr-completion...does every short option in bzr's help has the long one as well?
[08:18] <james_w> hi gour
[08:19] <james_w> I'm not sure I understand your question, are you asking whether there are any options that only have the short form?
[08:19] <spiv> chandlerc: glad I could help!
[08:22] <gour> james_w: yes, i've to add support for bzr-completion by tweaking some regexs
[08:24] <james_w> I don't know of any options that are only short
[08:24] <james_w> except perhaps the -D ones, but I'm not sure you even want to complete them.
[08:25] <gour> ok. ta
[08:36] <visik7> I've a problem
[08:36] <visik7> I've my branch locally
[08:37] <visik7> now I run bzr init-repo sftp://remotehost/path/to/repo
[08:37] <visik7> and
[08:37] <visik7> bzr push sftp://remotehost/path/to/repo/branch
[08:37] <visik7> the dir branch is created
[08:37] <visik7> with a .bzr inside
[08:37] <visik7> but there are no other files
[08:37] <visik7> obviously executed inside my local branch
[08:37] <AfC> visik7: That is correct behaviour
[08:38] <visik7> oh can I upload my branch content to the repo ?
[08:38] <visik7> remote repo
[08:38] <visik7> I've also bind the repo remotely
[08:39] <AfC> visik7: there is a "repository" & "branch" there but not a "working tree"
[08:39] <visik7> a working tree here ?
[08:39] <visik7> or there ?
[08:39] <AfC> there
[08:40] <AfC> Locally *only* operations  combine push & update. While this is convenient and makes it Subversion like, it means that bloody well everyone trips over what you are having trouble with right now
[08:40] <AfC> Because it does *not* do an update when operating remotely.
[08:41] <AfC> visik7: (try this:
[08:41] <visik7> so I need to setup a working tree there right ?
[08:41] <AfC> $ bzr missing --line ﻿sftp://remotehost/path/to/repo/branch
[08:41] <AfC> visik7: from within your local branch and you will find that it tells you nothing is wrong)
[08:42] <AfC> visik7: if you need one, yes
[08:42] <AfC> visik7: see the very end of
[08:42] <AfC> $ bzr help working-trees
[08:42] <visik7> bzr missing --line says: Branches are up to date.
[08:42] <AfC> visik7: which it could not have said if there was no branch there. You're all set.
[08:46] <visik7> the help on working tree says something like copy file remotely by hand
[08:46] <visik7> or something like that
[08:47] <visik7> does it make sense ?
[08:58] <visik7> I dunno how to setup a working tree on a remote server
[08:59] <Kinnison> Morning
[08:59] <Kinnison> vila: any progress with those notes?
[09:00] <vila> Kinnison: not yet, sorry, I thought a bit about it though and my overall feeling is that sftp is better for *your* current setup
[09:01] <vila> What I need to do to get a better understanding of the differences is to build a similar setup
[09:01] <vila> Oh, of course, there is a problem with squid
[09:02] <vila> my remark above was taking it out of the picture
[09:02] <Odd_Bloke> visik7: Do you have SSH access to the server?
[09:02] <Kinnison> vila: right. I'm happy to have bzr ignore my proxy for now.
[09:03] <Kinnison> vila: But understanding why http is slower would be nice.
[09:03] <vila> there is a pending bug about bzr ignoring caches anyway
[09:03] <visik7> Odd_Bloke: yes
[09:03] <Kinnison> vila: Does the http code interleave requests?
[09:03] <visik7> Odd_Bloke: I  technically  ignore how to do ir
[09:03] <visik7> it
[09:04] <vila> Kinnison: no. http has a higher overhead than sftp which issue "remote file seeks" while http have to buffer all the seeks in one (or several) requests, build the canned response (server side), uncanned the response
[09:05] <vila> the difference you're seeing may well be explained by the server having to can the response
[09:05] <vila> Kinnison: is that enough as an answer ?
[09:05] <visik7> do I need to checkout on the deploy server ?
[09:05] <Kinnison> :-)
[09:06] <Kinnison> It's something to think about, certainly
[09:06] <AfC> visik7: yes
[09:07] <AfC> visik7: (incidentally, ﻿if you can stick bzr on the server things will work much better)
[09:07] <visik7> AfC: I can't
[09:07] <visik7> :(
[09:07] <visik7> can I checkout on an sftp ?
[09:07] <vila> I didn't check the sftp code, but from memory it can still  be optimized :)
[09:08] <vila> Kinnison: what triggered your comparison in the beginning ?
[09:08] <lifeless> Kinnison: oh, do you have a suqid? what *exact* version
[09:09] <AfC> visik7: {shrug}
[09:09] <AfC> visik7: try it and see
[09:09] <Kinnison> vila: I was miffed with how long it was taking to branch/pull over http
[09:09] <Kinnison> lifeless: give me a sec
[09:10] <Kinnison> Squid Cache: Version 2.6.STABLE14
[09:10] <Kinnison> says 'squid -v'
[09:10] <Kinnison>  *** 2.6.14-1ubuntu2.1 0
[09:10] <vila> Kinnison: is that still the case without using squid ?
[09:10] <Kinnison> says apt-cache policy
[09:10] <Kinnison> vila: It still takes longer than sftp
[09:10] <Kinnison> vila: but not twice as long.
[09:11] <visik7> strange behaviour running   bzr checkout trunk sftp://location/path/branch : bzr: ERROR: sftp://location/path/branch.bzr/ is not a local path.
[09:12] <vila> Kinnison: indeed, so I think the relevant bug is bug #120697
[09:12] <vila> well, not exactly :-/
[09:13] <vila> but strongly related
[09:14] <vila> visik7: os/bzr versions ? You may need to install paramiko to activate sftp support
[09:14] <visik7> vila: 1.5
[09:14] <vila> visik7: os ?
[09:14] <visik7> ubuntu 8.04
[09:14] <visik7> yes paramiko is already installed
[09:14] <visik7> but
[09:15] <visik7> the odd thing is that it create a .bzr inside the remote path
[09:15] <visik7> but didn't upload files
[09:16] <vila> visik7: Oh ! Sorry I misread. Yes, bzr can't upload working trees, you need to ssh connect there and issue bzr update
[09:16] <visik7> vila: O_o
[09:16] <vila> generally bzr checkout is used in the other direction to create a local working tree from a remote branch, what are you trying to achieve here ?
[09:17] <visik7> vila: I've my branch on my laptop and I want to deploy the working tree remotly
[09:17] <vila> visik7: what is in your working tree ? A web site ?
[09:18] <visik7> yes python code
[09:18] <vila> visik7: and you really want your branch to be available as part of your web site ?
[09:18] <visik7> vila: no I just want to upload the code remotly make it synced with my local branch
[09:18] <visik7> in a smooth way
[09:19] <visik7> without sshfs remotely and cp  the code
[09:19] <vila> have a look at lp:bzr-upload then, it's targeted to *you* personally :)
[09:20] <visik7> it's your
[09:24] <lifeless> Kinnison: http://www.squid-cache.org/Versions/v2/2.6/changesets/11996.patch
[09:24] <lifeless> Kinnison: you need http://www.squid-cache.org/Versions/v2/2.6/changesets/SQUID_2_6_STABLE19.html
[09:26] <lifeless> visik7: I wonder if detecting squid versions with the bug would be useful, give a warning
[09:26] <lifeless> meh, sorry visik7
[09:26] <visik7> Mu ?
[09:26] <lifeless> vila: ^
[09:26] <visik7> :)
[09:27] <Kinnison> lifeless: I don't think warning will help
[09:27] <Kinnison> lifeless: A lot of people don't have control of their cache versions, or are in companies or places where they are forced to go via the cache
[09:27] <Kinnison> lifeless: unless you can make it a one-shot warning the first time it is encountered
[09:28] <visik7> vila: I dunno how to install it  copy the dir inside .bazaar/plugins maybe ?
[09:28] <lifeless> Kinnison anyhow, upgrade your squid; it will be better
[09:28] <Kinnison> lifeless: heron has 2.6.18-1ubuntu3
[09:28] <Kinnison> lifeless: I take it that's no good, so I'd have to go unpackaged... grr
[09:29] <vila> visik7: cd ~/.bazaar/plugins ; bzr branch lp:bzr-upload upload
[09:29] <visik7> cool
[09:30] <lifeless> Kinnison: NMU FTW, backports etc
[09:30]  * Kinnison is such a pansy-user these days
[09:31]  * igc dinner
[09:33] <visik7> upload
[09:33] <visik7> ops
[09:33] <vila> lifeless: by parsing the header: 'Via: 1.0 ennui.i.flarn.net:3128 (squid/2.6.STABLE14)' ? Ghaaaaa
[09:34] <vila> lifeless: I updated the bug report though.
[09:34] <lifeless> the format is specified in rfc2616
[09:45] <vila> visik7: don't forget to remove your *remote* .bzr directory if you don't intent to publish it
[09:49] <visik7> vila: indeed it's a django app so it's impossible to access it even if exists :)
[09:50] <visik7> visik7: does it upload only changes right ?
[09:50] <vila> visik7: ok. Any feedback about the plugin greatly appreciated, it's still in beta
[09:51] <vila> visik7: yes, only changes
[09:51] <visik7> any changes done remotely are not tracked obviously
[09:51] <vila> indeed, that may even trigger bugs if you rename/move files around
[09:52] <visik7> would be usefull if the plugin notice that something is changed and stop with warning errors and such things
[09:52] <vila> the bug tracker is lp :)
[09:52] <visik7> ;)
[09:52] <vila> visik7: monitoring the remote tree will defeat the purpose of the plugin which is to upload incremental changes
[09:53] <visik7> vila: just some checks with ctime
[09:53] <visik7> just to not commit wrong things
[09:54] <vila> visik7: or said otherwise: it helps keeping a remote tree under version control when version control is not available remotely
[09:54] <vila> so doing changes on remote can't be tracked, trying to do so will involve huge bandwidth for bad results
[09:55] <visik7> for a ctime ?
[09:55] <vila> visik7: ctime is not enough :-)
[09:56] <visik7> first line of defense
[09:56] <vila> visik7: so it's part of 'bad results'
[09:56] <visik7> :(
[09:56] <vila> visik7: since I can't provide a robust solution to address remote changes, I prefer to provide no solution at all to avoid building false hopes or a false sense of security
[09:58] <vila> the plugin use a trick: the whole remote tree is known as a whole by a revid. If that relation is broken, there is no easy way to rebuilt it. You have to download the whole tree.
[09:59] <vila> But if you keep that relation, updating the remote tree is uploading only the modified files.
[10:00] <vila> All you have to do is work/test/commit locally, upload. Boom, the remote site is up to date
[10:02] <vila> visik7: does it make sense ?
[10:03] <visik7> yes it make sens
[10:08] <spiv> Argh, setting TCP_NODELAY doesn't seem to be enough to force multiple small send(2) calls to all transmit immediately.  I'm still seeing it wait for ACKs :(
[10:08]  * spiv reluctantly adds some buffering to _ProtocolThreeEncoder
[10:08] <fullermd> Isn't that what you expect from NODELAY?   :P
[10:08] <spiv> fullermd: Hmm?
[10:10] <fullermd> NODELAY means that it sends ACK's straight off, instead of holding them for a little while to see if there's more user data to ship back along with them.
[10:10] <fullermd> You'd have to increase the TCP window size to have more packets in flight.
[10:10] <spiv> I'm writing a total of 82 bytes in this instance.
[10:10] <spiv> I'm fairly sure that fits inside the TCP window size for a freshly created loopback socket...
[10:11] <spiv> I thought delayed ACKs were different to the Nagle algorithm, and "man 7 tcp" says Nagle is what NODELAY disables.
[10:14] <fullermd> Ah, right.  But disabling Nagle doesn't affect whether you're waiting for ACK's; just how quickly you send your bits at a level above that.
[10:15] <spiv> Right, but if Nagle is disabled, why would it wait for an ACK to send a second small packet?
[10:15] <fullermd> Because Nagle is sorta "higher level" than that.
[10:16] <fullermd> Nagle determines "how long do I wait to finalize this packet and pass it down to be sent".  Waiting for an ACK happens at a layer below that, where it figures out "how many packets/bits can I have inflight at once".
[10:16] <fullermd> It's odd that you'd have such low limits over loopback, though.  Slow-start?  That should be auto-disabled on loopback or local nets...
[10:17] <[CroX]> I'm trying to branch from a FTP, but my username has an at sign (@) in it, which causes Bazaar to fail. How can I make this work?
[10:17] <spiv> CroX: URL-escape the @
[10:17] <fullermd> [CroX]: URL-encode the @ (%40 I think?)
[10:19]  * spiv wishes he had a copy of TCP/IP Illustrated handy...
[10:19] <fullermd> Normally, mine would be about 2.5 feet from me.
[10:19] <[CroX]> fullermd: Great, that seems to have worked. :) Now, to figure out why it wont see the branch..
[10:19] <fullermd> Unfortunately, it's currently in storage as a side effect of my place being hit by a tornado   :|
[10:21] <spiv> fullermd: Hmm, I thought slow start wouldn't be relevant when talking about so few bytes.  The initial window size is 32k, according to wireshark.
[10:23] <fullermd> Yeah.  Shouldn't be relevant period over loopback; 32k sounds like a standard full window size.
[10:23] <[CroX]> Wow, bazaar just worked. That's awesome. And with bare FTP even. :)
[10:23] <spiv> fullermd: my naive understanding was that modulo Nagle, it was the number of unACKed payload bytes that mattered, rather than the number of individual tcp segments outstanding.
[10:23] <spiv> fullermd: I guess I'm wrong :)
[10:24] <fullermd> I have very vague memories that there is packet scaling hidden somewhere in there too.  But I could be dreaming.
[10:24] <fullermd> It could just be a weird artifact of something on your system or something in the kernel or yada yada.  Could be worth a try in a few different situations.
[10:26] <spiv> fullermd: yeah.  But if I have weird voodoo on my system, I'm probably not the only one.
[10:27] <spiv> fullermd: (it's just a laptop running Hardy, after all)
[10:27] <fullermd> Oh, well, a laptop.  1 packet inflight limit is a power-saving measure   8-}
[10:28] <spiv> fullermd: so fixing/changing my system doesn't really help deal with the problem, I need to fix it in the code one way or another.
[10:30] <fullermd> Yeah.
[10:30] <fullermd> Wish my copy of Stevens were handy   :(
[10:30] <spiv> Until today, I thought setting the NODELAY flag in the code was adequate, but it appears I actually have to avoid calling send repeatedly :(
[10:30] <spiv> Which at least has the advantage of being definitely portable ;)
[10:31] <fullermd> Yeah.  If you buffer it long enough, it's even DOS 2.1 compatible   ;)
[10:36] <visik7> can I rename a branch inside a repo without drawbaks ?
[10:37] <Odd_Bloke> visik7: Well, references to that branch won't be updated, but other than that it should be fine.
[10:37] <Odd_Bloke> Assuming by 'repo' you mean a shared repository.
[10:38] <visik7> yes
[10:38] <visik7> mm dunno
[10:38] <visik7> init-repo
[10:49] <Odd_Bloke> Yeah.
[11:04] <Peng> When using dumb http, is gzip compression enabled?
[11:07] <lifeless> our data files are already gzip compressed (except for the indices)
[11:07]  * Peng blinks.
[11:07] <Peng> Right.
[11:24] <fog> where does one find a list of allowed values in --log-format?
[11:24] <fullermd> It lists them in the 'log' help.
[11:25] <fog> no, it does not. there is a description and examples and that's all.
[11:26] <fullermd> Sure it does, right below it; line, long, and short
[11:26] <fog> it says:
[11:26] <fog> --log-format=ARG    Use specified log format.
[11:26] <fog> what can I put in ARG?
[11:26] <fullermd>     --line              Log format with one line per revision
[11:26] <fullermd>     --long              Detailed log format
[11:26] <fullermd>     --short             Moderately short log format
[11:27] <fog> you mean I can't create my own format? just line, long and short?
[11:27] <fullermd> You can via a plugin.
[11:28] <fullermd> AFAIK registering the log format will add it to the list in help.
[11:28] <fog> ok, lets say that having the --log-format option _and_ the formats as options is not very intuitive.
[11:29] <fog> --log-format=ARG makes you think about something like --log-format="%r %f ..."
[11:29] <fog> thank you for the clarification
[11:30] <fullermd> It could be a bit clearer in the help.  Seems to me we've gone aronud that a time or two in the last few years...
[11:36] <Jc2k> jelmer: i have #186876 (with http://svn.gnome.org/svn/eog/) on bzr-svn 0.4.10. launchpad says fix is released.. do you want a new bug opening?
[11:37] <Jc2k> jelmer: it also hits if i branch /tags/EOG_2_16_2/ rather than svn-import
[11:59] <antares> Hi!
[12:00] <antares> I have a question about bazaar, I'm using a central repository where I store web modules versioned with bazaar
[12:01] <antares> When I start a project, I want to get some of those apps, so I do a checkout of the applications I need into the project
[12:01] <antares> The project is versioned as well, but bazaar doesn't version the checkouts of the apps. Can I change this?
[12:02] <antares> What I need is to version a bunch of checkouts of other applications
[12:02] <fullermd>  There are 1.5 ways of doing the overall task.
[12:02] <fullermd> The .5 is versioning the checkouts, which is the NestedTree stuff.  It's only .5 because it doesn't usably exist.
[12:03] <fullermd> The other one is not checking them out, but merging them in, which has a different set of tradeoffs.  But you can do it.
[12:04] <antares> merging? are there any docs about that?
[12:04] <fullermd> (not, perhaps, as smoothly as you can when NestedTree's come in, since they also address a variant of that case)
[12:04] <fullermd> Well, it's just like any other merging, except you're merging branches with no common ancestor [the first time you merge them in], so you have to explicitly give the revision range.
[12:04] <fullermd> You end up with a branch with multiple initial revisions, but that's no problem.  I do it all the time.
[12:06] <antares> ok, but I don't really understand what you are saying, I'm a kind of newbie in bazaar :-)
[12:06] <antares> you mean using bzr pull?
[12:06] <fullermd> No, using `bzr merge`.
[12:07] <antares> ok, I have to read about this
[12:07] <antares> So nested trees are still in development?
[12:07] <fullermd> In "normal" merging, the branch you're merging is based on [an older version of] your current branch.
[12:07] <fullermd> In this particular case, it's not.  So it's a kinda special case, but it all Just Works(tm) about the same.
[12:08] <antares> ok
[12:08] <fullermd> Yeah.  The general impression I have is that much/most of the backend support exists, but there's no frontend to work with it (which also means the backend is probably full of sharp corners)
[12:09] <fullermd> It's fairly back-burnered behind other priorities.
[12:09] <antares> ok
[12:11] <antares> Thank you for your help, I'm gonna try
[12:13] <antares> 1 more question, if I make changes to this merge directory, and then I want to commit them to the application, can I do it?
[12:16] <fullermd> Yes, that's one of the tradeoffs of merging the modules in rather than having them checked out.
[12:16] <fullermd> Since they're merged in, you can make and maintain local changes from the 'upstream'.
[12:16] <antares> that's cool,I'm gonna try it
[12:26] <gour> igc: i'm not coming anywhere with darcs2-git...i installed latest tailor and now building latest darcs with some new patches which should improve migration of larger repos...in any case, i'd say that, atm, tailor is the best 'front-end' for migrating from darcs
[12:32] <igc> gour: interesting. thanks for the update
[12:40] <gour> igc: darc2git produces something like http://rafb.net/p/xClKaI75.html for looong time and not coming anywhere
[12:45] <igc> gour: so the beauty of the fast-import architecture is that front-ends can be written using what language makes the most sense ...
[12:46] <igc> gour: I would expect that the one for darcs would be best to be written in haskell
[12:46] <gour> igc: right...now i'll test tailor by converting darcs' repo into bzr
[12:47] <igc> gour: hope it goes well
[12:47] <igc> I'm heading off now
[12:47] <gour> igc: the tailor's dev wrote me: "AFAIK it's the only tool able to translate a repo like darcs2
[12:47] <igc> night all
[12:47] <gour>         into something else, to date"
[12:47] <gour> night
[12:47] <gour> (tailor)
[12:47] <gour> let's see
[13:28] <TheSheep> how would I go about starting a new repository from python code? bzrlib.repository.Repository(...)?
[13:30] <lifeless> jelmer: ping
[13:30] <jelmer> lifeless, hi
[13:31] <lifeless> TheSheep: look at bzrlib.builtins.cmd_init and cmd_init_repo
[13:31] <lifeless> jelmer: in bzr-gtk, if you go to global preferences, plugins tab, the text down the bottom appears wrong
[13:31] <TheSheep> lifeless: thanks!
[13:32] <jelmer> lifeless, please file a bug
[13:32] <jelmer> :-)
[13:35] <Jc2k> jelmer: ping
[13:36] <jelmer> j2ck: hi
[13:36] <Jc2k> hi
[13:37] <Jc2k> i have a bzr-svn bug that is already reported against 0.4.8 with "Fix Released" - i'm getting it in 0.4.10. shall i raise another bug?
[13:37] <Jc2k> (https://bugs.edge.launchpad.net/bzr-svn/+bug/186876)
[13:37] <jelmer> yes, please file a new one since launchpad can't split bugs
[13:37] <Jc2k> okie dokie
[13:50] <lifeless> jelmer: https://code.edge.launchpad.net/~lifeless/bzr-svn/help/+merge/277
[13:51] <lifeless> jam: ping
[13:51] <jelmer> lifeless, thanks
[13:57] <lifeless> jelmer: you will probably want to do it differently, but the concept should be clear
[14:00] <jelmer> lifeless: That pretty much duplicates what's already in README
[14:01] <jelmer> and adds yet another place to update the feature list, etc
[14:01] <lifeless> jelmer: right; in my plugins I put less in README
[14:02] <lifeless> jelmer: to put it differently, online help FTW
[14:04] <jelmer> lifeless: I don't like the online help system
[14:04] <jelmer> It's ok for dynamic things (commands list, formats list) since there's no real alternative there
[14:05] <jelmer> for everything else I prefer just files I can browse however I like
[14:07] <lifeless> jelmer: most users won't know where to find README in a installed bzr-svn package
[14:07] <lifeless> jelmer: I don't want you use any system other than what you find best;
[14:07] <lifeless> jelmer: but I love the online help system for making things discoverabble
[14:07] <jelmer> lifeless, I'm ok with providing help topics if that helps some people
[14:08] <jelmer> I'm just concerned about the maintainance overhead of having both (and the wiki)
[14:11] <lifeless> I would be inclined to write a script to:
[14:11] <lifeless> export the local help to the wiki
[14:11] <lifeless> create the local README from a template which you fill out from the module docstring
[14:14] <jelmer> yeah, that would work
[14:22] <visik7> anyone know how to get commit-notify working ?
[14:22] <visik7> I got it in the help
[14:22] <visik7> but when I run bzr commit-notify I got this:
[14:23] <siretart> jelmer: would you please commit your last bzr upload to unstable to the packaging branch?
[14:23] <visik7> bzr: ERROR: unknown command "commit-notify"
[14:27] <visik7> maybe becouse the registration of the command is commented
[14:28] <lifeless> its not commented in my copy of gtk trunk
[14:28] <visik7> in hardy is commented
[14:28] <visik7> uncommenting it cause a crash
[14:28] <visik7> saing:
[14:28] <visik7>     from bzrlib.plugins.dbus import activity
[14:28] <visik7> ImportError: No module named dbus
[14:29] <lifeless> yes, it needs bzr-dbus
[14:29] <visik7> oh
[14:29] <visik7> stange package choices
[14:30] <jelmer> siretart: done, sorry
[14:31] <jelmer> lifeless: it used to be disabled because bzr-dbus wasn't packaged I think
[14:32] <jelmer> lifeless: sid already has a fixed version (now that bzr-dbus is also packaged)
[14:33] <visik7> jelmer: it's all packaged
[14:33] <visik7> on hardy
[14:35] <jelmer> visik7: that's the original reason it was disabled
[14:35] <jelmer> bzr-dbus doesn't appear to be in ubuntu yet
[14:35] <jelmer> actually
[14:36] <visik7> jelmer: you are right
[14:36] <visik7> I've the ppa repository of bzr
[14:36] <visik7> :)
[14:47] <siretart> jelmer: no problem, thanks!
[14:54] <visik7> what commit-notify is supposed to do ?
[14:54] <visik7> I change my files on a branch but doesn't popup anything
[14:55] <jelmer> it should notify you of commits from the notification area
[14:56] <jelmer> if you changed + committed it should show up
[14:57] <visik7> mmm
[14:57] <visik7> no
[14:57] <visik7> :(
[14:58] <jelmer> visik7: did you follow the instructions for setting up the dbus plugin?
[14:58] <jelmer> visik7: ppa contains an old version of that plugin so I'm not sure if it does all the necessary setup
[14:59] <visik7> jelmer: was there instructions ?
[14:59] <jelmer> visik7, I don't recall, sorry
[14:59] <jelmer> visik7: hmm, looks like it does the required setup already actually
[15:00] <jelmer> visik7: and you've got "bzr commit-notify" running?
[15:00] <visik7> yes
[15:00] <jelmer> you may also have to restart dbus
[15:01] <visik7> mmm
[15:01] <visik7> restarting dbus was not a good choice
[15:02] <visik7> but does it need to be executed inside the branch ?
[15:02] <visik7> or it monitoring the bzr commit command ?
[15:05] <jelmer> visik7, "bzr commit" sends a message to dbus which then propagates it on to "bzr commit-notify"
[15:05] <visik7> it doesn't do anything uff
[15:05] <jelmer> so no need to run it in the same branch
[15:05] <visik7> anyway it doesn't popup
[15:06] <yacc> If I understood that correctly, bzr is capable of pushing/pulling via ssh. And most importantly, I can use pull from the other direction instead of push?
[15:06] <visik7> jelmer: dbus-monitor doesn't show any message from bzr
[15:06] <jelmer> yacc, yes
[15:06] <bob2> yacc: yes
[15:07] <jelmer> visik7, looks like bzr-dbus isn't loaded correctly in your local bzr then
[15:07] <jelmer> visik7, I'd recommend trying newer versions of bzr-dbus and bzr-gtk
[15:07] <visik7> :(
[15:07] <visik7> I'll wait until some newer version on ppa
[15:07] <visik7> of both
[15:08] <visik7> if sometimes in the feature it will happen
[15:08] <jelmer> I don't update ppa anymore
[15:08] <visik7> Nooooo
[15:08] <visik7> :(
[15:08] <jelmer> you may be able to use the package in sid though
[15:08] <visik7> backporting from ibex ?
[15:09] <jelmer> or request a sid->intreprid import
[15:17] <nslater> how do i check the head revision of a remote bzr repos?
[15:21] <visik7> jelmer: I've 0.1~bzr34-1~bazaar1~hardy1
[15:21] <visik7> jelmer: on sid/ibex there is bzr35
[15:22] <yacc> Ok, is it a good idea to mix bzr 1.3.1 with bzr 1.5 when interoperating?
[15:22] <emgent> hello
[15:23] <emgent> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eemgent/ubuntu-cve-tracker/universe-security-updates/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
[15:23] <emgent> some idea?
[15:23] <visik7> emgent: http is readonly afaik
[15:24] <james_w> emgent: did you run "bzr checkout http://bazaar.launchpad.net/%7Eemgent/ubuntu-cve-tracker/universe-security-updates/" ?
[15:24] <emgent> james_w: mmh, no just a moment :)
[15:25] <jelmer> yacc, yes, shouldn't be a problem
[15:25] <james_w> emgent: don't, you're not supposed to :-)
[15:25] <james_w> emgent: that's just the usual cause, but not the usual one.
[15:25] <jelmer> visik7, yes - what about it?
[15:25] <lifeless> emgent: try 'bzr update' :P
[15:25] <james_w> emgent: what operation are you doing? How did you get the branch that you are working on?
[15:26] <emgent> simple push
[15:27] <james_w> emgent: try "bzr push --remember bzr+ssh://emgent@http://bazaar.launchpad.net/~emgent/ubuntu-cve-tracker/universe-security-updates/.bzr/repository/lock"
[15:27] <emgent> now, checkout in progress
[15:27] <emgent> i will try, thanks :)
[15:27] <yacc> Hmmm.
[15:27] <yacc> No revision control details recorded for Bazaar Bookmarks Plugin Series: trunk.
[15:27] <yacc> <= where do I get then the bookmarks plugin?
[15:28] <james_w> emgent: if you run "bzr lp-login emgent" then the above becomes "bzr push lp:~emgent/ubuntu-cve-tracker/universe-security-updates"
[15:28] <james_w> yacc: https://code.edge.launchpad.net/bzr-bookmarks/
[15:29] <yacc> ndreas@andi-lap:~/.bazaar/plugins$ bzr branch https://code.edge.launchpad.net/bzr-bookmarks/
[15:29] <yacc> bzr: ERROR: Not a branch: "https://code.edge.launchpad.net/bzr-bookmarks/".
[15:30] <james_w> yacc: it's not a branch, it's a webpage that lists the branches of the project
[15:30] <yacc> thx.
[15:30] <james_w> bzr branch lp:~luks/bzr-bookmarks/trunk
[15:35] <emgent> james_w: ok solved
[15:35] <visik7> is there something like a bzrweb ?
[15:35] <emgent> thanks.
[15:35] <james_w> emgent: no problem
[15:35] <james_w> visik7: look in to loggerhead, and bzr-webserve
[15:35] <lifeless> visik7: yes, loggerhead, bzr webserve  etc
[15:36] <lifeless> loggerhead is probably a better bet long term (as launchpad uses it so its getting lots of care)
[15:44] <yacc> What protocol does bzr assume when it gets something like user@hostname:dir ?
[15:44] <yacc> I'd expect it to create /home/user/dir on hostname, but I'm somehow a directory short.
[15:45] <yacc> Ok, that's a local directory ;)
[15:46] <fullermd> I think it assumes you're giving it bad input   :)
[15:47] <visik7> jamesh: push and pull are notified
[15:47] <visik7> james_w: but local commit aren't
[15:47] <visik7> ops
[15:49] <radix> yacc: right, anything that doesn't have a scheme is assumed to be local, AIUI
[15:50] <pickscrape> Are there decent bzr gui tools available for the Mac?
[16:09] <lifeless> yacc: without a protocol it will assume local disk
[16:09] <mneptok> ladies and gentlemen, #bzr has arrived. we now have an insane Finn on-channel. a prerequisite to a "real" IRC experience.
[16:10] <radix> mneptok: Man, I miss the days when every IRC channel had a good, crazy Finn or two
[16:10] <lifeless> liw: has import performance notiable degraded as that repository grew ?
[16:10] <liw> mneptok, I don't see why it's insane to keep disk images in bzr
[16:10] <lifeless> radix: watch out for the mickey's
[16:10] <liw> lifeless, not that I noticed, I can instrument when I import universe
[16:11] <lifeless> (My first IRC experience was in a channel called callahans)
[16:11] <mneptok> liw: as long as they are encrypted, multi-petabyte images, you should be OK
[16:11] <james_w> liw: it worked?
[16:11] <lifeless> james_w: main did
[16:11] <lifeless> james_w: 5.6Gb repository/packs dir
[16:12] <liw> james_w, one repo for all source package, one branch per source package, ubuntu main: worked
[16:12] <james_w> ooohhh!
[16:12] <bob2> a single pack?
[16:12] <lifeless> bob2: single pack repo
[16:14] <lifeless> liw: how long does it take to 'bzr branch' one of the main packages?
[16:16] <liw> lifeless, with the script to unpack universe sources also running, 46 seconds real time, of which 12 seconds user, 2 seconds system
[16:16] <liw> lifeless, for abiword
[16:17] <lifeless> not bad
[16:18] <CardinalFang> Hi all.
[16:19] <CardinalFang> I have two trees I want to apply a change to.  One is a superset of the other.
[16:20] <CardinalFang> So, I branch from the smaller one, apply the patch, commit.  Then I branch from the other, "merge ../subset", "commit".
[16:20] <CardinalFang> All that makes sense and I'm happy with it.
[16:21] <CardinalFang> But, "bzr missing" only shows that merge commit message, which I didn't add a lot of description to, as there was nothing to say that wasn't in the first change message.
[16:23] <CardinalFang> I /guess/ that "missing" only shows the left edge of the graph, when all my useful information is in the right edge.
[16:23] <lifeless> uhm
[16:23] <CardinalFang> In any case, is there a way to show what my branch has outstanding beneath that "merge" change?
[16:23] <lifeless> missing shows left hand only yes
[16:24] <lifeless> bzr log REMOTE -r -1
[16:25] <awilkins> Missing shows both sides unless  you instruct it not to, no?
[16:30] <lifeless> yes
[16:30] <CardinalFang> lifeless, ah, perhaps   "bzr log -r ancestor:REMOTE.."
[16:30] <lifeless> but only the left-hand edge within each side
[16:31] <CardinalFang> ...but that's making some assumptions about order.
[16:32] <yacc> How does one rebuild the checkout tree from .bzr?
[16:32] <CardinalFang> lifeless, The use of left edge for revno ordering makes sense, but I don't see any reason to prefer it for any other operation.
[16:32] <CardinalFang> It's completely arbitrary.
[16:34] <lifeless> yacc: 'bzr checkout .' or you can use some 'bzr reconfigure' option, but I don't know what the option is offhand
[16:34] <yacc> lessless bzr checkout . is ok.
[16:34] <lifeless> CardinalFang: its sufficient yo describe what you need to pass to merge or pull to obtain the detail, and it describes the merges done so is sufficient
[16:47] <gour> one can register project under lp and then have several 'products' under it?
[16:47] <gour> like different components of the project
[16:48] <luks> gour: yes
[16:48] <gour> luks: ta
[16:51] <visik7> where are the terms and conditions of launchpad usage ?
[16:52] <CardinalFang> lifeless, maybe if the output of "missing" we such that I could put it in backticks and for parameters to something else, I would agree with you.
[16:52] <TheSheep> sorry for all those questions, but I'm stuck again: how would I add a file to a memorytree, without actually writing that file to disk?
[16:53] <CardinalFang> lifeless, Which would you like, a patch to fix the wording of "Purpose: Show unmerged/unpulled revisions between two branches.", or a patch that shows the unmerged revisions between two branches?
[16:54] <gour> visik7: https://help.launchpad.net/Legal
[16:54] <luks> gour: hm, looks like I was wrong. I know I created one such 'project group' myself some time ago, but I can't find a way to do it now
[16:56] <abentley> lifeless: That push I was complaining about ultimately took 2394 seconds.
[16:57] <abentley> That's without copying any revisions, because they were already present.
[16:57] <visik7> so only opensource projects hosted on launchpad
[16:57] <visik7> right ?
[16:57] <visik7> just to be sure
[17:12] <jam> abentley: I *think* it might be because the LP tree has a lot of ghosts, which confuse the RemoteRepository.get_parent_map() code
[17:12] <jam> I'm guessing, though
[17:13] <jam> abentley, lifeless: Certainly I remember looking at the debug log and seeing that it was transmitting several queries of the same length
[17:13] <jam> all of them something ilke 177kB long
[17:13] <jam> and that is generally upload bandwidth bottlenecked
[17:14] <jam> The good was that it seemed to actually change the revision ids
[17:14] <jam> the weird was that the queries were *exactly* the same length each time
[17:40] <pickscrape> Is there anywhere I can go to have a look at what's 'landed' for 1.6 so far? I like to keep up with such things. I'm sad, I know...
[17:40] <pickscrape> BTW my presentation went well. Unless something unforeseen happens we're going to be switching to bzr (from svk) soon.
[17:57] <Odd_Bloke> pickscrape: NEWS in bzr.dev.
[18:07] <abentley> pickscrape: or  "bzr log http://bazaar-vcs.org/bzr/bzr.dev --short --limit 100" to see the last 100 merges.
[18:07] <pickscrape> kewl...
[18:11] <abentley> jam: casual inspection suggests that latency dominates when doing those get_parent_map queries.
[18:13] <pickscrape> Is there some equivalent of git's 'show' command? i.e. I want to see one revision, including log and full patch.
[18:14] <LeoNerd> bzr log -r 123 ;  bzr di -c 123
[18:14] <LeoNerd> The -c meaning --change.. i.e. the change introduced at 123
[18:14] <pickscrape> Would anyone be opposed to a show command that does that for you more simply?
[18:15] <pickscrape> (Just thinking of something fairly simple I could do mysqlf)
[18:15] <pickscrape> myself. Bah, I can't type myself without typing mysqlf
[18:17] <pickscrape> I suppose 'show' would be a prime candidate for a plugin...
[18:26] <abentley> pickscrape: considering that there have been multiple requests to add diff display to log, "log -p -r 123" will probably do that in the future.
[18:27] <yacc> Can it be that bookmarks are not support for bzr pull ?
[18:28] <yacc> (lookery)andreas@andi-lap:~/customers/lookery/trunk$ bzr pull bookmark:lookery-cluster
[18:28] <yacc> bzr: ERROR: Not a branch: "/home/andreas/customers/lookery/trunk/bookmark:lookery-cluster/".
[18:30] <pickscrape> abentley: yes, that would do it too
[18:32] <yacc> Any one here using the bookmarks plugin?
[19:13] <luks> yacc_: 'bzr pull' doesn't work with custom handlers like bookmark: or lp:
[19:13] <luks> it's a bug in bzr, not the plugin
[19:39] <lifeless> abentley: wheeeee
[19:52] <Pilky> is there meant any sort of consistent use of error codes in bzr? and if so is there somewhere where they are all listed?
[19:53] <Pilky> oh wait... I see what's happened, ignore me
[19:53]  * TheSheep obediently ignores Pilky 
[19:54] <Pilky> heh
[20:50] <visik7> is there a way to setup a working tree on a shared repository ?
[20:50] <visik7> I can't figure out how
[20:54] <fullermd> No, the concept is nonsensical in bzr.  Working trees only have meaning on branches.
[20:55] <fullermd> (now, you could make the working tree of a branch in the root of a shared repo.  Whether that's sensible is another question...)
[21:07] <lifeless> night all
[21:10] <abentley> lifeless: night.
[21:15] <visik7> fullermd: so a branch has a working tree right ?
[21:17] <visik7> if I branch into a remote server do I need to commit every push there ?
[21:17] <visik7> or there is some autocommit on push ?
[21:17] <fullermd> Well, a working tree always has a branch.  A branch doesn't need to have a working tree (or it may have several)
[21:18] <fullermd> Push pushes commits; you don't commit pushes.
[21:18]  * fullermd crafts sentences out of as few words as possible   :)
[21:18] <visik7> how can I have 2 working tree of a branch onto 2 machines ?
[21:23] <fullermd> Using 'bzr checkout'.
[21:24] <visik7> and then I can commit from a machine to another ?
[21:24] <visik7> I mean
[21:24] <visik7> push
[21:36] <visik7> no ?
[21:36] <LeoNerd> Anyone here on debian/unstable..? I've noticed sftp:// no longer works...
[21:36] <LeoNerd> Though, bzr+ssh does
[21:37] <beuno> LeoNerd, do you have python-paramiko installed?
[21:37] <LeoNerd> Yes.. It always used to work... this is a recent breakage (last week or so)
[21:37] <LeoNerd> bzr: ERROR: exceptions.AttributeError: 'SSHSubprocess' object has no attribute 'get_name'
[21:37] <beuno> hrm, that's very odd...
[21:37] <dato> LeoNerd: are you using 1.5?
[21:38] <dato> I meant to ask here what was up with that, but my problem went away when I switched to 1.5
[21:38] <LeoNerd> ii  bzr                  1.3.1-1              easy to use distributed version control system
[21:38] <LeoNerd> ii  python-paramiko      1.7.3-1              Make ssh v2 connections with python
[21:38] <dato> LeoNerd: so, upgrade bzr...
[21:38] <LeoNerd> OK
[21:38] <dato>     * Incompatibility with Paramiko versions newer than 1.7.2 was fixed.
[21:38] <dato>       (Andrew Bennetts, #213425)
[21:38] <vila> wasn't there a bug introduced in paramiko 1.7.3 but worked around in 1.4 or 1.5 ?
[21:39] <vila> dato: too fast :)
[21:39] <dato> that's from 1.4
[21:39] <LeoNerd> Aaah yes.. that's got it, thanks.
[23:01] <ollman> bzr
[23:02] <weigon_> hmm, is there a nice tool to cherry pick and merge patches with a nice UI ?
[23:02] <ollman> bzr
[23:03] <weigon_> I can do it by hand with bzr merge -c ... yeah
[23:03] <ollman> bzr
[23:03] <beuno> ollman, ?
[23:03] <ollman> beuno, what do you want to know?
[23:04] <pickscrape> He's not a bot is he?
[23:05] <ollman> what is a bot?
[23:05] <beuno> if he is, he should be kicked
[23:06] <ollman> he is not a bot, what ever that is
[23:06] <pickscrape> Just thought it was weird that you kept saying "bzr" and nothing else.
[23:06] <pickscrape> Weird.
[23:06] <beuno> very
[23:07] <pickscrape> Maybe it was a bot, designed to act like it wasn't. Some sort of AI experiment.
[23:08] <ollman> bzr
[23:08] <Pilky> .
[23:08] <ollman> yes
[23:09] <vila> ollman: reboot
[23:09] <vila> ollman: --help
[23:09] <ollman> you want help?
[23:10] <Pilky> ollman: When Littlefoot's mother died in the original 'land before time', did you feel sad?
[23:10] <beuno> lol
[23:10] <ollman> never heard of it
[23:11] <Pilky> hmm, inconclusive... we could try the tortoise problem?
[23:11] <pickscrape> ollman: which is better: old ﻿Star Wars or new Star Wars?
[23:11] <ollman> the revenge of the sith is the best part
[23:12] <beuno> damn, he's good
[23:13] <Pilky> beuno: actually no, he's crap
[23:13] <Pilky> return of the jedi is the best ;)
[23:13] <beuno> hehe
[23:13] <pickscrape> :)
[23:13] <pickscrape> Might betray age.
[23:14] <ollman> empire strikes back is the second best part
[23:16] <vila> you mean the best in the second part (or is that the previous revision (trying to get back on topic...))
[23:16] <Pilky> pickscrape: Age is no excuse, I wasn't even born when return of the jedi was out ;)
[23:17] <pickscrape> hehe
[23:17] <ollman> why do you want to talk about starwars?
[23:18] <Pilky> ollman: where did you hear about bazaar?
[23:18] <ollman> what the hell is that?
[23:19] <Pilky> a type of fruit
[23:19] <ollman> cunting hun
[23:20] <beuno> ollman, ñ
[23:20] <ollman> what?
[23:20] <beuno> (let's see if he's UTF-8 safe)  :p
[23:20] <beuno> right, you win this round
[23:20] <Pilky> ollman: where are you based?
[23:21] <ollman> in Switzerland
[23:21] <Pilky> what time is it there?
[23:21] <ollman> 00:21
[23:22] <Pilky> and why are you in this channel if you don't know what bazaar is?
[23:22] <ollman> because it's interesting
[23:22] <Pilky> why did you choose to come in in the first place though?
[23:23] <ollman> out of curiosity
[23:23] <Pilky> odd
[23:23] <ollman> why is that odd
[23:24] <Pilky> just find it a bit odd that someone would come in here just out of curiosity
[23:24] <ollman> ok
[23:24] <ollman> if you say so
[23:25] <beuno> and repeating bzr randomly helped the oddness too  :)
[23:25] <ollman> alright
[23:25] <ollman> I like being odd
[23:52] <beuno> ah, k-lined isn't normally good