[00:00] <jelmer> lifeless: thanks, much appreciated!
[00:03] <poolie> lifeless: could you repaste to me or point me to the numbers for gc performance on bzr.dev please?
[00:04] <lifeless> http://paste.ubuntu.com/116333/ <- these?
[00:05] <lifeless> poolie: or the usertest ones ian did?
[00:07] <poolie> that looks right
[00:08] <poolie> that's the first 1000 commits of bzr?
[00:08] <Odd_Bloke> So I'm using looms for something at the moment.  I have two looms currently, and I have a change to make which belongs between them.  Can I do that in any sensible manner?
[00:08] <lifeless> poolie: thats more
[00:08] <lifeless> poolie: I have the first 1000 stats , one sec
[00:08] <poolie> if this is more that's fine
[00:09] <poolie> so it's something more than 1000 commits of bzr? all of them?
[00:09] <lifeless> 7410
[00:09] <lifeless> not sure of the revno
[00:11] <lifeless> http://paste.ubuntu.com/117486/
[00:12] <poolie> thanks
[00:15] <lifeless> spiv: woo
[00:15] <lifeless> spiv: no new failures, just that one test I discussed with John to tweak, and a 1200 line patch to eyeball :P
[00:17] <spiv> Heh.
[00:17] <spiv> Hmm, overdue for breakfast.
[00:29] <lifeless> spiv:
[00:29] <lifeless> # branch.sprout(bzrdir) is defined as using the branch format selected
[00:30] <lifeless> # by bzrdir; format preservation is achieved by parameterising the
[00:30] <lifeless> # bzrdir during bzrdir.sprout, which is where stacking compatibility
[00:30] <lifeless> # checks are done. So this test tests that each implementation of
[00:30] <lifeless> # Branch.sprout delegates appropriately to the bzrdir which the
[00:30] <lifeless> # branch is being created in, rather than testing that the result is
[00:30] <lifeless> # in the format that we are testing (which is what would happen if
[00:30] <lifeless> # the branch did not delegate appropriately).
[00:31] <spiv> lifeless: +1
[00:31] <mwhudson> which reminds me of something
[00:31] <mwhudson> what's the difference between clone and sprout?
[00:31] <lifeless> mwhudson: push and branch
[00:31] <lifeless> mwhudson: identical copy vs new line of development
[00:32] <lifeless> spiv: so with that explanation, it seems reasonable to me, to say, if (remote), parameterise bzrdir with [arbitrary non-source branch format]
[00:32] <mwhudson> ok
[00:32] <lifeless> spiv: and otherwise leave well enough alone
[00:33] <igc> lifeless, spiv: pull is giving me grief in brisbane-core saying ...
[00:33] <igc> "must end write group before releasing wrote lock"
[00:34] <lifeless> igc: that means that its breaking in a @write_locked decorator
[00:34] <igc> I've spent 30 minutes trying to find the problem but no luck so far :-(
[00:34] <lifeless> and the code path isn't aborting the write group [generally a bug]
[00:35] <lifeless> igc: disable that assertion, you'll see another one pop up; I thought we logged the real one or something, but perhaps not yet
[00:35] <igc> I've looked at the changes to fetch.py, repository.py and pack_repo.py but nothing stands out to my untrained eye
[00:35] <lifeless> spiv: ^ does my plan scan for you ?
[00:35] <igc> lifeless: ok, I'll try that
[00:36] <lifeless> igc: or even (if its nt a blackbox test) a pdb call inside the point that that is raise, would let you look at sys.exc_info
[00:37] <spiv> lifeless: yes, that sounds good
[00:39] <spiv> igc: ah yeah, as lifeless says that's typically like TooManyConcurrentRequests — there's an underlying exception being lost by the failure to abort the write group.  If you can change abort_write_group or something to log the current exception first, or just reraise, that might help.
[00:42] <lifeless> spiv: ok thats done and passing
[00:45] <lifeless> spiv: suggstion: in those acceptance tests we have
[00:45] <lifeless> spiv: put a ratchet now on the hpss call count
[00:46]  * spiv nods
[00:52] <lifeless> spiv: bombs away, putting up a bundle - you can pull that to get the final code
[00:54] <spiv> Ok.
[00:55] <lifeless> spiv: I think you didn't pair with me on enough of this that you can review it with clear conscience:)
[00:57] <lifeless> in the meantime, I'm going to eat, then look at record_stream().next().get_network_bytes conceptually for a bit
[00:57] <lifeless> possibly by walking, I think this is a thinking time
[01:05] <jelmer> hmm, activity reporting works on svn transports but I'm not sure it should be kept in, it makes svn look slow :-P
[01:06] <lifeless> jelmer: why?
[01:07] <jelmer> lifeless: average speed is < 100kb/s
[01:08] <jelmer> I'm getting much more than that for "native" bzr
[01:08] <jelmer> lifeless: I was kidding, it works well
[01:08] <fullermd> Hey, maybe there'll be an entirely new and original statement made in this thread about explicitly-vs-not tracking renames...
[01:08] <jelmer> I guess I should just do some more optimization
[01:10] <mtaylor> hey all you wonderful people...
[01:10] <mtaylor> anybody gonna update the bzrtools package in the PPA?
[01:11] <mtaylor> I'd like to upgrade my bzr but I can't because it'll uninstall bzrtools, and I use those too much ... :(
[01:11] <igc> lifeless, spiv: so disabling that exception didn't work, nor did looking at exc_info() via pdb ...
[01:11] <igc> it does have an exception there about NotABundle but it's a red herring caused by ..
[01:12] <igc> an attempt to read the location as a bundle early in cmd_pull
[01:12] <igc> comment that bit out and exc_info is (None,None,None)
[01:13] <jml> mtaylor: I don't know the answer to your question.
[01:13] <mtaylor> jml: oh well.
[01:13] <jml> mtaylor: but many people are in the same boat as you. perhaps the things that are in bzrtools that everyone uses should be pushed into bzr proper
[01:13] <mtaylor> jml: yes. perhaps so.
[01:14] <mtaylor> jml: or, a release policy that ensures bzrtools goes to the ppa at the same time as bzr - I'd be fine with either
[01:14] <igc> lifeless, spiv: it might be something dumb on my end - let me keep looking
[01:14] <jml> cdiff, cbranch & clean-tree are about all I use from it.
[01:14] <jml> patch sometimes
[01:15] <mtaylor> shelve
[01:15] <jelmer> mtaylor: shelve is in bzr itself these days
[01:15] <mtaylor> shelve is my savior in many case
[01:15] <mtaylor> is it?
[01:15] <mtaylor> cool
[01:16] <jelmer> there was also agreement about having clean-tree in bzr itself, but nobody has stepped up yet and actually done it
[01:16] <mtaylor> heh
[01:16]  * jml adds a personal todo
[01:22] <jelmer> poolie: what are your plans for backports exactly?
[01:22] <lifeless> igc: hi
[01:22] <jelmer> poolie: addition to PPA or replacement?
[01:23] <lifeless> igc: so unlock was being called and no exception had occured?
[01:23] <lifeless> igc: what specifici test is doing this?
[01:24] <poolie> jelmer: in addition to the PPA
[01:24] <poolie> maybe not updated immediately when we release, and maybe not done for every release
[01:25] <lifeless> igc: (I will run it and give it a shot)
[01:25] <poolie> > jml: mtaylor: but many people are in the same boat as you. perhaps the things that are in bzrtools that everyone uses should be pushed into bzr proper
[01:25] <poolie> i agree with jml
[01:25] <poolie> if "everyone has it" as seems to be the case why keep it separate
[01:29] <lifeless> so network delta reuse
[01:29] <lifeless> I think a sensible approach is:
[01:30] <lifeless> each record in a stream has a network representation
[01:31] <lifeless> we assume that a stream recipient can use any part of a stream they have seen before, for text extraction
[01:31] <lifeless> we assume a stream recipient *will* extract every text, to validate them
[01:32] <lifeless> a delta which needs data not introduced as a diff by that delta just includs that in its network representation
[01:33] <lifeless> and the stream knows what to include/not include
[01:33] <lifeless> finally, we have graph data seperate, but offer a single api call to get the right bytes for serialisation
[01:34] <lifeless> this lets compressors like knits and gc which don't embed graph data not have to grow graph data foo
[01:34] <lifeless> but lets compressors like weaves which do embed graph data just use the embedded data
[01:35] <lifeless> a minor tweak would be to say that record.get_bytes_as(record.storage_kind) if record.storage_kind not in ('chunked', 'fulltext') will return something with inline bytes for graph and raw data
[01:35] <spiv> I'm not clear on what you mean by "a delta which needs data not introduced as a diff by that delta just includs that in its network representation"
[01:36] <lifeless> spiv: a knit-delta-gz
[01:36] <lifeless> spiv: with include_delta_closure == True
[01:37] <lifeless> would just include its parents transitively up to a full text in the blob you get when you ask for the bytes
[01:37] <spiv> Ok.
[01:38] <lifeless> so a naive implementation which never recompresses might include the same external parent several times
[01:38] <spiv> So the network representation for record can vary depending on the stream's include_delta_closure flag, and what has gone on the stream prior to that record.
[01:38] <lifeless> (when we have include_delta_closure ==True)
[01:38] <lifeless> spiv: yes
[01:38] <spiv> Ok.
[01:39] <lifeless> spiv: should I start a branch that aims to test this and get it working with knits and weaves?
[01:39] <spiv> Yes please :)
[01:39] <lifeless> ok
[01:40] <spiv> Hmm, I need caffeine, but I'm out of beans.
[01:40] <lifeless> I have one remaining 'this may be bad' bit - which is that we may need (given this structure) to stash the stream of inventories during a rich root upgrade
[01:40] <lifeless> because of the 'can use anything seen before' constraint
[01:40] <lifeless> but I think writing a temporary versioned files to disk isn't really so bad
[01:40] <spiv> Ugh.
[01:41] <lifeless> alternatively, we window it
[01:41] <lifeless> we say 'anything in the last 256 items', and the generator knows that it has to track what parents are available in that window
[01:41] <spiv> Let's just kill non-rich-root already ;)
[01:41]  * spiv nods
[01:41] <lifeless> spiv: well it still applies with xml -> bbc
[01:41] <spiv> I know :)
[01:41] <lifeless> spiv: or even bbc-flavour-A to bbc-flavour-B
[01:42] <spiv> And I'm sure we'll be varying the inventory format again one day, we're good at doing that ;)
[01:42] <lifeless> because we may need random access to data from the source which is at the far end of the wire
[01:42] <lifeless> so we need a contract where the sender can say 'you need these texts to read my shit', here they are
[01:42] <lifeless> and the recipient can then access them all
[01:43] <igc> lifeless: I'm about to grab some food so here's a brain dump ..
[01:43] <igc> to trigger it ...
[01:43] <igc> bzr-gcchk init --gc-plain-chk xx
[01:43] <igc> cd xx
[01:44] <lifeless> igc: there isn't a test case that dies?
[01:44] <igc> bzr-gcchk pull ../some-pack-branch
[01:44] <igc> bzr-gcchk is brisbane-core with the latest groupcompress plugin
[01:44] <igc> usertest is dying
[01:45] <igc> it gets pass 900 revisions being pulled so my theory is ...
[01:45] <igc> it's something in groupcompress/repofmt.py, around auto-packing say
[01:46] <lifeless> bzr.dev is the test branch ?
[01:46] <igc> I added -Dpack and looked at bzr.log ...
[01:46] <lifeless> igc: oh, packing is broken
[01:46] <lifeless> igc: I was discussing this with jam
[01:46] <igc> btw, groupcompress/repofmt.py needs to import trace and use trace.mutter for -Dpack to work :-)
[01:47] <lifeless> probably need to disable autopack at the moment
[01:47] <igc> bzr.log had a message about autopacking to 1000 revs but it wasn't the very last message fwiw
[01:48] <igc> lifeless: so what's the easiest way to disable autopack?
[01:48] <lifeless> bzrlib.repofmt.pack_repo - in there somewhere ;)
[01:48] <igc> lifeless: np. I disable it in fastimport so I'll do the same thing I do there :-)
[01:48] <jelmer> poolie: thanks
[01:48] <doozer__112> hi - apologies for what's probably a basic question... ;)  But - I'm testing bazaar on XP and the tortoise? integration into the explorer shell works fine - but the only major task it doesn't seem to do is rolling back between versions of a file.  I can do it from the command line if necessary, but was wondering if I'm just missing something?!
[01:49]  * igc grabs some lunch
[01:52] <igc> lifeless: a quick update ...
[01:53] <igc> I tried the same thing with bzr.dev+groupcompress using gc-plain
[01:53] <lifeless> igc: it should break the same way, if you do multiple write groups to it; fetch from a compatible repo won't do that though
[01:53] <igc> it falls over as well, but in a different place - insert_record_stream inside the group_compress plugin
[01:53] <lifeless> doozer__112: I'm not sure, perhaps you could file a bug? (If its not obvious, thats a bug, if its not there, thats a bug too :P)
[02:04] <lifeless> poolie: re: performance figures, the insertion time includes disk read IO
[02:05] <lifeless> poolie: so its not a reliable figure yet. My observation is that its not wildly off, as each pass thrashes on the same content :P
[02:05] <lifeless> igc: a backtrace, and the exception would be good
[02:16] <doozer__112> lifeless: heh, thanks, just playing with some of the other GTK based GUI's too..
[02:17] <lifeless> spiv: please paste your knit modem code :)
[02:22] <victory747> I'm having troubles with bzr-svn - I am pulling into an existing repostiory, and since upgrading to jaunty (bzr 1.11, bzr-svn 0.5.0), all my revision-ids used to have blahblah:Dir%2Ftrunk: and now they have blahblah:Dir/trunk:
[02:22] <victory747> So it sees the branches as having diverged
[02:25] <lifeless> victory747: bzr-svn 0.5 is a fairly big upgrade, I suggest reading the release notes
[02:29] <spiv> lifeless: you mean http://people.ubuntu.com/~andrew/bzr/streaming-push ?
[02:29] <igc> lifeless: the backtrace from pulling into a gc-plain branch has just been emailed to you
[02:29] <lifeless> spiv: just the bencode bits :)
[02:30] <spiv> lifeless: http://rafb.net/p/rIAqn353.html
[02:40] <victory747> lifeless: Thanks - I think I understand now
[02:42] <lifeless> igc: ugh, uhm
[02:43] <lifeless> [02:43] <lifeless> --- repofmt.py  2009-02-10 22:08:17 +0000
[02:43] <lifeless> +++ repofmt.py  2009-02-10 22:47:37 +0000
[02:43] <lifeless> @@ -300,6 +300,8 @@
[02:43] <lifeless>          self._reconcile_does_inventory_gc = True
[02:43] <lifeless>          self._reconcile_fixes_text_parents = True
[02:43] <lifeless>          self._reconcile_backsup_inventory = False
[02:43] <lifeless> +        # Tell fetch what we require.
[02:43] <lifeless> +        self._fetch_order = 'topological'
[02:43] <lifeless>  
[02:43] <lifeless> igc: ^ try that
[02:43] <lifeless> igc: it shouldn't be needed, but if you have a broken source repo it may help
[02:45] <lifeless> spiv: thanks
[02:47] <kenichi> what's bzr for "up -r NN" where NN is a few revisions ago?
[02:47] <lifeless> kenichi: currently the closest is 'bzr revert -r NN'
[02:49] <kenichi> lifeless: that doesn't seem to work the way i'm thinking...  i want revert the whole working copy to rNN.
[02:50] <lifeless> kenichi: thats what it does
[02:50] <lifeless> kenichi: after doing that, 'bzr diff' shows the change from NN to -1
[02:51] <kenichi> ugh.. sorry, i should stop working now... yes, thanks it works.
[03:13] <poolie> igc, the display of merges in the commit template is a good idea but not a post-rc thing i think
[03:14] <igc> poolie: ok
[03:14] <igc> poolie: did you see markh's email re tortoise docs?
[03:15] <igc> he'll like them in 1.12
[03:15] <igc> apparently, it was ready for 1.11 but hasn't been landed by anyone
[03:20] <poolie> i landed something related to that...
[03:21] <tro> is ther an external api reference? http://starship.python.net/crew/mwh/bzrlibapi-oe/ seems down
[03:22] <lifeless> tro: you can run pydoctor locally
[03:23] <lifeless> mwhudson: ^
[03:23] <poolie> ah i see it
[03:23] <poolie> tro, lifeless, i'll see if we can run it on escudero
[03:23] <tro> :)
[03:36] <mrooney> Will upgrading my bzr in Intrepid fix this: "Selected-file commit of merges is not supported yet"?
[03:36] <mrooney> or, is there a way to merge just one file
[03:36] <fullermd> No, and not if you want merge tracking of it.
[03:37] <mrooney> Crap. Okay, thanks
[03:37] <lifeless> mrooney: you can merge just one file, but it becomes a cherrypick: 'bzr merge branch/FILENAME'
[03:37] <fullermd> You can fling around single file changes or the like, but history-wise it's indistinguishable from doing the same thing manually.
[03:37] <mrooney> lifeless: will merging again in the future (a full merge) work fine then?
[03:37] <lifeless> mrooney: probably
[03:38] <mrooney> okay that is what I need then, thanks I'll give it a try!
[03:39] <mwhudson> tro: http://starship.python.net/crew/mwh/bzrlibapi/ ?
[03:40] <poolie> tro: where is the -oe version linked?
[03:41] <poolie> our main doc server is apparently too old to have a packaged version of pydoctor
[03:41] <lifeless> spiv: ping
[03:42] <spiv> lifeless: pong
[03:42] <lifeless> spiv: how do you bdecode 'the first item from this long bytestream'
[03:42] <spiv> You don't.
[03:42] <lifeless> ah-ha!
[03:42] <lifeless> no wonder it was seeming difficult
[03:42] <spiv> At least, not with any bencode.py that anyone has written.
[03:42] <poolie> you could write one fairly easily
[03:43] <spiv> You could in principle do it.
[03:43] <spiv> But honestly, I've written enough network stuff like that in recent times :)
[03:43] <poolie> mwh: should i remove the link to the editable copy?
[03:44] <mwhudson> poolie: yes, i think so
[03:46] <lifeless> spiv: so heres my structure
[03:46] <lifeless> I have a NetworkRecordStream calss
[03:46] <lifeless> which takes a bytes_iterator
[03:47] <lifeless> and has a read() method that returns a generator which reconstitutes the input stream
[03:48] <lifeless> I want to dispatch to some code that isn't written yet
[03:50] <lifeless> so I want the generating code to output enough data that I can dispatch on it
[04:46] <lifeless> spiv: is _length_prefix in bzr.dev?
[04:49] <spiv> lifeless: no, but it's trivial:
[04:49] <spiv> def _length_prefix(bytes): return struct.pack('!L', len(bytes))
[04:56] <lifeless> spiv: its ok for now I'm just handwaving, we can tune Monday
[05:23] <lifeless> poolie: spiv: I'm calling it, have a good weekend
[05:23] <lifeless> spiv: I have good progress at pushing that down to the VF interface
[05:23] <lifeless> spiv: we'll still have to do the ugly vis-a-vis delta closures and so on
[05:25] <poolie> night ll
[05:26] <spiv> lifeless: cool
[05:26] <spiv> lifeless: the write group stuff is looking good too
[05:26] <spiv> poolie: woo
[05:34] <poolie> spiv, can we have a really quick call?
[05:36] <AfC> poolie: I thought you were aiming for the 1234567890 timestamp :)
[05:36] <poolie> not precisely
[05:40] <AfC> Anyway,
[05:40] <AfC> Congratulations to the Bazaar hackers on your continued persistence.
[05:44] <spiv> AfC: even in the face of lengthy mailing list threads? :)
[05:47] <fullermd> If it goes on long enough, somebody will say something that hasn't been said the last 50 times the topic was discussed.
[05:47] <fullermd> Surely.  Statistics alone...
[06:38] <fullermd> Hm.  The tarball for the 1.12 release is called bzr-1.12rc1.tar.gz ?
[06:58] <vila> hi all
[07:00] <vila> mtaylor: Are you having a problem with bzr/bzrtools getting out of sync ? Where are you getting them from ?
[07:00] <mtaylor> vila: from the ~bzr ppa
[07:00] <vila> Both will be upgraded today to 1.12 if poolie finish the 1.12 release (which he should ;-)
[07:00] <mtaylor> vila: deb http://ppa.launchpad.net/bzr/ppa/ubuntu intrepid main
[07:00] <mtaylor> cool
[07:00] <vila> In the mean time the bzr-beta-ppa contains both 1.12rc1
[07:01] <vila> mtaylor: which TZ are you in ?
[07:02] <mtaylor> vila: Pacific US
[07:03] <vila> mtaylor: then you should have then when you wake up tomorrow :)
[07:03] <mtaylor> vila: yay! (although you are assuming I will go to sleep at a reasonable time...)
[07:04] <mtaylor> vila: so I _might_ have it before I go to bed!
[07:04] <vila> mtaylor: now *you're* assuming I can produce them before you go to sleep :)
[07:05] <fullermd> Sleep?  Didn't we do that LAST week?
[07:14] <igc> hi vila. Thanks for the review. I'll take a look next week.
[07:14] <vila> igc: sure, enjoy your week-end, and remember that I like the overall direction, I just disagree on details :)
[07:16] <igc> vila. cool. today was lost fixing fast-import bugs and trying to get the groupcompress stuff working under usertest
[07:16] <vila> igc: and don't forget that failing test in usertest :-)
[07:17] <igc> vila: which one is that? can you email me the details please?
[07:17] <vila> I think I did in the past, but I'll mail a fresh one anyway :)
[07:18] <vila> log from bzrlib.plugins.usertest.tests.test_blackbox.BlackboxTests.test_usertest_strict
[07:18] <vila> with a ~440 line output totally opaque to me :-/
[07:19] <vila> igc: still there in revno 137
[08:12] <hno> Hmm.. 1.12 released but tarball not on launchpad?
[08:13] <hno> seems 1.12rc1 got uploaded again instead..
[08:33] <Youssef> Hi al!!!!
[08:39] <igc> night all - have a good weekend
[08:44] <LarstiQ> lifeless: it seems so
[09:23] <radix> is someone going to add bzrtools to the bzr PPA
[09:23] <radix> so that my update-manager stops telling me I need to do a partial upgrade
[09:24] <radix> (and so that I can upgrade bzr without removing bzrtools)
[09:45] <vila> radix: as soon as poolie fix the source upload, I'd build the ppas for both bzr and bzrtools
[09:45] <radix> vila: cool, thanks
[09:47] <vila> I jsut can't upload it myself being currently blocked by a failing test (apparently due to some weirdness in my install as ./bzr selftest bzrlib.tests.tree_implementations.test_path_content_summary.TestPathContentSummary.test_unicode_symlink_content_summary fails for both bzr.dev and bzr-1.12 >-/
[09:50]  * fullermd gets a failure there too.
[09:51] <fullermd> FAILED (errors=1, known_failure_count=2)
[09:51] <vila> let's kill a chicken, how can pqm left that pass ?
[09:54] <fullermd> I don't even know what it means  :p
[09:55] <vila> fullermd: what python version are you using ? What os version ? 32/64 bits ?
[09:55] <vila> it suceeds on hardy inside a 32 bits VM but failed on intrepid in 64 bits native
[09:56] <fullermd> 2.5.2 FreeBSD/i386
[09:56] <vila> 32 bits ?
[09:56] <fullermd> Yah.
[09:56]  * fullermd can't imagine word size has much to do with it though...
[09:56] <vila> Of course... just when I thought word size couldn't have anything to do with it you confirm that 32bit works :-(
[09:57] <fullermd> Hm?  It _fails_ for me.
[09:57] <vila> Oh ! Thanks
[09:58] <vila> do you have a python-2.4 handy ?
[09:58] <fullermd> It would take a lot of sit-around-and-compile.
[09:59] <vila> fullermd: nevermind, thanks anyway
[10:00] <vila> Urgh, python-2.5.2 disagree with itself about encondig strings between my two tests 8-(
[10:01] <fullermd> FWIW, 1.12rc1 out of the tarball "passes" (via SKIP'ing that test) on 2.5.2 FreeBSD/amd64
[10:01] <vila> 2.5.2 on hardy/32bits says: '\u03b2-path', where 2.5.2 on intrepid/64bits says: '\xce\xb2-path'
[10:02] <fullermd> Oh, wait, I've got LANG=C on that box...
[10:02] <fullermd> Yah, it fails there too with the UTF-8 locale.
[10:29] <UbuntuBoy> lol
[10:54] <Lo-lan-do> jelmer: I don't know if you committed the fix you mentioned earlier, but a bzr update I did just now took one minute and a half instead of the previous five minutes.  Thanks :-)
[10:59] <vila> jelmer: ping
[11:02] <UbuntuBoy> brb
[11:15] <nielsbom> (I'm a n00b), what's the correct way to stop having a simple local bzr repository?
[11:15] <nielsbom> I just deleted the .bzr dir, that worked, but seemed wrong
[11:15] <Kinnison> Depends what you mean
[11:16] <nielsbom> Can you elaborate?
[11:19] <Kinnison> Well, if all you wanted was to abandon your revision control then removing .bzr works
[11:19] <nielsbom> Kinnison: Yeah, that answers my question :)
[11:19] <Kinnison> If you wanted something with more complex semantics then it wasn't necessarily the right thing to have done
[11:19] <nielsbom> Kinnison: is there a bzr command for that?
[11:19] <nielsbom> Kinnison: or is just ok to rm .bzr?
[11:20] <Kinnison> personally I'd use bzr export to create a non-controlled copy
[11:20] <Kinnison> and then tar up and backup the version with the .bzr
[11:20] <Kinnison> but that's because I don't abandon revision control, if I can help it
[11:20] <fullermd> Me, I'd...   well, not do it in the first place   ;p
[11:21] <nielsbom> Kinnison: ok clear, thanks
[11:21] <Kinnison> sometimes I have to translate from one RCS to another, where importing the history isn't an option
[11:21] <glade88> what would be the equivalent of "svn update" in bzr? "bzr update" doesnt seem to do the same
[11:21] <glade88> ..neither "bzr upgrade"
[11:21] <fullermd> bzr update does the same thing svn update does.  That may not be quite what you want in a given case, though.
[11:21] <Kinnison> glade88: In a checkout, bzr update ought to work
[11:21] <fullermd> Perhaps you want 'bzr pull'.
[11:21] <Kinnison> glade88: in a branch, you may want bzr pull
[11:21] <Kinnison> snappish
[11:22] <glade88> it is a Launchpad branch.
[11:22] <glade88> bzr pull LP:ideatorrent ?
[11:22] <Kinnison> simply 'bzr pull' will pull from the last location IIRC
[11:24] <glade88> damn this "ssh passphrase". can I make it not to ask each time? "ssh add URL" doesnt seem to work for some reason..
[11:24] <glade88> URL=bzr+ssh://sayakb@bazaar.launchpad.net/~ideatorrent-developers/ideatorrent/devel/
[11:24] <glade88> ^in my case
[11:24]  * fullermd didn't know there WAS a 'ssh add'...
[11:24] <glade88> fullermd: any other way to save the passphrase?
[11:25] <Kinnison> do you mean your ssh password, or your ssh key passphrase?
[11:25] <fullermd> bzr doesn't have anything to do with that, TTBOMK.  That's all in your ssh client.
[11:25] <fullermd> Well, it has to be passphrase where LP is concerned.
[11:25] <fullermd> There's a ssh-agent or something like that.
[11:25] <glade88> its my ssh passohrase
[11:25] <glade88> and yes, bzr has nothing to do with that :)
[11:25] <Kinnison> ssh-add ~/.ssh/id_rsa
[11:25] <Kinnison> that kind of thing
[11:25] <glade88> since it is the same for svn
[11:27] <glade88> Kinnison: fullermd: thanks, bzr pull works. I'll pondermore on the passphrase thing.
[11:27] <glade88> cheerio
[11:28]  * Kinnison 's suggested ssh-add commandline is what glade88 wants
[11:28] <fullermd> Well, only once you have the agent running.
[11:28] <nielsbom> Just found this in the user guide (d'oh!): If you accidently put the wrong tree under version control, simply delete the .bzr directory.
[11:28] <fullermd> And you need that ancestrally to all your terminal creations (or manual hackery in each)
[11:29] <Kinnison> fullermd: typically, linux systems start ssh agents as part of the X session
[11:29] <Kinnison> fullermd: As for other systems, dunno :-(
[11:30]  * fullermd always has a hand-crafted .xinitrc, so nothing gets started he doesn't order  :p
[11:30] <glade88> Kinnison: w00t! yes, darn me I was using "ssh add" not "ssh-add". worksformenow (tm) . ty
[11:30] <Kinnison> fullermd: How retro :-)
[11:31] <fullermd> Oh, that's not retro.  What's retro is how the last line starts the window manager, ctwm  :p
[11:32] <Kinnison> Oh dear
[11:32]  * Kinnison pats fullermd gently on his clearly damaged head :-)
[11:32] <fullermd> But it's ctwm with a few of my own local hacks applied, of course.
[11:32] <fullermd> Sorta like the web browsing is firefox with my local hacks, and the mail reading is mutt with my local hacks, and...
[11:33]  * fullermd . o O ( If the world would just cater to me more, things would be so much easier... )
[11:38] <fullermd> Oh dear.  Somebody actually _likes_ $Log$?
[11:38] <vila> fullermd: some even likes log --forward :-)
[11:39] <fullermd> log --forward is almost as cool as missing --reverse!
[11:40] <vila> Don't start *me* on --reverse :-)
[11:40]  * fullermd reverses vila on --start.
[11:40] <vila> --start is good :-)
[11:40] <fullermd> Hey, we should add stat --backward, to show the merge revs in the opposite order, too.
[11:41] <fullermd> Then we'll cover the gamut better!
[11:43] <Kinnison> urf
[11:53] <UbuntuBoy> Hi guys!
[11:54] <UbuntuBoy> I would like to know how I can launch bazaar as windows service when i execute "BZR SERVE" please
[12:21] <nielsbom> (noob question) is it possible to co-develop a website using 2 computers which can't be connected through SSH (or something like it) using bzr? (Something like sending a whole repositorie as a file and merging it locally, and vice versa?)
[12:22] <Lo-lan-do> nielsbom: Yes, with merge requests sent by email.
[12:27] <santagada> actually  you can save a bundle to a file and transport it anyway you fell like it
[12:28] <santagada> for example a pen drive
[12:29] <Lo-lan-do> Yeah, or a floppy disk or a punched card.  I sort of assumed the two computers still had access to *some* net :-)
[13:10] <UbuntuBoy> Lo-lan-do!?
[13:11] <UbuntuBoy> I would like to know how I can launch bazaar as windows service when i execute "BZR SERVE" how can I do that please?
[13:11] <santagada> Lo-lan-do: you are not paranoid enough :)
[13:12] <Lo-lan-do> UbuntuBoy: I don't even know what a windows service is...
[13:12] <UbuntuBoy> lol
[13:12] <UbuntuBoy> a deamon i u want
[13:13] <UbuntuBoy> if
[13:13] <UbuntuBoy> sry
[13:13] <UbuntuBoy> a deamon if u want
[13:13] <santagada> UbuntuBoy: you know a service is not really a daemon right?
[13:13] <UbuntuBoy> :p
[13:13] <UbuntuBoy> yep
[13:14] <santagada> UbuntuBoy: so I'm guessing that if there is no service plugin and windows services are not mentioned on bazaar manual it is not supported
[13:14] <UbuntuBoy> mmmhhhhh...
[13:15] <santagada> UbuntuBoy: but maybe there is a way to use unix tools or something from microsoft to use a daemon as a service
[13:16] <santagada> UbuntuBoy: why not use IIS and fastcgi?
[13:16] <UbuntuBoy> because I prefer use directly bzr://
[13:17] <UbuntuBoy> its more easy
[13:18] <UbuntuBoy> it's sry
[13:20] <santagada> UbuntuBoy: I don't really agree... but ok
[13:20] <UbuntuBoy> :)
[13:20] <santagada> UbuntuBoy: use the unix daemon tools or unix tools that came with your windows server to do it
[13:21] <UbuntuBoy> unix daemon tools ?
[13:21] <santagada> UbuntuBoy: with IIS you can easily integrate with AD also
[13:21] <UbuntuBoy> I dunno
[13:21] <UbuntuBoy> how
[13:21] <santagada> UbuntuBoy: I think it is unix tools
[13:21] <santagada> daemon tools is that thing to run .iso images
[13:22] <santagada> UbuntuBoy: as an Ubuntu boy you probably know how to link LDAP and apache... with IIS is probably even easier to connect to AD for authentication
[13:22] <santagada> authorization will be left as an exercise :D
[13:22] <UbuntuBoy> hmmm
[13:23] <UbuntuBoy> hmm...
[13:23] <UbuntuBoy> i'm not really an ubuntyboy I took this nick becoz i didn't find anything else looooooooool
[13:24] <UbuntuBoy> or my name
[13:24] <Youssef> like this
[13:24] <Youssef> hihi
[13:24]  * Youssef put back his deguisment
[13:25] <santagada> Youssef was cooler
[13:25] <UbuntuBoy> Really?
[13:25] <UbuntuBoy> okay
[13:25] <Youssef> hihi
[13:26] <Youssef> ^^
[13:26] <Youssef> hmmm
[13:30] <santagada> Youssef: windows services for unix is deprecated I think, and don't do what you want
[13:30] <Youssef> about what?
[13:32] <Odd_Bloke> Youssef: I would suggest a post to the ML.
[13:33] <Youssef> ML?
[13:33] <Youssef> what is it?
[13:33] <Youssef> sorry guys im a windows user I try my best to learn the linux world
[13:33] <Youssef> it's a bit hard for me the please use full words
[13:34] <Youssef> not only those characters lol
[13:34] <Youssef> santagada! You said -> and don't do what you want <- what does it means?
[13:34] <Odd_Bloke> Youssef: Mailing List.
[13:34] <Youssef> loooooooooooooooool
[13:34] <Youssef> okay okay
[13:35] <Youssef> and why would you suggest me to post to the mailing list?
[13:35] <santagada> Youssef: I don't see a way to run a daemon as a service
[13:35] <Youssef> hhoo okay okay
[13:35] <santagada> Youssef: because them more people can see your question
[13:36] <santagada> Youssef: and can give you a more complete answer
[13:36] <Youssef> ooohhh
[13:36] <santagada> Youssef: or just because your question might become a feature request for a future version of bazaar :D
[13:36] <Youssef> okay
[13:36] <Youssef> mmhhhh...
[13:36] <santagada> Good luc
[13:36] <Youssef> interesting hehe
[13:36] <santagada> luck
[13:37] <Youssef> thankyou very much
[13:37] <Youssef> guys
[13:37] <Youssef> thanks a lot hehe
[13:37] <Youssef> but one last question
[13:37] <Youssef> where is the mailing list?
[13:40] <Odd_Bloke> Youssef: https://lists.ubuntu.com/mailman/listinfo/bazaar
[13:42] <nielsbom> Lo-lan-do: thanks!
[13:51] <xtian_> Can anyone tell me how to prevent bzr on windows from using plink for sftp (and get it to fall back to paramiko)?
[13:53] <xtian_> I can force it to fallback by renaming plink, but I need plink on my path to edit remote files in emacs.
[13:56] <xtian_> whoa, tumbleweeds, huh?
[13:57] <Lo-lan-do> And crickets.
[13:57] <Odd_Bloke> I don't know.
[13:57] <Odd_Bloke> And I can't think who here uses bzr on Windows.
[13:58] <xtian_> Fair enough! I might try the mailing list.
[13:58] <Odd_Bloke> Probably wise
[13:59] <xtian_> Cheers!
[14:03] <Tak> eh, I use bzr on windows, but not with sftp
[14:04] <xtian_> do you just use it with launchpad?
[14:08] <Tak> no, I use it with bzr-svn and smb
[14:20] <verterok> xtian_: try with set BZR_SSH=paramiko
[14:20] <xtian_> aha! Thanks!
[14:20] <xtian_> Trying now.
[14:21] <xtian_> Is there any reference where I could find that kind of thing in future?
[14:22] <xtian_> That worked! Thanks heaps.
[14:22] <verterok> xtian_: I found it the mail list archive, but I'm sure it's in the official docs
[14:23] <verterok> xtian_: if you can't find it in the official docs, please file a bug about it
[14:23] <xtian_> Wilco
[14:23] <xtian_> Just looking now
[14:24] <xtian_> Gah - there it is - I was looking for the wrong keywords. I could find mention of restoring auto-detection of plink in some bug threads, but not that.
[14:25] <xtian_> Thanks again!.
[14:26] <verterok> xtian_: np, glad to hlep
[14:29] <hno> Youssef: There is a tool in the windows resource kit for creating services of arbitrarily programs not having builting service capabilities.
[14:33] <Kinnison> What's the status of tracking cherrypicks in bzr?
[14:43] <vila> verterok: that was short :-)
[14:43] <verterok_> vila: me netwokr is flaky, hopefully be back at home during the weekend :)
[14:44] <verterok_> /me/my
[14:44] <vila> s!/me/my!s/me/my/! :-)
[14:45] <verterok> :)
[14:45] <Odd_Bloke> s,s!/me/my!s/me/my/! :-),s!/me/my!s/me/my/!,
[14:45] <Odd_Bloke> :)
[14:45]  * fullermd hopes you don't try that in csh...
[14:51] <yenzenz> hi
[14:52] <Odd_Bloke> yenzenz: Hi. :)
[14:52] <yenzenz> is this a known issue: download link to tgz of 1.12 release is broken at http://bazaar-vcs.org/Download
[14:53] <Odd_Bloke> yenzenz: I wasn't aware of it.
[14:53] <fullermd> Yes, it's known.
[14:54] <yenzenz> fullermd: ok, thnaks. so just a matter of time :)
[14:54] <nielsbom> {noob} I start a local repository on my pc (bzr init, bzr add, bzr commit), then I want to send the whole branch including all files to a colleague so he can start development on his own pc and then send patches my way. How do I export my whole dir, incl repository to him? Should I do that with bzr? Or just copy it?
[14:55] <Lo-lan-do> You can copy the .bzr dir
[14:56] <nielsbom> Lo-lan-do: yes, I understand that, and also copy all the files in the dir in which my files reside.
[14:57] <Lo-lan-do> You don't *need* to copy those, since they can be regenerated from the .bzr dir.
[14:58] <nielsbom> Even if he hasn't had the repo before?
[14:59] <Lo-lan-do> The .bzr dir contains the full history.  So he can just bzr reconfigure --tree and get the working files from that.
[14:59] <Lo-lan-do> (Or just bzr checkout)
[15:00] <fullermd> Well, if you send the .bzr from a dir with a checkout, you'd use revert...
[15:00] <jelmer> vila: hi
[15:01] <vila> jelmer: hi
[15:01] <vila> jelmer: did you see my mail about 1.12
[15:01] <vila> jelmer: did you see my mail about 1.12  ?
[15:01] <jelmer> vila: Yeah
[15:01] <jelmer> vila: Strange it's failing for you :-/ Does it fail both with dirstate C extensions and without?
[15:02] <vila> It fails *with* C extensions
[15:02] <jelmer> does it work without?
[15:02] <vila> let me check
[15:04] <fullermd> It works for me without, and fails with.
[15:04] <vila> works without
[15:04] <vila> ...
[15:04] <vila> gha...
[15:05] <nielsbom> Lo-lan-do: ok, I'm starting to understand, I think (we're testing it now)
[15:05] <Lo-lan-do> nielsbom: Maybe you could use the bzr-fast-export.py script from plugins/fastimport if you don't feel comfortable copying a .bzr dir.
[15:06] <vila> jelmer: does it make sense to you ?
[15:06] <jelmer> vila: Not entirely yet, but at least more
[15:06] <nielsbom> Lo-lan-do: I'm ok with that for starters
[15:08] <vila> jelmer: with my patch, that's the opposite, fail without extensions, works with
[15:11] <nielsbom> Lo-lan-do: So I have a local repository, I committed to it, then I copy the .bzr directory to another directory, say example/. I then go to that dir and give the command bzr reconfigure --tree. I get the error "example is already a tree"
[15:12] <nielsbom> Lo-lan-do: "example/ is already a tree
[15:12] <jelmer> vila; Looks like there's an inconsistency in dirstate C extensions / Python
[15:12] <Lo-lan-do> nielsbom: Try "bzr revert" instead.  Apparently the .bzr contains info on what's supposed to be outside itself :-)
[15:15] <vila> jelmer: yup, we need more tests parametrized on C extension availability or not
[15:15] <jelmer> vila, i.e. one already provides unicode, the other provides ascii
[15:17] <nielsbom> Lo-lan-do: cool, that worked thanks!
[15:17] <vila> What are the consequences if we revert your patch ? Is bzr-svn impacted ?
[15:18] <jelmer> vila: No, bzr-svn is not impacted, but some repositories will be impacted (as it'll break symlinks with unicode names)
[15:19] <jelmer> vila, Do you really need to revert it though? Only newly added tests seem to fail
[15:20] <vila> jelmer: well, I came across it just before a release... I don't think it should block it, but that's for the RM to decide...
[15:21] <vila> jelmer: plus, it fails only under unclear circumstances...
[15:21] <vila> jam: ping
[15:21] <jelmer> vila: I mean, the alternative would be to just remove the tests added by my patch
[15:21] <jam> hi vila
[15:21] <vila> untested code is broken code :-)
[15:22] <jelmer> vila, well, that seems to be what's breaking for you
[15:23] <vila> jelmer: Only because I came across it via the test but I presume I can reproduce it from command line, so our users can too
[15:25] <jelmer> vila: this was already broken from the command-line
[15:25] <jelmer> my patch was meant to address it
[15:25] <vila> jelmer: I understand that, don't get me wrong.
[15:26] <vila> But it the fix seems incomplete then, even if you can't trigger it yourself (or so it seems) because, well, your setup is different
[15:26] <vila> I can't reproduce it either under hardy/32bits inside a VM,
[15:27] <vila> I reproduce it only under intrepid/64bits on a real host
[15:27] <vila> Same python version: 2.5.2
[15:27] <vila> I fail to understand why the word size has an impact though....
[15:28] <jelmer> I'll see if I can reproduce on my 64bit machine
[15:28] <jelmer> it seems strange indeed that the word size would affect the type of a field in dirstate..
[15:30] <fullermd> It happens for me on i386 and amd64 both.
[15:32] <jam> fullermd: are you on BSD?
[15:32]  * jam seems to remember that BSD has different ideas about fs_enc
[15:33] <fullermd> What's the thing that makes bzr spit its fs_enc out?
[15:35] <jam> fullermd: um... python -c 'import bzrlib.osutils; print bzrlib.osutils._fs_enc" ?
[15:36] <jelmer> the problem seems to be that the dirstate C extensions call _read_link() with a str argument
[15:36] <jelmer> and the native Python code calls it with a unicode argument
[15:36] <fullermd> UTF-8
[15:36] <jam> so the dirstate code should be using a UTF-8 string (always), which is probably incorrect on some situations
[15:36] <fullermd> I note that (if it matters) it's the (PreviewTreePost) variant that fails.  (DirStateRevisionTree) and the other options work.
[15:37] <fullermd> Well.  I assume pass == work.
[15:37] <jelmer> jam: the dirstate code should always use unicode internally?
[15:37] <jelmer> s/unicode/utf8
[15:39] <jam> jelmer: generally, yes
[15:39] <jam> The paths stored *in* the dirstate file should all be utf-8
[15:39] <jam> And 90% of all processing is done via utf-8 strings
[15:40] <jam> only when finally yielding them to upper layers do we decode it back to Unicode
[15:40] <jelmer> and when reading from the OS encoding as _fs_enc?
[15:41] <jam> jelmer: right
[15:41] <LarstiQ> evening
[15:41] <jam> hi LarstiQ
[15:41] <jam> beuno: ping
[15:41] <LarstiQ> hey jam
[15:44] <jelmer> Hey LarstiQ
[15:44] <jelmer> hi emmajane
[15:44] <LarstiQ> hi jelmer, emmajane :)
[15:44] <emmajane> jelmer, hello :)
[15:44] <emmajane> LarstiQ, hello as well
[15:44] <jelmer> emmajane, thanks for the report wrt the docs on samba.org, btw
[15:44] <emmajane> jelmer, no problem.
[15:45] <emmajane> jelmer, I wasn't sure if it was meant to work with local files, but not online. Or something.
[15:46] <jelmer> emmajane, it's supposed to work, but seems to break from time to time as it's updated automatically
[15:46] <emmajane> heh. Yeah. There's 'supposed to' and then there's 'output from scripts' :)
[15:47] <jam> Does anyone else know if 'loggerhead' is fully plugin-ized now?
[15:48] <LarstiQ> jam: yes, fsvo fullu
[15:48] <jam> well, is "bundling it with the win32 installer" going to work
[15:48] <LarstiQ> jam: I don't think it does the fancy decorating of 'bzr serve' yet
[15:48] <jam> I guess is the question
[15:48] <jelmer> emmajane, :-)
[15:48] <LarstiQ> jam: ooh, goed question.
[15:48] <jam> I think it will take a few steps
[15:48] <jam> as it would also require extra dependencies
[15:48] <jam> like we have to do with bzr-svn, etc.
[15:48] <jam> I think I need to put together a spec
[15:48] <jam> for handling setup issues with bundling plugins
[15:49]  * LarstiQ cries as selftest slows his netbook to a crawl
[15:49] <jam> as I'm tired of having to edit bzr's setup.py for each plugin
[15:49] <jelmer> vila, jam: So the problem seems to be that py_update_entry() calls _read_link() with a unicode string
[15:49] <jelmer> vila, jam: Whereas the C extensions call it with a utf8 string
[15:51] <jam> hmm... something odd here
[15:51] <jam> as the C extension just passes through the "abspath" it was given
[15:51] <jam> which is also what "py_update_entry" does
[15:52] <jam> So I'm guessing it isn't the 'update_entry' code
[15:52] <jam> but the _process_entry code
[15:52] <jam> which is getting something wrong
[15:57] <emmajane> And now for something completely different: an on-topic comment! :)
[15:57] <emmajane> Next weekend I'm giving a bzr talk at SCaLE. I'm giving essentially the same talk as I gave before.
[15:58] <beuno> jam, pong
[15:58] <emmajane> The slides are at: http://www.slideshare.net/emmajane/version-control-for-mere-and-freelance-mortals-presentation if anyone has comments for add/modify/deletes.
[15:58] <jam> beuno: on bug #328860, Martin mentions wanting to bundle loggerhead with the win32 installer
[15:58] <jam> I was just curious if loggerhead has been fully turned into a "plugin"
[15:58] <emmajane> The talk description is at: http://scale7x.socallinuxexpo.org/conference-info/speakers/emma-jane-hogbin (It's just an intro talk)
[15:59] <jam> so that it would be bundled in the same fashion that bzr-svn, etc. would be
[16:00] <beuno> jam, poolie actually did turn it into a plugin during our sprint
[16:00] <beuno> let me find the merge proposal..
[16:01] <beuno> https://code.edge.launchpad.net/~loggerhead-team/loggerhead/loggerhead-plugin/+merge/3095
[16:01] <beuno> jam, ^
[16:01] <beuno> I'll merge that in today
[16:02] <jam> beuno: well, I won't change anything for 1.12
[16:02] <jam> just thought I'd check where things were at
[16:02] <jam> Does that also decorate "bzr serve" ? Or is it just "bzr loggerhead-commands"?
[16:02] <beuno> it decorates serve
[16:02] <beuno> which is what prompted jml's work on it
[16:06] <jelmer> emmajane, do you have some other format than flash? gnash is not cooperating with me atm
[16:06] <fullermd> Ooh look, a 1.12 tarball...
[16:07] <emmajane> jelmer, is there an option to download the ODP from that page?
[16:08] <emmajane> http://www.slideshare.net/emmajane/version-control-for-mere-and-freelance-mortals-presentation/download ?
[16:08] <emmajane> it gives a PDF, I think.
[16:08] <Lo-lan-do> beuno: Will you also merge the init script for daemon-like operation?
[16:09] <jelmer> emmajane, that seems to require login :-/
[16:09] <Lo-lan-do> (You did ask me to pester you :-)
[16:09]  * fullermd keeps waiting for the day flash joins java applets in the dustbin...
[16:09] <emmajane> jelmer, boo to slideshare.
[16:09] <beuno> Lo-lan-do, I may put up a merge proposal for someone with a working brain to review  :)
[16:09] <jelmer> beuno, and will you remove start-loggerhead ? (-:
[16:10] <beuno> jelmer, not until I get config working with serve-branches  :/
[16:11] <emmajane> jelmer, http://bazaar-vcs.org/Talks?action=AttachFile&do=get&target=bzr-intro-template.odp
[16:11] <jelmer> emmajane, thanks
[16:11] <emmajane> jelmer, thanks for looking! :)
[16:13] <fullermd> Things you notice when updating packages:
[16:13] <fullermd> bzrtools 1.12.0 is 1 'larger' than bzrtools 1.11.0.  Thus, it's fitting that the tarball is also 1 byte larger.
[16:13] <jam> a single byte, that is quite intriguing
[16:14] <Lo-lan-do> "Well, it's one louder, innit?"
[16:14] <fullermd> But why not make each byte bigger?
[16:14]  * fullermd nods at jam.
[16:14] <fullermd> I thought so.
[16:14] <fullermd> -SIZE (bzrtools-1.11.0.tar.gz) = 69765
[16:14] <fullermd> +SIZE (bzrtools-1.12.0.tar.gz) = 69766
[16:15] <jam> well, also of interest:
[16:15] <jam> 3.8M Feb  9 04:42 bzr-1.11.tar.gz
[16:15] <jam> 3.9M Feb 13 09:53 bzr-1.12.tar.gz
[16:15] <jam> 1 (100kB) bigger
[16:16] <fullermd> Well, not really.  It's 39807 bigger.
[16:17] <Odd_Bloke> s/bigg/loud/
[16:19] <fullermd> Of course, if you subtract that from the curent bzrtools, you get 29959.  Subtrace that from the previous bzrtools, you get 9848.
[16:19] <Toksyuryel> Would Stackless provide any measurable speed improvements to bzr?
[16:19] <fullermd> Sum those digits, you get 29, which starts the pattern.  The next digit is the 9 again from the start of 9848.  The 59 is one more than the trailing 48.
[16:19] <fullermd> So it all works out anyway.
[16:20]  * fullermd wanders off to smoke some more crack...
[16:20] <Toksyuryel> seems to have done a lot for EVE Online, am wondering if bzr can achive similar performance gains
[16:21] <Toksyuryel> http://en.wikipedia.org/wiki/Stackless_Python
[16:23] <Odd_Bloke> Toksyuryel: Without really knowing anything more, I would note that EVE and bzr are fairly different apps. ;)
[16:23] <Toksyuryel> Granted, but still :)
[16:23] <jelmer> emmajane: seems good to me :-) simple, and quick
[16:23] <Odd_Bloke> Essentially, I doubt it, because bzr isn't multi-threaded.
[16:23] <jfroy> Morning!
[16:24] <jelmer> emmajane, why does "bzr tags --sort=time" need special attention? The other commands mentioned seem much more common
[16:24] <jelmer> hi jfroy !
[16:24] <Toksyuryel> Is threading planned for a future development?
[16:24] <Odd_Bloke> Toksyuryel: I don't know.
[16:24] <emmajane> jelmer, it's just one that I use a lot myself (tagging what versions I send to the client). I talk a bit about it.
[16:25] <Toksyuryel> Perhaps implimenting threading and moving to stackless coule provide performance improvements over the current model?
[16:25] <Toksyuryel> *could
[16:25] <fullermd> I would tend to doubt it, certainly in the near or mid term.
[16:25] <jfroy> jelmer: congrats on 0.5 final
[16:25] <emmajane> jelmer, thanks for taking a look. Much appreciated.
[16:26] <Toksyuryel> fullermd: I see
[16:27] <jelmer> Toksyuryel, what would the benefit of threading be exactly?
[16:28] <Toksyuryel> potential speed increases? I'm just wondering and asking. someone's gotta actually answer the question with "yes that would make it faster" or "no it would not make it faster" :D
[16:29] <jam> Toksyuryel: currently I think our big bottlenecks are stuff like graph walking
[16:29] <jam> it is pretty hard to come up with efficient walking code
[16:29] <jam> and even harder to do something that is also parrallel
[16:29] <jam> One possible place would be text insertion, I guess
[16:29] <Toksyuryel> like I said... I am just asking. I am not saying "this would definitely be faster and you should do it right now".
[16:30] <jam> if you are trying to insert 100 different texts, you could probably farm a couple of those out to different threads
[16:30] <Toksyuryel> please stop trying to spin my words to your own ends :)
[16:30] <Toksyuryel> I understand that it's not a high priority compared to other things which need to be done
[16:31] <santagada> jam: sorry to botther you but isn't this kind of stuff io bound?
[16:31] <jam> santagada: some is, some is 'diff' bound
[16:31] <fullermd> I expect the place we're most likely to pick up parallelism would be from python-level stuff, really.
[16:31] <jam> stuff like 'annotate' could benefit
[16:32] <fullermd> e.g., list comprehensions are inherently parallelizable.
[16:32] <jelmer> Toksyuryel: You're talking about specifics, parallelism can be achieved through more than just threading
[16:42] <jfroy> I was just asked by a friend if bzr had an equivalent to git add -p. He tells me it lets you commit a subset of all the changes in the branch, even from the same file. I've never done that in bzr, so I'm not sure.
[16:43] <fullermd> You can specify files, you can use shelve to set aside bits before you commit, or...   I think somebody wrote a plugin to do a darcs-style record?
[16:43] <fullermd> (I don't know if/how well it works)
[16:45] <Odd_Bloke> jfroy: Yeah, shelve is probably what he's looking for.
[16:46] <Odd_Bloke> You use it put some of your changes on the 'shelf', commit, then use unshelve to pull them back off.
[16:46] <Odd_Bloke> It has the advantage of allowing you to confirm that you haven't broken anything with the subset of changes you're committing before you commit them.
[16:46] <jam> jfroy: it is sort of the "inverse" of add -p, in that you are taking off things you don't want to commit, rather than explicitly listing the things *to* commit
[16:46] <jam> however, it leaves the tree in a state that you can run "make test" on
[16:46] <jam> which is generally beneficial
[16:49] <lbieber> Can someone tell me how to modify the 1200 second timeout limit in bzr? I'm experiencing a problem on several of our machines where they occasionally time out, not sure if it is because they are behind a firewall or not
[16:50] <jfroy> Thank you all.
[16:50] <LarstiQ> lbieber: do you have a .bzr.log of when that happens?
[16:51] <lbieber> LarstiQ:  one minute let me see if I can dig it up
[16:52] <jam> lbieber: you can set bzrlib.lockdir._DEFAULT_TIMEOUT_SECONDS
[16:52] <jam> though if you are hitting that
[16:52] <jam> (default is 5 min)
[16:52] <jam> I'm guessing it is something else.
[16:52] <lbieber> LarstiQ: ummmm, where would I find .bzr.log, I'm not seeing it anywhere?
[16:53] <jam> ~/.bzr.log
[16:53] <jam> Or if on windows $My Documents/.bzr.log
[16:53] <jam> bzr --version spells it out for you
[16:57] <lbieber> ahhhh -  let me fix this first and see if it helps, from the log file - 0.120  WARNING: using slower ElementTree; consider installing cElementTree and make sure it's on your PYTHONPATH
[16:58] <Myrtti> I was wondering if http://paste.ubuntu.com/117733/ this is an error of bzr, launchpad or me?
[16:59] <Odd_Bloke> Myrtti: That looks like a bzr problem.  Is there any chance you could try with a newer version of bzr?
[17:00] <jam> Myrtti: that is a known bug with bzr 1.6.1 when using -Dhpss
[17:00] <jam> what bug happened that caused you to try and use -Dhpss
[17:00] <jam> as that is the real issue
[17:01] <jam> (that said, if you upgrade your bzr, it probably all goes away anyway)
[17:02] <Myrtti> what I did was I removed some of the launchpad projects and tried to rebranch them
[17:02] <Myrtti> bzr pull worked while the launchpad project working copies were there
[17:03] <Myrtti> but now http://paste.ubuntu.com/117739/
[17:05] <jam> so that looks more like you don't have you ssh keys set up properly
[17:05] <jam> it may have been working before because you didn't do "bzr launchpad-login"
[17:05] <jam> (so we were using anonymous http access, rather than authenticated bzr+ssh access)
[17:06] <Odd_Bloke> Myrtti: OK, so you probably did the inital lp:foo branch before running 'bzr launchpad-login'.  So the branches had the http:// location stored (because currently we store the resolved URL, not just the 'lp:foo' bit).  Then you ran launchpad-login, and it's now trying to use bzr+ssh.  But you haven't set up SSH keys with Launchpad.
[17:06] <Myrtti> well that's funny, because it gave me that even before I had logged in
[17:06] <Myrtti> and now that there is a proper ssh key at launchpad, it still doesn't work.
[17:07] <Myrtti> or that's what I think
[17:07] <Odd_Bloke> Myrtti: What does 'ssh <username>@bazaar.launchpad.net' give you?
[17:08] <Myrtti> Agent admitted failure to sign using the key.
[17:08] <Myrtti> Permission denied (publickey).
[17:08] <jpds> Ah, the seahorse-agent bug.

[17:11] <jpds> bug 328127
[17:12] <Myrtti> that's funny
[17:12] <Myrtti> I'm on intrepid.
[17:12] <Myrtti> >___<
[17:13] <jpds> So am I, I have the same problem :/
[17:13]  * Myrtti checks
[17:14] <Myrtti> gnome-keyring: Installed: 2.24.1-0ubuntu1
[17:15] <jpds> Really odd.
[17:15] <Myrtti> I'm on xfce4 though
[17:16] <Myrtti> and I know about these things about as much as my guinea pigs know about particle physics
[17:19] <Odd_Bloke> Myrtti: Try "SSH_AUTH_SOCK= ssh <username>@bazaar.launchpad.net".
[17:19] <Myrtti> and presto it works
[17:22] <Myrtti> Odd_Bloke: thanks
[17:23] <LarstiQ> abentley: from the standup reports you're not yet in nested territory?
[17:23] <abentley> LarstiQ: No.  Hopefully next week.
[17:25] <Odd_Bloke> Myrtti: :)
[17:25] <Odd_Bloke> Myrtti: Adding a comment on the bug with your version details might be helpful. :)
[17:26] <LarstiQ> abentley: k, I'm paging through a full test suite run log now, deferring most things for later, almost got myself convinced to commit/push the current status
[17:26] <abentley> LarstiQ: Great.
[17:28] <Myrtti> Odd_Bloke: done :-) thanks
[17:29] <pickscrape1> Is bzr-1.12 compatible with bzr-loom 1.4?
[17:30] <pickscrape1> I'm getting this when running bzr status: bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose'
[17:31] <pickscrape1> The backtrace refers to /usr/lib/python2.5/site-packages/bzrlib/plugins/loom/commands.py
[17:31] <Odd_Bloke> pickscrape1: Could you pastebin a more complete error?
[17:31] <pickscrape1> sure
[17:31] <pickscrape1> Is there one for this channel, or should I just paste anywhere?
[17:32] <LarstiQ> any pastebin works
[17:33] <pickscrape1> http://pastebin.ca/1336235
[17:33] <vila> pickscrape1: try updating your plugin I'm pretty sure it has been fixed on trunk
[17:33] <pickscrape1> I was running it direct from apt... I'll uninstall that and grab it manually
[17:33] <vila> pickscrape1: yup, seeing the traceback I'm even more sure :)
[17:35] <pickscrape1> Is bzr-loom available in a PPA anywhere?
[17:36] <vila> I don't  think so
[17:36] <vila> Do you get 1.12 from bzr-ppa ?
[17:36] <vila> Did you get 1.12 from bzr-ppa ?
[17:36] <pickscrape1> vila: yes
[17:36] <vila> pickscrape1: did you get bzrtools too ?
[17:37] <pickscrape1> I had to uninstall bzrtools because 1.11 was never uploaded to the PPA, so currently I have that installed manually
[17:38] <vila> pickscrape1: could you try to install bzrtools from bzr-ppa ?
[17:38] <pickscrape1> vila: yes, I will once I've fixed etckeeper, which has also just started complaining :)
[17:38] <vila> pickscrape1: argh, no wait, the builds aren't finished yet :-/
[17:40] <pickscrape1> OK, using loom trunk has fixed the problem: thanks :)
[17:40] <pickscrape1> etckeeper needed BZR_COMMIT_OPTIONS="--unchanged"
[18:11] <LarstiQ> woops, unlocking other_tree once too many
[18:36] <vila> pickscrape1: bzrtools-1.12 available in bzr-ppa, can you try it ?
[18:37] <pickscrape1> vila: I just did, and it seems to work fine :)
[18:37] <pickscrape1> Thanks for your help
[18:37] <vila> pickscrape1: great, thanks for your test :)
[18:37] <vila> pickscrape1: which os/version/arch are you using ?
[18:38] <pickscrape1> vila: jaunty amd64 and intrepid x86 (tested on both)
[18:39] <vila> pickscrape1: you're my man, two birds with one stone :)
[18:39] <pickscrape1> :)
[19:23] <jfroy|work> jelmer: I was wondering if you had some experience to share with setting up bi-directional bzr-svn syncing.
[19:55] <ronny> jelmer: sup?
[19:57] <jfroy|work> ronny: I believe he's away ATM.
[19:58] <ronny> hmm
[19:58] <ronny> -9 to 1234554321 ( 1234554330 19:45:30 UTC )
[19:58] <ronny> [20:45]        MinceR | A4Tech: no u
[19:58] <ronny> ops
[19:58] <ronny> touchpads + broken syndaemon are hellish
[20:02] <Lo-lan-do> jfroy|work: I'm usung bzr-svn, maybe I can be of help?
[20:04] <jfroy|work> Lo-lan-do: ok, so here's the use case. Project A is hosted in a Subversion repository over which I have little or no control. I want to introduce a Bazaar bridge, of sort, to allow some developers to use Bazaar as their main VCS. However, it is likely some other will continue using Subversion.
[20:04] <jfroy|work> I'm only interested in syncing one branch, the trunk,
[20:05] <jam> vila: ping
[20:05] <jfroy|work> That is, the Subversion trunk with a Bazaar branch, from which Bazaar-using developers would pull and push from.
[20:05] <miracle2k> when I init-repo after I already have branches checked out, can I make them part of the repository, or they I need to re-clone?
[20:05] <jam> miracle2k: check 'bzr reconfigure' I think it has some flags for that
[20:06] <Lo-lan-do> jfroy|work: I think it's simpler for everyone if people just use bzr as a Subversion client then.
[20:06] <jam> jfroy|work: I believe doing:
[20:06] <jfroy|work> miracle2k: AFAIK you need to branch into the repo to get the branch to store its history data in it
[20:06] <jam> bzr co svn+ssh://path/to/trunk
[20:06] <jam> Should "just work"
[20:06] <jam> as in, the developers can commit there, and it will update the subversion trunk
[20:07] <Lo-lan-do> That's exactly what I'm doing, and it seems to works well.
[20:07] <jfroy|work> Lo-lan-do: I see. So each developer would maintain their own Subversion trunk checkout.
[20:07] <miracle2k> jam, jfroy|work: There's a reconfigure --use-shared which I'm gonna try. Thanks.
[20:07] <jfroy|work> miracle2k: ah, good to know, didn't know that existed :)
[20:07] <jfroy|work> jam: thanks for the tip
[20:07] <jam> jfroy|work: it is certainly the easiest way
[20:07] <jam> there are always others
[20:07] <jam> you can also
[20:07] <jam> cd my-local-trunk
[20:08] <jam> bzr pull ../my-branch
[20:08] <jam> and if that succeeds (branches aren't diverged)
[20:08] <jam> it should be the same as doing "bzr push svn://...."
[20:35] <pickscrape1> Was a release email sent out for 1.12?
[20:42] <jam> pickscrape1: I don't think so
[20:43] <jam> Or it was sent, but Martin forgot to approve his email
[20:43] <jam> Let me check
[20:43] <pickscrape1> I just enjoy reading the release notes is all :)
[21:08] <jam> pickscrape1: http://doc.bazaar-vcs.org/bzr.1.12/en/release-notes/NEWS.html#bzr-1-12-1234567890-2009-02-13
[21:08] <jam> Or to see the on-going one: http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html
[21:08] <pickscrape1> jam: thanks
[21:28] <jam> lifeless: to your earlier question, "groups" do not get +junk branches:
[21:28] <jam> bzr: ERROR: Permission denied: "/~bzr/+junk/bzr-groupcompress": : +junk branches are only available for individuals. Please consider registering a project for collaborating on branches: https://help.launchpad.net/Projects/Registering
[21:29] <zsquareplusc> bzr 1.12 and olive? i get errors on my ubuntu box. for example the log windows are shown, but the log itself is never shown
[21:30] <jam> as such, I went ahead and created: https://edge.launchpad.net/bzr-groupcompress
[21:31] <jam> since I needed to do a couple patches to the plugin
[22:44] <jelmer> ronny: hi
[22:44] <jelmer> jfroy|work: hi
[22:45] <jfroy|work> hey
[22:45] <jfroy|work> As you can read in your history, my question was mostly answered, unless you have something to add to Lo-lan-do's recommendation.
[22:54] <jelmer> jfroy|work: ah, sorry, hadn't seen that
[22:54] <jelmer> jfroy|work: yeah, his answer seems to cover it all - just pretend the svn branch is a bzr branch and all should be well
[22:55] <ronny> re
[22:56] <jfroy|work> jelmer: just need to make sure the other developers who wish to use bzr understand they really need to not use a bound branch for daily work, because operations on that branch will be *slow*.
[22:56] <jfroy|work> Your standard "train them a bit" situation, I suppose.
[22:58] <ronny> jelmer: im at the final point of vcs unhappyness, all reasonable vcs's have at least one major pain point i dont want to be brothered with
[23:16] <jelmer> jfroy|work: just tell them to use 0.5.1, which will be lightning-fast
[23:16] <jelmer> ronny: yeah, it's tricky to get right :-/ a task-specific API is probably easier than a generic one like anyvc
[23:17] <ronny> jelmer: nah, also all common vcs's have at least one fail that makes me hate them
[23:23] <jfroy|work> jelmer: is that so?
[23:24] <jfroy|work> (this is a worst case scenario, the svn server is still 1.4 with no plan to upgrade to 1.5 anytime soon :p )
[23:41] <sri> so..
[23:41] <sri> is there a irc hannel for paramiko?