[00:35] <spiv> igc: ping
[00:36] <igc> hi spiv
[00:36] <spiv> igc: I've just made a tarball for 0.92rc1
[00:36] <igc> hooray
[00:37] <spiv> igc: I don't have write access to escudero though... do you?  I know you've been RM in the past.
[00:37] <spiv> igc: I've put it at http://people.ubuntu.com/~andrew/bzr-0.92rc1.tar.gz for now
[00:37] <igc> yes
[00:37] <spiv> (and there's a .sig as well)
[00:37] <igc> I'll move it across
[00:37] <spiv> igc: thanks!
[00:37] <igc> np
[00:38] <igc> few minutes ...
[01:06] <igc> spiv: I have the files on esceduro now but not in the right directory :-( Permissions issue ...
[01:06] <igc> Let me ping a few people
[01:07] <spiv> igc: Ok.
[01:09] <spiv> igc: if necessary I can just have the annoucement and download page point at people.ubuntu.com/~andrew/.  That's not great, but at least the tarball is GPG-signed so people will know that I'm definitely the guy to blame ;)
[02:52]  * spiv -> lunch
[03:22] <poolie> hello
[03:22] <poolie> igc, spiv, thanks for making the release
[03:22] <poolie> have a good trip when you leave
[03:22] <igc> hey poolie
[03:22] <poolie> things are going spiffingly here
[03:22] <igc> how was your trip?
[03:22] <igc> excelent
[03:24] <poolie> pretty good
[03:24] <poolie> i'm about to fall asleey
[03:24] <poolie> asleep
[03:26] <igc> sleep well
[03:26] <poolie> thanks; and say thanks/well done to spiv too
[03:53]  * igc food
[05:19] <Peng> I know I should just RTF mailing list, but what was the most recent pack format change? Just the name?
[05:42] <frogduster> The packages for bazaar are listed in ubuntu's repositories with the following warning:
[05:43] <frogduster>  Unless you have a pressing reason to use bazaar you should use some other revision control system as upstream development has ceased.
[05:43] <frogduster> ..this is incorrect, right?
[05:43] <spiv> frogduster: the "bazaar" packages are for the old TLA-derived revision control system.  The current tool called "Bazaar" is packaged as "bzr".
[05:45] <spiv> It sounds like the package description for the "bazaar" package should probably say something about the "bzr" package, which is what people are probably looking for when they find the "bazaar" package.
[05:46] <frogduster> Ah.  Thank you.  :-)  If the old 'bazaar' is rarely used, it might be wise to put a disclaimer in the description for the package "bazaar" that states that it is not to be confused with the currently-developed package manager packaged as "bzr".
[05:46] <frogduster> *nod*
[05:46] <frogduster> Hehe.
[05:46] <frogduster> Thanks for the info.
[05:47] <frogduster> Should I file a bug report / wishlist item on launchpad?
[05:48] <spiv> frogduster: I think so.
[05:48] <spiv> frogduster: assuming it hasn't already been filed :)
[05:48] <frogduster> *nod* will do.
[05:48] <frogduster> :-)  natch.
[05:48] <spiv> frogduster: https://bugs.edge.launchpad.net/ubuntu/+source/bazaar/+bug/143998 looks to be related
[05:48] <ubotu> Launchpad bug 143998 in bazaar "rename 'bazaar' package to 'baz'" [Low,New]
[05:49] <frogduster> ah.
[05:49] <frogduster> You beat me to the search.. :-)  But, that's not too bad, as my system is bogged down right now, and firefox is a bit much on top of what it's already doing..
[06:01] <frogduster> Nudged the existing bugreport.  :-)
[06:01] <frogduster> Thanks, spiv.  :-)
[07:11] <dewd__> let it be known that I just tested the new pack support of 0.92rc1 and at least for me it didn't work as well as the old one in my working environment. I hit one "lock" error during a bzr+ssh push (which can be part of multiple simultaneous requests)
[07:11] <dewd__> anyway, I'e decided for now to continue to use the old format as it seems to be a little more fool proof with regards to locking in my environment.
[07:18] <AfC> dewd__: if you've got time, you should send that as an email to the bazaar mailing list
[07:21] <dewd__> it would be more helpful i know. but I have just reverted it back because i was testing it in "production" with a bunch of repos, not one or two.
[07:21] <dewd__> so i can't even test/debug it
[07:43] <AfC> Sure
[07:59] <igc> night all
[09:56] <mathrick> hiya
[09:56] <mathrick> why does bzr.dev identify as 0.90.0?
[09:57] <mathrick> it breaks my newest and greatest bzr-svn
[09:57] <mathrick> ooh
[09:57] <mathrick> bzrlib: /usr/lib/python2.5/site-packages/bzrlib
[09:57] <mathrick> I guess that's why
[09:58] <mathrick> how do I make it not use the systemwide bzrlib without uninstalling bzr?
[09:58] <mathrick> (the packaged one I mean)
[10:01] <Kinnison> futzing with python's module path is about all I can suggest
[10:02] <fullermd> I've never had that confusion happen, and I use bzr.dev all the time on my workstation...
[10:02] <mathrick> I tweaked PYTHONPATH and it appears to work
[10:05] <mathrick> hmm, now it doesn't
[10:30] <mathrick> bzr bzr-pokerolymp2:2101/> missing --other
[10:30] <mathrick> Using last location: svn+https://beta.aimido.de/svn/src2/trunk
[10:30] <mathrick> Unhandled error:
[10:30] <mathrick> character mapping must return integer, None or unicode
[10:30] <mathrick> humm
[10:31] <mathrick> I hacked PYTHONPATH into ~/bin/bzr.dev/:$DEFAULTPATH
[10:32] <mathrick> hmm, it seems it's bzr-svn that's dying
[10:32] <mathrick> jelmer: poke?
[10:34] <mathrick> or anyone else, any ideas what might be breaking it?
[10:46] <mathrick> argh, bummer
[10:46] <mathrick> I need bzr-svn working
[11:45] <jelmer> mathrick: pong
[11:45] <jelmer> mathrick: can you set BZR_PDB=1 and try again?
[11:45] <mathrick> yes
[11:46] <mathrick> I just need to switch to 0.92 again
[11:49] <mathrick> jelmer: hmm, I merged that branch with upstream using r716 in the meantime, and it doesn't seem to die anymore
[11:51] <mathrick> but I've got other fun
[11:53] <mathrick> jelmer: http://pastebin.org/6321
[11:55] <jelmer> can you print the contents of elements and existing_elements ?
[11:57] <mathrick> (Pdb) p elements
[11:57] <mathrick> ['mathrick', 'pokersource']
[11:57] <mathrick> (Pdb) p existing_elements
[11:57] <mathrick> []
[11:57] <mathrick> (Pdb)
[11:57] <mathrick> jelmer: there
[11:58] <jelmer> hmm, but that path (/mathrick/pokersouirce) exists in the repository ?
[11:58] <mathrick> jelmer: no, mathrick/ does
[11:58] <mathrick> I believe
[11:58] <mathrick> uh-huh
[11:58] <mathrick> nope
[11:58] <mathrick> I wonder why, I created it before
[11:59] <jelmer> at least /mathrick will have to exist
[11:59] <jelmer> the error should probably be a bit clearer...
[11:59] <mathrick> indeed
[12:01] <mathrick> jelmer: btw, with 716 it was uploading a lot, and then at the end died with "at least one property change failed, repository unchanged" from subversion
[12:01] <mathrick> r716 I mean
[12:01] <mathrick> now it did with r761 as well
[12:02] <mathrick> jelmer: http://pastebin.org/6322
[12:03] <jelmer> mathrick: can you run with -Dcommit and try again?
[12:03] <jelmer> that should print any revision properties set to ~/.bzr.log
[12:03] <mathrick> jelmer: that goes as a bzr argument?
[12:03] <jelmer> yes
[12:08] <mathrick> jelmer: http://pastebin.org/6323
[12:09] <jelmer> ahh
[12:11] <jelmer> in ~/.bazaar/subversion.conf, please look for list-QlpoOTFBWSZTWZkHsqUAAAhRgAAQABC6yR4AIAAxTAAAlRkDRtJDWcJGukaEIjw7FScqiDvxdyRThQkJkHsqUA== and change the two '=' at the end into '-'
[12:12] <mathrick> oookay
[12:13] <jelmer> if that doesn't help, can you please mail me the bit you just pastebinned ? pastebin seems to have a X-character limit
[12:14] <mathrick> jelmer: TypeError: Incorrect padding
[12:14] <mathrick> list-QlpoOTFBWSZTWZkHsqUAAAhRgAAQABC6yR4AIAAxTAAAlRkDRtJDWcJGukaEIjw7FScqiDvxdyRThQkJkHsqUA--
[12:14] <mathrick> that's what it should look like?
[12:14] <jelmer> whoops, that should be two dots at the end
[12:14] <jelmer> sorry
[12:15] <mathrick> jelmer: still the same with ..
[12:16] <jelmer> can you set BZR_PDB=1 again and see where it's breaking?
[12:17] <mathrick> **** entering debugger
[12:17] <mathrick> > /home/mathrick/Dev/rails/bzr-pokerolymp2/base64.py(76)b64decode()
[12:18] <jelmer> and "bt"?
[12:19] <mathrick> http://pastebin.org/6326
[12:20] <jelmer> are you sure you're running r761?
[12:20] <jelmer> the source for scheme.py:133 is different here
[12:22] <mathrick> lemme confirm
[12:23] <mathrick> jelmer: it seems that bzr revert on a lightweight checkout will confuse bzr
[12:24] <mathrick> gotta report that
[12:24] <mathrick> now I've got that mapping thing again
[12:24] <jelmer> mathrick: but you were actually running a different version?
[12:24] <jelmer> mathrick: which mapping thing?
[12:24] <mathrick> jelmer: http://pastebin.org/6329
[12:25] <mathrick> jelmer: yeah, it *said* 761, but was running 716 still I guess
[12:26] <jelmer> see /query
[12:33] <lifeless> moin
[12:34] <jelmer> hey lifeless
[12:34] <jelmer> how's the UDS?
[12:41] <ubotu> New bug: #158306 in bzr "Reverting a lightweight checkout confuses bzr about revision number" [Undecided,New] https://launchpad.net/bugs/158306
[12:41] <lifeless> good
[12:41] <lifeless> jerry is playing with packs
[12:45] <mathrick> ^-- lightweight checkouts have very unclear idea of their own status
[12:46] <lifeless> well, revert does not change revno
[12:47] <mathrick> but you can't change revno on a lightweight checkout otherwise
[12:47] <mathrick> since it doesn't have its own identity
[12:47] <fullermd> Well, that's what update -r is for.  Or would be, if it existed.
[12:48] <lifeless> mathrick: well, it does have it's own identity
[12:49] <mathrick> lifeless: but tries very hard to hide it :)
[12:49] <lifeless> revert does not change it, and is not intended to change it; as fullermd says update is the command that would be suitable for changing it
[12:49] <lifeless> mathrick: uhm, not really ;)
[12:49] <jelmer> lifeless: Nice :-)
[12:50] <fullermd> I wish heavyweight checkouts tried harder to hide it...
[12:50] <mathrick> lifeless: try rebinding a lightweight checkout for which the parent branch is inaccessible
[12:50] <mathrick> it's not possible
[12:50] <mathrick> it's not possible at all by default
[12:50] <mathrick> but the plugin to do that fails with inaccessible parents
[12:50] <lifeless> mathrick: 'bind' only applies to heavyweight checkouts; I think 'switch' is the right ui for it, but its not done yet
[12:51] <lifeless> mathrick: well you have found a bug then :)
[12:51] <mathrick> yeah, switch was what I was thinking about
[12:51] <mathrick> I know :)
[12:51] <mathrick> I thought it's been reported already
[12:51] <mathrick> *think
[12:51] <mathrick> jelmer: anyway, ping me when there's hot new svn love waiting for me to update :)
[12:52] <jelmer> mathrick: The unicode bug should be fixed already
[12:52] <jelmer> now looking into the missing prefix error
[12:56] <mathrick> jelmer: ah, fine, lemme try that
[12:58] <mathrick> jelmer: where do I change the branching scheme again?
[12:58] <mathrick> (it doesn't think that mathrick/pokersource/ is a valid branch path)
[13:00] <jelmer> mathrick: just remove ~/.bazaar/subversion.conf
[13:00] <mathrick> jelmer: oh, it doesn't need the branch specs anymore?
[13:01] <mathrick> crap
[13:01] <jelmer> it does, but will create it again
[13:01] <mathrick> I deleted bazaar.conf instead
[13:02] <fullermd> Just goes to show you why you should keep ~/.bazaar in bzr   ;)
[13:02] <mathrick> mathrick@hatsumi:~/Dev/rails/bzr-pokerolymp2$ BZR_PDB=1 bzr -Dcommit svn-push svn+https://beta.aimido.de/svn/src2/mathrick/pokersource/
[13:02] <mathrick> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[13:02] <mathrick> gah
[13:03] <mathrick> jelmer: is that related to me having just deleted bazaar.conf?
[13:03] <jelmer> mathrick, no, it's shouldn't be
[13:03] <jelmer> mathrick, You created just mathrick?
[13:03] <mathrick> yeah
[13:03] <mathrick> hmm
[13:04] <mathrick> but somehow pokersource/ popped up there
[13:12] <mathrick> jelmer: see priv
[13:23] <jelmer> mathrick: can you still reproduce bug 145171 or is that what we're looking at right now?
[13:23] <ubotu> Launchpad bug 145171 in bzr-svn "Invariant break on bzr missing in bzr-svn" [Medium,Incomplete] https://launchpad.net/bugs/145171
[13:24] <mathrick> jelmer: unsure, I looked at it earlier today, but I decided I can't determine if it still happens
[13:24] <mathrick> it doesn't look the same
[13:25] <jelmer> but you were trying to do the same thing there?
[13:27] <mathrick> jelmer: no, I was trying to push to a new branch
[13:27] <mathrick> jelmer: oh, you might want to know that I have a merged-into subtree in that repo
[13:29] <jelmer> in the bzr repo?
[13:29] <jelmer> that you're trying to push?
[13:34] <mathrick> jelmer: yes
[13:35] <jelmer> mathrick: also in the particular branch you're pushing?
[13:36] <mathrick> jelmer: umm, unsure what you mean now
[13:37] <jelmer> the pokersource branch you're trying to push, does that include a revision with subtrees?
[13:37] <mathrick> the repo is plain SVN, so it doesn't have merged subbranches of course. My branch is derived from that SVN repo trunk, AND merges-into a subbranch, now I want to push the whole thing under branches/mathrick/pokersource/
[13:38] <lifeless> jelmer: what will it take to get rid of bzr svn-push ?
[13:40] <jelmer> lifeless: bug 121875
[13:40] <ubotu> Launchpad bug 121875 in bzr "cmd_push() should abstract away transport.mkdir()" [Wishlist,New] https://launchpad.net/bugs/121875
[13:43] <jelmer> lifeless: svn-push is basically a wrapper around the BzrDir.import_branch(path, source_branch) function
[13:54] <lifeless> jelmer: so send a patch :)
[14:00] <jelmer> lifeless: lots of other things I have to do first, I'm afraid :-/
[14:06] <lifeless> jelmer: it does seem very likely to trip people up; and I don't understand why you don't just decoate the existing push command in bzr-svn as a firststep
[14:09] <jelmer> lifeless: I'm focussing on fixing some of the functionality bugs in push that have come up for now
[14:11] <mrevell> Hi - does anyone have a moment to answer a question about "bzr status"?
[14:12] <lifeless> jelmer: fair enough
[14:12] <LeoNerd> Just ask your question; don't ask to ask
[14:12] <lifeless> mrevell: don't ask to ask, just ask.
[14:13]  * lifeless high fives LeoNerd 
[14:13] <mrevell> fair enough :)
[14:13] <fullermd> Asking to ask asks for axeing.
[14:13] <mrevell> I want to know what the Subversion-style status flags are but can't find a definitive list for Bazaar
[14:14] <mrevell> can anyone point me in the direction of definitions?
[14:14] <lifeless> bzr help st
[14:14] <lifeless> ...
[14:14] <lifeless> See also: diff, revert, status-flags
[14:14] <mrevell> lifeless: Thanks, managed to miss that.
[14:19] <jelmer> lifeless: so send a patch :-P
[14:19] <lifeless> mrevell: suggestions on making it more clear solicited
[14:20] <lifeless> jelmer: fixing performance for e.g. samba first :)
[14:20] <mrevell> lifeless: Working on it right now.
[14:20] <jelmer> lifeless: ok, I can live with that :-)
[14:21] <jelmer> lifeless: Did you discuss the difference in workflow compared to git with Jerry?
[14:21] <lifeless> yes somewhat
[14:21] <jelmer> (one working tree per repository compared to one per branch)
[14:21] <lifeless> big thing appeasrs to be our lack of 'collectionof branches' facilities
[14:21] <jelmer> yeah, I blogged about that a while back
[14:21] <LeoNerd> Coming from CVS, I'd say that's true
[14:26] <fullermd> If only somebody could rant via email at length on that topic...
[14:27] <lifeless> jelmer: I don't see blogs that often; discussion about features is really best on the list IMNSHO :)
[14:28] <jelmer> Well, the problem I guess is that it's not a concrete feature request
[14:28] <jelmer> more like: these things bother me about bzr at the moment and they all seem to be related to management of branches
[14:28] <jelmer> *related branches
[14:28] <jelmer> I can forward the blog post to the list, would htat be useful?
[14:29] <jelmer> here's a link: http://jelmer.vernstok.nl/blog/archives/192-Bazaar-Need-for-a-Product-object.html
[14:30] <fullermd> It was ref'd by igc in the recent thread on the topic.
[14:31] <lifeless> jelmer: do you know about path_policy=append ?
[14:31] <james_w> fullermd: :)
[14:31] <lifeless> things
[14:35] <jelmer> lifeless: no, and cna't find any reference ot it in the bzr source
[14:35] <jelmer> with apologies for my bad spelling today
[14:35] <lifeless> e.g.
[14:35] <lifeless> public_branch:policy = appendpath
[14:36] <lifeless> for instances... I have:
[14:36] <lifeless> [sftp://bazaar.launchpad.net/%7Ebzr/]
[14:36] <lifeless> public_branch = http://bazaar.launchpad.net/~bzr/
[14:36] <lifeless> public_branch:policy = appendpath
[14:36] <lifeless> create_signatures = always
[14:36] <lifeless> post_commit_to = bazaar-commits@lists.ubuntu.com
[14:36] <LeoNerd> Hmm.. What's that do?
[14:37] <jelmer> lifeless: ah, that would at least help with the configuration bit
[14:37] <jelmer> but still not allow pushing multiple related branches at once, for example
[14:38] <lifeless> LeoNerd: it makes all branches unter that path be given a public location of the public_branch component plus the relative path under the sftp root
[14:38] <jelmer> lifeless: also, is this settable in the repository config?
[14:39] <jelmer> i don't use locations.conf because it means every time I rename a branch or one of it's parent directories I lose configuration
[14:39] <gotgenes> I can checkout but not commit to an SVN repository with a self-signed certificate. The latter gives a pycurl error
[14:39] <jelmer> gotgenes: what version of bzr-svn are you running?
[14:39] <fullermd> I don't think we _have_ a repository config...
[14:39] <gotgenes> 0.91 with v 0.34 bzr-svn
[14:40] <jelmer> gotgenes: not 0.4.3 ?
[14:40] <jelmer> I doubt bzr-svn 0.3.4 works with bzr 0.91
[14:41] <jelmer> gotgenes: this is bug 150699, which has been fixed in bzr-svn's 0.4 branch
[14:41] <ubotu> Launchpad bug 150699 in bzr-svn "Cannot commit on svn+https checkout" [Low,Fix committed] https://launchpad.net/bugs/150699
[14:41] <gotgenes> jelmer: meant v 0.4.3
[14:41] <gotgenes> dyslexia
[14:41] <jelmer> gotgenes: ok, in that case updating to the 0.4 branch (or 0.4.4, when it's released) should fix that issue
[14:42] <gotgenes> jelmer: ah, okay
[14:42] <jelmer> 0.4.4 will be released later this week
[14:42] <gotgenes> jelmer: should I just bzr co your branch?
[14:43] <jelmer> gotgenes: Yep, just checking it out and linking ~/.bazaar/plugins/svn to it should be sufficient
[14:44] <gotgenes> jelmer: great! and then it's bzr pull to update from your changes every now and then?
[14:44] <jelmer> gotgenes: if you use "bzr up" if you've "bzr co" earlier
[14:44] <jelmer> "bzr pull" if you used "bzr branch" earlier
[14:44] <gotgenes> jelmer: ah, okay
[14:45] <lifeless> jelmer: no, its locations.conf - not coupled to repo's
[14:45] <jelmer> most confusing thing in the bzr UI at the moment, imho
[14:47] <jroes> anyone know a workaround for bug 107593?
[14:47] <ubotu> Launchpad bug 107593 in bzr "bzr unable to ask password for access over bzr+ssh:// or sftp:// when plink.exe used as SSH client" [Low,Confirmed] https://launchpad.net/bugs/107593
[14:48] <jroes> I literally can't use bzr on win32 to push branches
[14:48] <jroes> I'd consider it a showstopper for win32, but then again, I guess much less people use plink than I thought
[14:51] <jelmer> jroes: any reason you can't use paramiko?
[15:01] <jroes> well, tbh, I simply downloaded a binary dist of bzr, and I'm guessing paramiko is just bundled in there somewhere
[15:01] <jroes> I don't honestly know what paramiko is besides "ssh2 for python" :)
[15:01] <Peng> jroes: SSH and SFTP for Python.
[15:06] <lifeless> jroes: it is a bit of a showstopper for plink users; I guess we don't have all that many, or they are using the putty agent
[15:07] <jroes> plink is the putty agent?
[15:07] <jroes> oh, pageant is
[15:07] <jam-laptop> pageant is the putty agent
[15:07] <jroes> I don't know the binary names, I just click the pretty icons :)
[15:08] <jam-laptop> I think the mistake is that we use plink if we can find it, even though paramiko works better :)
[15:08] <jroes> so, I guess I'm confused, I just use pageant, something else makes the decision as to whether or not to use paramiko or plink
[15:08] <jroes> but I'm not the one making that decision, and I don't know how to choose :)
[15:08] <jam-laptop> we see if we can find plink in the path
[15:08] <jroes> ah
[15:09] <jam-laptop> I don't know that we have a way to disable it ....
[15:09] <jam-laptop> I guess the assumption is that if it is available you have it configured
[15:09] <jroes> ah ha
[15:09] <jam-laptop> certainly both paramiko and plink will talk to pageant
[15:09] <jroes> ok, removing plink from path :)
[15:10] <jam-laptop> that should do it :)
[15:10] <jroes> yes, it sure did, awesome :)
[15:11] <jroes> thank you very very much :)
[15:11] <spiv> You can override the choice of SSH bzr uses with an environment variable IIRC.
[15:12] <spiv> set BZR_SSH=paramiko
[15:12] <spiv> I think that would do it.
[15:13] <jroes> excellent.  I'd probably use that if I needed plink :)
[15:13] <spiv> (It'll be fractionally faster too, because it won't need to autodetect which SSH to use)
[15:14] <Peng> How much does paramiko hurt bzr's SSH performance?
[15:16] <spiv> Peng: probably only slightly; I believe most of the heavy lifting is done in the PyCrypto module, which is written in C.
[15:16] <Peng> Hmm, pycrypto is a good point.
[15:18] <pattern> is there any way to have bzr use xxdiff to compare changes instead of the regular diff program?
[15:20] <lifeless> pattern: the difftools plugin IIRC
[15:21] <pattern> ok, cool
[15:21] <pattern> thanks
[15:58] <ubotu> New bug: #158350 in bzr-eclipse "import wizard does not display" [Undecided,New] https://launchpad.net/bugs/158350
[16:17] <ubotu> New bug: #158333 in bzr "bzr-rebase-0.2 crashes with bzr-0.92rc1" [Undecided,Confirmed] https://launchpad.net/bugs/158333
[16:20] <mrevell> Can anyone tell me where bzr help draws the "usage" line from?
[16:21] <james_w> mrevell: it creates them by looking at attributes of the command.
[16:22] <mrevell> thanks james_w.
[16:26] <jam-laptop> mrevell: it generally looks at "takes_args" and "takes_options"
[16:26] <jam-laptop> though takes_args is the one to generate Usage
[16:27] <jam-laptop> mrevell: bzrlib.commands.Command._usage()
[16:27] <mrevell> jam-laptop: Thanks.
[16:27] <jam-laptop> Command.get_help_text() is what you would change
[16:28] <jam-laptop> if you wanted to move the SeeAlso stuff
[16:28] <jam-laptop> or bzrlib.help_topics.help_as_plain_text()
[16:28] <jam-laptop> no, it is the get_help_text()
[16:28] <jam-laptop> I was just confused by the if blocks
[16:29] <lifeless> jam-laptop: hi. lets talk pack2
[16:30] <jam-laptop> lifeless: sure
[16:30] <jam-laptop> It is always fun to see you on at the same time as I am
[16:31] <lifeless> :)
[16:31] <lifeless> so, zlib, I think thats kinda interesting to do (but the current packs format is frozeN)
[16:32] <lifeless> I'd really like to see xdelta/mutiparentdiffs/arbitrary knit diffs though
[16:33] <jam-laptop> mrevell: I'll reply to you with a simple patch
[16:33] <jam-laptop> lifeless: I'm curious if the 10% zlib difference would scale for first commit
[16:33] <mrevell> mrevell: Thanks. I may need to ask what seem like simple questions though :)
[16:35] <james_w> Is a branch allowed to have more than one root commit? (i.e. commit with no parents)
[16:35] <lifeless> jam-laptop: easy enough to test; once you have it in a different format we can convert moz  to it :)
[16:36] <lifeless> james_w: yes
[16:36] <lifeless> mw: are you really talking to yourself?
[16:36] <jam-laptop> lifeless: my branch has it in the zlib format at the moment
[16:36] <jam-laptop> james_w: You can merge 2 ancestries together
[16:37] <jam-laptop> so you can get two root commits
[16:37] <fullermd> james_w: Sure, I do it all the time.
[16:38] <mw> lifeless: what's that?
[16:39] <james_w> thanks. I guess I set parent_ids to an empty list, and last_revision_info to (0, NULL_REVISION).
[16:39] <jam-laptop> mw: lifeless was actually trying to point out to mrevell that he wrote "mrevell:" rather than probably replying to me
[16:39] <lifeless> I'll be right back, we're grabbing foodstuffs
[16:39] <mrevell> Lordy
[16:40] <dato> mw: he meant to address mrevell
[16:40] <mw> people confuse us all the time
[16:40] <mw> (that is a lie)
[16:41] <fullermd> Oh, you can't trust any of those 'm' people anyway.
[16:43] <lifeless> mw: I meant mrevell
[17:01] <lifeless> I'm back
[17:02] <lifeless> jam-laptop: so, where is your branch? I'll convert lp to your new format
[17:03] <jam-laptop> lifeless: http://bzr.arbash-meinel.com/branches/bzr/0.92-dev/knit_parents
[17:03] <jam-laptop> If you prefer, I could push it to LP or something
[17:04] <lifeless> thats fine
[17:04] <lifeless> does it affect knitpack-experimental, or is it a new repo format ?
[17:22] <mrevell> The help for bzr inventory has a line that reads, "It is also possible to restrict the list of files to a specific set. For example: bzr inventory --show-ids this/file" Can anyone explain "this/file" to me, please?
[17:23] <jam-laptop> mrevell: if it is "this/" then it will only show files/directories underneath this/
[17:23] <fullermd> I presume it means the path of a file/subdir in the branch...
[17:23] <lifeless> mrevell: try it :). I think its just a filter on the path.
[17:23] <jam-laptop> if it is "this/file" then it would only show this/file
[17:23] <jam-laptop> (so I'm pretty sure it is 90% useless to give it a filename, but there are edge cases where it could be useful)
[17:24] <mrevell> When I tried it I got a "paths are no versioned" message.
[17:24] <mrevell> s/no/not
[17:25] <fullermd> Works for me with .dev and 0.91.
[17:26] <mrevell> fullermd: Me too now, I made a typo. Cheers.
[17:31] <lifeless> jam-laptop: so is it a new repo format or does it alter knitpack-experimental
[17:31] <jam-laptop> lifeless: it alters knitpack-experimental, but uses a different format string on disk
[17:31] <jam-laptop> Which means you can't pull from a pack into a pack
[17:31] <jam-laptop> but it was reasonable to experiment with
[17:31] <jam-laptop> mrevell: well was "this/file" versioned?
[17:31] <lifeless> ok, so I won't overwrite my devpad test branch :|
[17:32] <jam-laptop> good idea :)
[17:32] <mrevell> jam-laptop: In the end, yes, once I understood properly and also corrected a typo. The use of "this" threw me a bit.
[17:45] <jelmer> lifeless: the argument for packs is still --knitpack-experimental, is it a good idea to upgrade yet?
[17:45] <lifeless> jelmer: knitpack-experimental is frozen now
[17:46] <lifeless> jelmer: however it's not suitable for uninformed use because of e.g. obsolete_packs, slow annotate[no cache], etc
[17:46] <jelmer> what are the chances of corruption?
[17:47] <lifeless> reconcile your knits branch before you convert
[17:47] <lifeless> after that it should be fine
[17:47] <lifeless> I've been dogfooding for a couple of months, no corrpution
[17:47] <jelmer> I'm considering moving my Samba branches to packs, but would rather not lose any data in the process :-)
[17:47] <lifeless> here is the acid test:
[17:47] <jelmer> ok, I'll give it a go then. most of my code is mirrored in svn anyway
[17:47] <lifeless> convert to packs, then push to a new pack branch
[17:48] <lifeless> if that works (and it will if you've reconciled first), then no problems
[17:48] <lifeless> read the docs :) (doc/developer/knitpack.txt)
[17:48] <fullermd> 'k, here's a random thing that's bugged me for a little while...
[17:48] <fullermd> Why does 'reconcile' exist?
[17:48] <fullermd> Which is to say, "Why isn't there 'check --fix-broken-crap'?"
[17:49] <lifeless> 'check' implies readonly in the name.
[17:49] <lifeless> in terms of code, we should probably have Reconcile/Reconciler --check-only
[17:49] <fullermd> Well, 'fsck' has check in the name, but nobody's surprised that it fixes what's fixable and shouts loudly about what isn't...
[17:50] <lifeless> fullermd: actually, I was surprised when I first encountered that.
[17:51] <Kinnison> OOI is reconcile meant to produce progress info?
[17:51] <lifeless> some; patches solicited.
[17:51] <Kinnison> It has been throbbing with a 0/0 message for ages now for me, after saying "Inventory ok>"
[17:51] <lifeless> its throbbing
[17:51] <Kinnison> :-)
[17:51] <Kinnison> Fair enough
[17:52] <Kinnison> Hmm, presumably it'd be telling me if it had to change anything?
[17:53] <lifeless> mebbe
[17:54] <Kinnison> :-)
[17:56] <bialix> jam-laptop: hi
[18:08] <jam-laptop> hi bialix
[18:09] <bialix> do you have a chance to upload new installers to the bazaar site? or I need to ask another person?
[18:09] <fullermd> %  bzr stat | wc -l
[18:09] <fullermd>     1288
[18:09] <fullermd> Sheesh.
[18:15]  * fullermd blinks.
[18:16] <lifeless> fullermd: ?
[18:16] <fullermd> Didn't selftest used to have an arg to not blow away the temp dirs?
[18:18] <fullermd> It's hard to experiment with the env and see what's failing in it, when it gets blown away when selftest finishs...
[18:18] <jelmer> yes, --keep
[18:19] <fullermd> Why was it taken out?
[18:21] <jelmer>     * Remove selftest ``--clean-output``, ``--numbered-dirs`` and
[18:21] <jelmer>       ``--keep-output`` options, which are obsolete now that tests
[18:21] <jelmer>       are done within directories in $TMPDIR.  (Martin Pool)
[18:22] <fullermd> Does that seem wrong to anybody else?
[18:23] <fullermd> Seems kinda non-sequitor to me.
[18:24] <fullermd> Mmm.  Looks like even before the rev that removed it, it didn't exist; keep_output just gives a warning about it doing nothing.
[18:25] <fullermd> Looks like it was all poolie a few months before that.
[18:26] <gotgenes> Is 0.92rc1 going to be in the bazaar Ubuntu repos soon?
[18:27] <lifeless> yes, its high on my todo
[18:27] <jam-laptop_> fullermd: generally you can use BZR_PDB or import pdb; pdb.set_trace() to drop into a debugger
[18:27] <lifeless> in a sprint at the moment though
[18:27] <jam-laptop_> which will (a) allow you to check the disk
[18:27] <jam-laptop_> and (b) have you in a debugger which has more information anyway
[18:27] <gotgenes> lifeless: great, I'm looking forward to it!
[18:28] <bialix> jam-laptop_?
[18:28] <fullermd> Mmm.  Does it need to be set to anything in particular?  '1' apparently doesn't do the trick...
[18:29] <james_w> fullermd: that only triggers on exceptions I think
[18:29] <jam-laptop_> james_w: correct
[18:30] <fullermd> Well, the test failure is an AssertionError...
[18:30] <jam-laptop> fullermd: yeah, but it needs to be caught by the main loop, and not the test suite
[18:30] <jam-laptop> so you probably need import pdb; pdb.set_trace()
[18:30] <fullermd> run_bzr_catch_errors().... but it's not using run_bzr_catch_errors.
[18:30] <lifeless> jam-laptop: reviewed your patch
[18:31] <fullermd> I put it in bzrlib/__init__.py, and it doesn't seem to change anything...
[18:32] <jam-laptop> bialix: downloading now
[18:32] <jam-laptop> fullermd: you need to put it at the point that the test is failing
[18:32] <fullermd> OK, talk to me like I'm an idiot who doesn't know anything about python.
[18:33] <fullermd> How do I point it?  pdb.set_trace(bzrlib.tests.[...])?
[18:34] <jam-laptop> vi bzrlib/tests/test_file.py
[18:34] <jam-laptop> :line that is failing
[18:34] <jam-laptop> O (insert a line)
[18:34] <jam-laptop> import pdb; pdb.set_trace()
[18:34] <jam-laptop> ESC
[18:34] <jam-laptop> :wq
[18:36] <lifeless> jam-laptop: I like :!./bzr --no-plugins selftest $(basename % | sed -e /.py//)
[18:37] <fullermd> Ah, OK.  That worked, thanks.
[18:38] <fullermd> OK.  So I'm snatching a little time to work on this patch from last month to make pull do an open_containing() instead of open().
[18:39] <jam-laptop> um... why?
[18:39] <jam-laptop> In general you shouldn't be pulling on a filename
[18:39] <jam-laptop> If there is a specific reason then maybe
[18:39] <jam-laptop> but otherwise you have mistyped something
[18:39] <jam-laptop> and it is generally better to fail
[18:39] <jam-laptop> than to pull the wrong branch
[18:39] <fullermd> Because "bzr pull --overwrite -r-5 . ; *boom* ; bzr pull --overwrite -r-5 .. ; *boom* ; bzr pull --overwrite -r-5 ../.. ; [...]" is a freakin' annoying process to go through.
[18:40] <jam-laptop> hmm.. interesting thought
[18:40] <lifeless> fullermd: bzr pull --overwrite -r-5 $(bzr root ..)
[18:40] <jam-laptop> well, "bzr pull --overwrite ($bzr root) -r-5"
[18:40] <jam-laptop> since I think he is just wanting to revert when he is inside a tree
[18:40] <lifeless> jam-laptop: jinx!
[18:40] <jam-laptop> lifeless:  not really, I wrote it from what you had :)
[18:40] <jam-laptop> I just removed the ".."
[18:41] <lifeless> oh right
[18:41] <lifeless> fullermd: 'bzr update -r -5' ?
[18:41] <jam-laptop> hmm, I just ran into the "cannot update in a checkout of an http branch"
[18:41] <jam-laptop> I'll try to debug it
[18:41] <jam-laptop> lifeless: if we had --r
[18:41] <jelmer> lifeless, update doesn't support -r does it ? :-)
[18:41] <fullermd> No, I really did want to pull --overwrite; change the branch head.
[18:41] <jam-laptop> As I recall the patches haven't been merged
[18:41] <jam-laptop> because of questions as to how -r should be evaluated
[18:41] <jam-laptop> for heavyweight checkouts
[18:41] <fullermd> But I meant it rather as the specific case I hit of the general "You have to point at the branch root and nowhere else"
[18:42] <jam-laptop> fullermd: alternatively "bzr uncommit -r -5; bzr revert"
[18:42] <jam-laptop> or if you don't want to be asked
[18:42] <jam-laptop> "bzr uncommit -r -5 --force; bzr revert"
[18:42] <jam-laptop> but that does weird things if you have changes
[18:42] <fullermd> OK, see...   I solved the actual _problem_ wherein I triggered this case a month and a half ago   :p
[18:42] <lifeless> fullermd: or uncomimt -r -5 ?
[18:44] <fullermd> (and actually, it was a revision that wasn't even in the branch history that I was making the head, so uncommit would blow up last I checked)
[18:44] <fullermd> Or maybe it was history, but not mainline.  Can't remember.
[18:44] <lifeless> fullermd: I guess what I'm really saying, is 'do we have a better UI for this already, but possibly buggy?'
[18:44] <lifeless> certainly for your example I think that bzr troot is the right way to get the source to pull from
[18:45] <lifeless> hmm bzr trout
[18:45] <fullermd> Well, if we were into proliferating commands, the right UI would "bzr reset --hard" or something.
[18:46] <fullermd> But ISTM that I'm pulling from a branch, and bzr has ways to find the branch I'm pointing at, even if I'm pointing somewhere within it, so why the heck doesn't pull use them and make my life easier?
[18:46] <fullermd> (and where were you people with your objections back in mid-September when I submitted it and it got as far as PQM before the test failure kicked it back to waiting for me to have spare time again?   :p)
[18:48] <lifeless> fullermd: heh, dunno ? :)
[18:49] <fullermd> So, is this a quorum saying "no, pull shouldn't do that", and I should just ditch the patch?
[18:49] <lifeless> uhm
[18:50] <lifeless> got a thread topic for the prior patch?
[18:50] <lifeless> I'll rad up on it before sayignt that to you
[18:50] <lifeless> *read*
[18:50] <fullermd> [MERGE] Make pull more forgiving of its location
[18:50] <lifeless> *saying*
[18:50] <fullermd> Sept 11
[18:50] <fullermd> Wasn't much discussion on it.
[18:51] <fullermd> I mean, I don't feel THAT strongly about it.  It just feels like an overly-demanding UI to me.
[18:51] <lifeless> right
[18:51] <fullermd> I can see how it might confuse people who think it'll make pull somehow pull only part of a branch.
[18:51] <lifeless> so there is a serious failure mode
[18:51] <lifeless> projectA-branch/foo/project-B-branch
[18:52] <lifeless> cd local-projectA; bzr pull /projectA-branch/foo/project-B-branch --overwrite
[18:52] <fullermd> Which is roughly why the test suite croaks on it.
[18:52] <lifeless> now, if I am used to having to give the exact url, I won't in scripts etc do that
[18:53] <lifeless> if I don't know that the subdir is a nested tree rather than a subdir this converts projectA-branch *into* project-B-branch
[18:53] <lifeless> which is really bad
[18:56] <lifeless> ok, mailed to that thread.
[19:06]  * fullermd nods.
[19:06] <fullermd> Good 'nuff.  I'll shelve it 'till we see where that ends up.
[19:17] <jam-laptop> fullermd: we could special case "."
[19:18] <fullermd> That sounds hackier.
[19:18] <fullermd> If we put that sorta smarts into 'pull', it'd probably be better as a --self option or something.
[19:20] <jam-laptop> bialix: the files have been uploaded
[19:20] <jam-laptop> it seems whoever uploaded 0.91
[19:20] <jam-laptop> didn't update the MD5SUM and SHA1SUM files
[19:22] <jam-laptop> nor did they fix the line-ending issue
[19:25] <Peng> Is 'bzr init && bzr pull foo' slower than 'bzr branch foo' (and maybe 'bzr upgrade foo')?
[19:29] <jam-laptop> Peng: well, it depends if you have to change formats
[19:30] <jam-laptop> "bzr branch foo" generally creates a local branch in the same format as the remote one
[19:30] <jam-laptop> "bzr init && bzr pull" will create a local branch in the default format
[19:30] <jam-laptop> and then pull the revisions (converting as necessary)
[19:30] <jam-laptop> Otherwise they should be equivalent
[19:30] <Peng> jam-laptop: Yeah, I was changing formats.
[19:30] <jam-laptop> bzr branch + bzr upgrade ....
[19:30] <jam-laptop> I couldn't tell you for sure if that is faster or not
[19:31] <Peng> Wow.
[19:31] <jam-laptop> I've never benchmarked it.
[19:31] <jam-laptop> I would guess it might be faster
[19:31] <jam-laptop> because it has all the data locally already
[19:31] <Peng> dirstate-tags is 212 MB, knitpack is 175.
[19:31] <jam-laptop> rather than streaming the data and then converting
[19:31] <jam-laptop> Peng: as judged by "du" ?
[19:31] <Peng> I think branch && upgrade could be slower, since it has to go through and verify everything twice.
[19:31] <jam-laptop> could be
[19:32] <jam-laptop> as I said, I haven't tested it
[19:32] <Peng> jam-laptop: As judged by right-clicking in a file manager, yeah.
[19:32] <jam-laptop> Often that includes the wasted space
[19:32] <jam-laptop> so if you have lots of small files
[19:32] <jam-laptop> they all take up a "block" (usually 4k)
[19:32] <jam-laptop> so 100 2k files takes up a lot more space than 1 200k file
[19:32] <Peng> True.
[19:32] <jam-laptop> And I believe after upgrade/pull you end up with 1 pack file
[19:32] <Peng> (And there were a *lot* of files.)
[19:32] <Peng> jam-laptop: Yes.
[19:33] <jam-laptop> Not to mention we create 2 knit files per source file
[19:33] <jam-laptop> (1 data, 1 index)
[19:33] <Peng> Wait, 177 MB for packs, counting things other than the .pack file.
[19:33] <jam-laptop> versus 5 files for a pack
[19:33] <jam-laptop> 1 data, 4 indicies
[19:33] <Peng> Mm-hmm. 7 files vs. 24,761.
[19:36] <fullermd> The heck?  There's no test for Branch.open_from_transport()?
[19:37] <bialix> jam-laptop: thanks, I will update wiki
[19:39] <jam-laptop> does anyone remember the "bzr update" bug?
[19:39] <jam-laptop> Where it would refuse to update if you had a heavy checkout
[19:39] <jam-laptop> I tracked down the problem to URL escaping
[19:39] <fullermd> I think I'd remember that blood pressure spike...
[19:39] <jam-laptop> bound_location() == http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk/
[19:40] <jam-laptop> source.base == http://bazaar.launchpad.net/%7Ebzr/bzr-gtk/trunk/
[19:40] <jam-laptop> Notice that the ~ has been escaped
[19:40] <jam-laptop> So it only fails some of the time
[19:40] <jam-laptop> but notable for all LP urls
[19:40] <fullermd> Hm.  OK, so maybe there _is_ a small upside to bzr+ssh still not supporting ~...
[19:42] <Verterok> moin
[19:42] <dato> % head -1 .bzr/repository/packs/e4307cb31157e6aa229b28ef2ada8346.pack
[19:42] <dato> Bazaar pack format 1 (introduced in 0.18)
[19:43] <dato> is that known? (the "0.18" bit)
[19:43] <dato> ah
[19:43] <dato> I guess it's correct.
[19:58] <jam-laptop> dato: the stream/container format was introduced in 0.18
[19:58] <dato> yeah, I realized one line later :)
[20:02] <Peng> What's the point of having packs and indices in separate directories?
[20:02]  * Peng wanders off.
[20:03] <fullermd> Miscegenation preventation.
[20:05] <lifeless> dato: yes, that is correct for that file.
[20:05] <lifeless> Peng: bit of a yagni, but we want to makeindices optional data
[20:20] <jelmer> argh, git's merge does indeed suck
[20:20] <jelmer> simply tracking upstream for a project during some time causes conflicts in several unrelated pieces of the code
[20:21] <Verterok> beuno: ping
[20:27] <beuno> Verterok!
[20:27] <beuno> :D
[20:27] <Verterok> Hi
[20:27] <beuno> I just updated the plugin a few minutes ago, ran into the merge bug, and you fixed it a few minutes later
[20:27] <Verterok> ;)
[20:28] <Verterok> same happen to me while working in bzr-eclipse
[20:28] <Verterok> beuno: I need your help, are you available?
[20:28] <beuno> Verterok, sure
[20:28] <lifeless> jelmer: well let jerry kow :)
[20:28] <lifeless> *know*
[20:29] <jelmer> blogging as we speak :-)
[20:30] <Verterok> beuno: I played a bit with missing --xml, in a new branch of xmloutput plugin. it change the xml structure so it is ~ "well-formed"
[20:31] <jam-laptop> poolie: hi
[20:31] <jam-laptop> vila: ping
[20:32] <poolie> hi jam, how's it going
[20:32] <Verterok> beuno: if you can take a look to the new format, and see if it's ok for the current use you giviin to it
[20:32] <jam-laptop> poolie: pretty good. I ran into the "bzr update" in a checkout failure
[20:33] <jam-laptop> It seems we are encoding some urls
[20:33] <jam-laptop> but not all
[20:33] <jam-laptop> so self.get_bound_location() != self.get_master_branch().base
[20:33] <jam-laptop> If there is a ~ in it
[20:33] <jam-laptop> Which is .... *all* LP urls.
[20:33] <jam-laptop> Unless you did the original checkout with %7E instead of ~
[20:33] <beuno> Verterok, I've got revno 41 and everything seems to have imported correctly (I cleared the DB and reimported everything(
[20:35] <beuno> Verterok, ~3000 revisions from ~80 repos and over 100k of files/dirs imported correctly
[20:35] <Verterok> beuno: nice!
[20:36] <beuno> Verterok, indeed, seems like you've done great work
[20:39] <Verterok> beuno: I changed the way we track the open/close of the tags, now it's a lot easier to handle espcial cases (like the nested merges)
[20:40] <Verterok> beuno: are you using 'missing --xml' in your application?
[20:44] <beuno> Verterok, not yet, no
[20:44] <beuno> just using log at the moment
[20:44] <Verterok> ok
[20:45] <beuno> the plan was to start implementing missing and annotate as soon as everything got stable
[20:45] <beuno> and it seems we're at that point now
[20:45] <beuno> Verterok, you changed the was the tags where opened/closed in general, or just in merges?
[20:47] <Verterok> only for <merge> and <log>, now it use some kind of stack to keep track of what tags are opened
[20:48] <Verterok> beuno: about missing --xml, once you give me the OK with the new xml structure I want to merge the changes in trunk
[20:48] <Verterok> and make a 0.2 release of xmloutput :)
[20:49] <beuno> Verterok, doesn't missing output the same way log would?   because if that's the case, I'd rather not delay 0.2 while I implement it on my software (could take a day, could take weeks)
[20:50] <beuno> I have to develope the bit that compares each of the users' repos to the main one, and outputs missing
[20:50] <beuno> that will take tweaking in more then a few parts
[20:52] <Verterok> beuno: the answer is yes and no, it show the logs the same way as log, but the current xml isn't "well-formed" because the root node is <missing> but th xml ends with a </log> tag
[20:52] <beuno> Verterok, aaaah, right, you want me to fix that and run a few tests with mt repos?
[20:52]  * beuno goes look for his python-developer hat
[20:52] <Verterok> the changes i made in https://code.launchpad.net/~guillo.gonzo/bzr-xmloutput/well-formed-missing fix this issue
[20:53] <Verterok> jaja
[20:53] <beuno> oooh, so it's already fixed
[20:53] <beuno> even better
[20:54] <beuno> I'm not actually importing that yet, so it won't break anything on my side, but I'll get that and run it through a few of the messier repos
[20:54] <Verterok> yes, but as you are the developer of missing --xml, I want your Ok to proceed :D
[20:55] <beuno> Verterok, right, I forget, I'm less posesive of my code as I should be. I'm on it right now, I'll get back to you in a few minutes
[20:56] <Verterok> beuno: thanks!
[20:56] <james_w> poolie: hi, are you busy at the moment?
[20:56] <poolie> yes
[20:56] <poolie> i can take a quick question here though
[20:57] <james_w> ah no, just wanted to say hello, it can wait.
[20:57] <james_w> you're a hard man to get hold of :)
[20:58] <poolie> :) i'll be out about 6 i think
[20:58] <poolie> or maybe tomorrow, or dinner?
[20:59] <james_w> yeah, I've no plans.
[20:59] <beuno> Verterok, have you had any new thoughts on how to better integrate all this in bzrlib itself?
[21:04] <beuno> Verterok, everything seems fine in the missing branch
[21:04] <beuno> all tags close correctly
[21:05] <beuno> and it looks pretty straight forward to parse
[21:07] <Verterok> beuno: only bit's of it.  Still wondering how to could be the more clean way
[21:08] <Verterok> great! proceeding to merge it with trunk for xmloutput-0.2
[21:09] <beuno> the only thing that seemed a little bit wierd, is that it outputs the <?xml version="1.0" encoding="UTF-8"?> bit before it asks for my password, but that's probably my fault
[21:09] <beuno> wouldn't happen locally either though
[21:11] <Verterok> I never realized of it, it can be fixed without much pain..so i'm donig it right now :)
[21:12] <beuno> Verterok, I didn't either, I just tested it wierder this time, local pc > ssh to server without keys
[21:15] <vila> jam-laptop: pong, and thks for mentioning that url encoding bug, ran into it some weeks ago and thought *I* was at fault :)
[21:20] <jam-laptop> vila: well, you are at fault, since you introduced _split_url and _unsplit_url :)
[21:20] <jam-laptop> Which causes "get_transport(url).base == url" to fail
[21:20] <lifeless> jam-laptop: did my review make sense ?
[21:21] <lifeless> jam-laptop: are you interested in work ing on e.g. xdelta/multiparent for packs ?
[21:21] <jam-laptop> for what to do moving forward for pack2 ?
[21:21] <jam-laptop> yeah, it made sense
[21:21] <Verterok> beuno: it should be fixed, in revno 45 (of the branch)...waiting your confirmation
[21:21] <vila> jam-laptop: how can that cause an encoding problem ?
[21:21] <jam-laptop> lifeless: And yes, I'm interested in doing xdelta stuff
[21:21] <jam-laptop> vila: _unsplit_url() has "path = urllib.quote(path)"
[21:22] <jam-laptop> Which causes "~" => "%7E"
[21:22] <jam-laptop> I'm curious what it will do to "sftp://foo/~/" paths
[21:23] <beuno> Verterok, works like a charm, go get 0.2 out there, I can't hold the screaming crowd anymore
[21:23] <vila> hmm, the test suite did use paths that needed quoting if I recall correctly
[21:23] <jam-laptop> well, >>> t = bzrlib.transport.get_transport('sftp://juju/~/.bazaar')
[21:23] <jam-laptop> t.base
[21:23] <jam-laptop> >>> t.base
[21:23] <jam-laptop> 'sftp://juju/%7E/.bazaar/'
[21:24] <jam-laptop> But it still works to get files from that location
[21:24] <jam-laptop> So somehow sftp realizes it is still a relative path
[21:24] <vila> nad I doubt I introduced a gratuitous quoting, more probably I inherited that from one transport and there was different paths regarding the quoting...
[21:24] <vila> s/nad/and/
[21:25] <jam-laptop> oh sure
[21:25] <jam-laptop> I'm just blaming you to be cruel :)
[21:25] <Verterok> beuno: JAJAJA!
[21:25] <vila> I'm hurt, bye
[21:26] <vila> kidding, but can't stay, see you tomorrow (in roughly 12 hours in TZ-independant parlance :)
[21:26] <jam-laptop> k
[21:26] <jam-laptop> vila: I think what you did change is that in the past
[21:26] <jam-laptop> only *some* transports
[21:27] <jam-laptop> used base = _unsplit(_split)
[21:27] <jam-laptop> and others used
[21:27] <jam-laptop> base = base
[21:27] <jam-laptop> self.base = base
[21:29]  * jam-laptop => heads to a coffee shop
[21:42] <beuno> Verterok, a very useless thought just came to mind, with the XML structure in place, we might be able to add a --html switch to it too
[21:42] <beuno> maybe it can be a different plugin
[21:42] <beuno> dunno what's best
[21:42] <beuno> but it might be nice to have it output a nice-ish HTML
[21:42] <beuno> and it seems pretty trivial once XML is correctly generated
[21:44] <Verterok> beuno: you are absolutely right, but it still need work, so we can reuse the current core of the xml generation.
[21:45] <Verterok> beuno: the plugin approach seems nice, in that case the xml output should be a plugin too :)
[21:46] <beuno> Verterok, :D   and that would just leave it open to add more, like CSV
[21:46] <beuno> not sure if they all should be seperate plugins if we're going to go down that road though, maybe just one that outputs stuff in all kinds of formats
[21:47] <Verterok> not sure about about csv.
[21:49] <beuno> Verterok, I'm just thinking outloud, if the core is flexible enough, it opens up things to output any weird format that we need/get requested
[21:49] <Verterok> it's easy to generate csv output, but I think it will lose a lot of information (like the merges, etc).
[21:49] <beuno> Verterok, not sure it would, it can be an extra column
[21:50] <Verterok> beuno: the core isn't flexible enough, al least not a this time...maybe in a few weeks ;)
[21:50] <beuno> Verterok, I'm just making sure you don't have any free time  :D
[21:51] <beuno> that said, I'll be glad to jump into coding a bit more in that aspect
[21:51]  * Verterok have much fun with python than with Java
[21:51] <Verterok> s/much/much more/
[21:51] <beuno> Verterok, Java is evil
[21:52] <Verterok> we should tell that to the Eclipse guys
[21:53] <beuno> Verterok, we can open a bug  :D
[21:53] <beuno> "Eclipse should be in Python"
[21:53]  * Verterok LOL
[21:54] <Verterok> back to the business, I think the html output can be added without much work
[21:55] <beuno> Verterok, me too, if you work on the core bits, I can start some work on that
[21:55] <beuno> I'll branch out for now, and we'll decide if it'll be a new plugin, a switch, or a new VCS all together later on
[21:56] <Verterok> beuno: if you look to __open_log, __open_merge, etc and __log_revision in logxml.XMLLogFormatter, you would realize it'll only require knowledge of html
[21:57] <beuno> Verterok, I've actually been peeking at it, that's why it occured to me
[21:58] <Verterok> beuno: maybe a new plugin is the right choice, and when the core is ready, both plugins can be merged
[21:58] <beuno> Verterok, gotcha, will take that aproach then
[21:59] <beuno> if that's the case, then I'm going to look into HTML templating to be able to present it as nice as possible
[22:02] <Verterok> beuno: in a second thought,  actually, you can (and maybe should) subclass XMLLogFormatter (XHTML is a subset of XML, right?) :)
[22:30] <Peaker> any way to get bzr to remember URL passwords?
[22:36] <lifeless> Peaker: coming very soon - see vila's auth-ring patch
[22:36] <jam-laptop> ?
[22:54] <Peaker> is it safe to "bzr pull" while a "bzr push" is running?
[22:55] <jam-laptop> Peaker: yes
[22:55] <jam-laptop> it won't pull the new stuff
[22:55] <jam-laptop> but you can generally issue any 2 commands
[22:55] <Peaker> won't push you mean?
[22:55] <jam-laptop> and if they would conflict
[22:55] <jam-laptop> one will block
[22:55] <jam-laptop> If you bzr push revision 10
[22:55] <jam-laptop> and while that is going
[22:56] <jam-laptop> you bzr pull to revision 12
[22:56] <Peaker> ok thanks
[22:56] <jam-laptop> only revision 10 will be pushed
[22:56] <jam-laptop> it won't push the newly pulled revisions
[22:56] <Peaker> yeah ok
[22:56] <Peaker> that's alright cause the push is a huge init on the remote branch
[23:12] <lifeless> jam-laptop: heading to to dine.
[23:13] <lifeless> jam-laptop: tomorrow I'dlike to tie down what is different in pack2
[23:13] <jam-laptop> sure
[23:20]  * jam-laptop => out for a while