[00:01] <igc> morning
[00:02] <jam> morning igc
[00:23] <jam> lifeless: you're going to make the bzr.1.5 branch today, right?
[00:31] <lifeless> http://laserjock.wordpress.com/2008/05/08/git-and-bzr-historical-performance-comparison/
[02:32] <mlh> found it  .. http://svn.blastwave.org/trac
[02:33] <mlh> oops
[03:40]  * igc food
[04:07] <lamalex> Hi everyone, how do I commit only a single file so that bzr send will generate a patch for only 1 file
[04:08] <lifeless> bzr commit FILENAME
[04:08] <lamalex> bzr: ERROR: Selected-file commit of merges is not supported yet: files Do.Addins/src/Do.Universe/ApplicationItem.c
[04:08] <RAOF> lamalex: Yup, this was where I was about to suggest ;)
[04:08] <lifeless> this smeans you have done a merge, but not committed the result
[04:10] <lamalex> so solution?
[04:10] <lamalex> commit
[04:10] <lamalex> :P
[04:10] <RAOF> The shelf plugin can be your friend here.
[04:10] <lifeless> do the commit
[04:10] <lifeless> if the branch you are merging is your upstream send won't include changes from the upstream in the sent content anyway
[04:12] <lamalex> thanks guys
[04:13] <lamalex> oh jeeze! So I did a commit on just the one file after, and bzr send still generated a patch for /all/ changed files
[04:17] <lamalex> any idea how to only generate the patch for the 1 file?
[04:21] <jamesh> "bzr diff" will give you a diff for one file
[04:21] <jamesh> but if you want "bzr send" to give you a bundle for one file, then the bundled revisions need to have changed just the one file
[04:21] <jamesh> (relative to the submission branch)
[04:23] <lamalex> so I'm SOL for bzr send, and should just diff it
[04:23] <lamalex> and advantage of using bzr diff over gnu diff?
[04:23] <jamesh> well, you can always prepare the change in a new branch
[04:23] <lamalex> ignore my previous question
[04:31] <lifeless> lamalex: bzr send -r x..y will probably do what you want
[04:31] <lifeless> lamalex: it sounds like you want to send in one commit, not all of your work
[04:31] <lamalex> yeah
[04:31] <lifeless> lamalex: this is the usual confusion that I have seen
[04:31] <lamalex> I've had the problem a few times :P
[04:31] <lamalex> I always forget how to do it
[04:31] <lamalex> wrote it down this time
[04:32] <lifeless> lamalex: the name for doing this, irrespective of transport (branch/bundle/patch) is 'cherrypicking'
[04:33] <lamalex> thanks
[04:42] <lamalex> lifeless: still no luck, I'll just do a diff
[04:43] <jsled> lamalex: What's wrong with `bzr diff path/to/file`?
[04:44] <lamalex> I was under the impression that bundles were better
[04:44] <jsled> nevermind; didn't read enough scrollback.
[04:44] <lamalex> :)
[04:47] <lifeless> lamalex: you probably have more than just one file changed; or are nto using the correct arguments - the list had a good discussion about bzr send just this week
[04:47] <lamalex> I'll check it out, thanks for your help
[04:47] <lifeless> I'm happy to debug futher if you like; remember though that send's finest granularity is a single commit
[04:49] <lamalex> I have to go to bed soon, I have a sociology final in the morning
[04:50] <lifeless> go then !
[04:51] <lamalex> :) I've still got 9 hours!
[04:52] <lamalex> well, I guess 6:30 of sleep, but that's plenty. Thanks for the help.
[05:10] <ferringb> curious, for a bzr-svn branch, is there way to effectively convert that into a standalone bzr branch- specifically, converting it to a knit repository?
[05:13] <lifeless> bzr-svn branches are native bzr branches
[05:13] <lifeless> bzr info will tell yo the current format
[05:19] <ferringb> lifeless: branched from the svn branch to a "Standalone tree (format: rich-root)"
[05:20] <ferringb> from there, trying to branch from the standalone into a shared repository (pack-0.92), but getting no love; error msg is essentially "knit pack repository is not compatible with knit repository"
[05:22] <ferringb> so... something there isn't right. :)
[05:22] <ferringb> (attempts to upgrade the svn branch fail also)
[05:23] <Peng> You can't go from a rich-root format (rich-root, rich-root-pack) to a non-rich-root format like pack-0.92.
[05:24] <Peng> If you want to upgrade to packs, "bzr upgrade --rich-root-pack".
[05:24] <ferringb> bingo
[05:24] <ferringb> Peng: that's working for the svn branch; from there, probably will fly for pulling it into my shared repo
[05:25] <ferringb> what is a 'rich root pack' anyways?  just a new format, or
[05:26] <Peng> ferringb: rich-root-pack is like pack-0.92, only it has rich roots, meaning it stores slightly more meta data.
[05:26] <Peng> ferringb: rich-root is like dirstate-tags, only it has rich roots.
[05:33] <lifeless> ferringb: as peng says, rich-root stores more data; you can't go back to a plain repo from there
[05:33] <lifeless> ferringb: we will very shortly (probably 1.6 I think) be making rich root our default format
[05:33] <lifeless> abentley: around ?
[05:34] <abentley> lifeless: Hi.
[05:34] <lifeless> any chance of a brief skype call?
[05:34] <abentley> Sure.  I'm just finishing up something with thumper.
[05:35] <lifeless> 5 minutes?
[05:36] <abentley> Sure.
[05:42] <abentley> I couldn't hear you.
[06:28] <lifeless> k, thats my work day done; later all
[06:28] <lifeless> thanks abentley
[06:28] <abentley> lifeless: np
[06:34] <jamesh> the "if self.new_inventory_root is None" branch in CommitBuilder.finish_inventory() (bzrlib/repository.py) looks broken
[06:34] <jamesh> AssertionError doesn't take a "stacklevel" keyword argument
[07:02] <docgnome> I'm running bzr 1.4 under cygwin. Every time I try to do a checkout it spits back bzr: ERROR: [Errno 0] Error
[07:05] <docgnome> any ideas?
[07:06] <Peng> docgnome: You could pastebin the traceback and .bzr.log section. But I dunno how much the developers care about supporting Cygwin.
[09:04] <Le-Chuck_ITA> Hi there, I don't understand one thing of bzr: is it possible to manage more than one branch in the same local repository?
[09:04] <Le-Chuck_ITA> or should I always copy the current directory to a new one?
[09:06] <igc> night all - have a good weekend
[12:56] <ignas> hi
[12:56] <ignas> anyone has any ideas why i could be getting "bzr: ERROR: exceptions.AssertionError: 2412 != 2413" ?
[12:56] <ignas> when trying to commit
[12:57] <ignas> "assert len(history) == revno, '%d != %d' % (len(history), revno)" to be more accurate
[13:11] <Peng> ignas: Your revnos are a little off. There's info on either the mailing list or bug tracker, if you can find it.
[13:12] <ignas> is it fixable?
[13:12] <Peng> ignas: Yes, but I don't remember the details.
[13:16] <ignas> emm i don't think the fix is in hardy though :/
[13:27] <ignas> the "production ready" part of bzr is sometimes giving me doubts...
[14:23] <ignas> bzr check is stuck in [                                                             ] checking versionedfile     0/12726 for like 30 minutes
[14:23] <ignas> should i be worried?
[15:33] <jam> vila: your patches are going to the wrong mailing list
[15:34] <vila> huh ?
[15:34] <jam> vila: you are sending to "bazaar-commits@" not "bazaar@"
[15:34] <vila> aaargh
[15:34] <jam> your merge requests
[15:34] <vila> thanks for the heads-up :)
[15:35] <vila> hmmm, on another project I took the habit to use 'bzr send', get bitten there :)
[15:35] <vila> 'bzr send' with no params I meant
[15:35] <jam> vila: well, send should do the right thing, but you have to set your 'mail_to'
[15:36] <jam> as opposed to you "post_commit_to"
[15:38] <vila> only post_commit_to seems to be defined...
[15:41] <vila> hehe, no, submit_to was defined (with a wrong value), and it's really submit_to, not mail_to
[15:42] <jam> spiv: are you still around?
[15:42] <jam> vila: anything you want to try to sneak into the 1.5rc1 release today?
[15:43] <vila> --starting-with ftw :)
[15:43] <vila> bug fixes can wait next week isn't it ?
[15:43] <spiv> jam: not really ;)
[15:43] <spiv> jam: I think my big patch should miss 1.5
[15:43] <jam> spiv: k, I was checking in
[15:43] <jam> I would have liked to have it
[15:43] <jam> but it seemed a bit large for a last-day approval
[15:44] <jam> anything else in the queue?
[15:44] <spiv> jam: happy releasing!
[15:44]  * spiv -> sleep
[15:44] <vila> spiv: good night
[15:44] <jam> igc: ping, for great justice, and things you want in 1.5rc1
[15:44] <jam> poolie: I know you're not here, but just in case
[15:44] <jam> lifeless: Anything you need me to merge for 1.5rc1?
[15:45] <james_w> jam: thanks for the weekly report, I think it's a good thing to have.
[15:45] <jam> james_w: well, thank statik as it was his idea, but I agree that it is a good one
[15:45] <james_w> statik: thanks!
[15:45] <jam> vila: this is 1.5rc1, so not really
[15:45] <jam> vila: we forgot todo a feature freeze bugfix release
[15:46] <statik> james_w: glad you liked it!
[15:46] <jam> vila: martin is wanting to get back on schedule, rather than having them all keep slipping
[15:46] <igc> hi jam
[15:46] <jam> igc: you know, I'm always shocked to see you guys awake and online at this time
[15:46] <igc> me too :-)
[15:46] <statik> jam: igc is an unstoppable code machine, he only closes his eyes to make everyone else feel normal
[15:47] <cody-somerville> :)
[15:47] <igc> statik: just finished watching a movie actually ...
[15:47] <vila> jam: good, I'm always bad at sync with the releases schedule anyway :) My remark still stands, I'd be happy to have --starting-with (really only the doc tweak requested by martin needs review), the bug fixes I'm issuing today are not urgent, if you don't have the time to handle them, no worries
[15:47] <igc> and checking on the Out Of Memory bug that has me intrigued
[15:48] <jam> igc: the change you made in fast-import is because it isn't double-buffering
[15:48] <jam> Maybe also the lines variable isn't getting GC correctly
[15:48] <jam> but doing line.append().... ''.join() has to allocate 2x memory
[15:48] <jam> now, line += '' has to re-allocate as well
[15:49] <jam> but IIRC, CPython is able to re-use the memory (using realloc instead of a new malloc/free)
[15:49] <jam> but that is a "don't expect this to always work" feature of CPython
[15:50] <vila> igc: you're coding while watching a movie ! Wow, I'm impressed :)
[15:50] <spiv> StringIO is arguably more likely to use memory better than +=
[15:50] <igc> vila: nah - movie over 30 minutes ago
[15:50] <jam> igc: Though I'm mostly guessing, anyway anything pressing for 1.5rc1?
[15:50] <vila> and spiv talks while sleeping, those australian guys....
[15:50] <jam> I can take a look at your doc patches
[15:50] <spiv> Probably even better is probably not combining string objects at all.
[15:50] <jam> while we *can* bring them in later, I'd really like to respect the spirit of a "release candidate"
[15:52] <igc> jam: np. I'd really like the plugins+integration doc patch in if it's ok
[15:52] <jam> igc: reviewing now
[15:52] <igc> the other one is getting closer ...
[15:52] <igc> I'll see if it's worth resending it tonight (or not)
[15:59] <jam> igc: does the "part2_intro.txt" belong in the "A brief tour" chapter?
[15:59] <igc> jam: yes
[15:59] <jam> It seems like you are starting a whole new chapter/book/etc and that paragraph is "above" that section
[15:59] <igc> jam: if we split the chapters into parts, that would be true
[16:00] <igc> we don't have partsa so it's at the start of the first chapter in that part
[16:00] <igc> in the current guide, similar text intros "Best practices" fwiw
[16:01] <jam> igc: overall bb:approve
[16:01] <jam> igc: can you get it sent in now, so it is queued up for me?
[16:01] <igc> jam: cool, thanks
[16:01] <igc> sure
[16:03] <vila> jam: I sent 3 patches, you catch up on the second one (but the third was already send), I re-send the three to the right address
[16:04] <jam> I saw a couple of them come in, reviewing now
[16:04] <vila> jam: thks
[16:15] <ignas> hmm, if I have a checkout from a remote bzr shared repository, and run bzr reconcile in the checkout
[16:16] <ignas> will that fix - my local checkout, the revisions from that branch in the remote repository, the whole remote repository?
[16:19] <davidge> hi all
[16:19] <ignas> hi
[16:20] <jam> vila: reviews are in
[16:21] <vila> jam: thks, what about --starting-with then ;-)
[16:21] <davidge> what should i do to convert my dir-with-subtree repository to a non subtree one? the only format i can convert without errors is pack-0.92-subtree
[16:21] <jam> vila: can I get a --starting-without ?
[16:21] <ignas> jam: are you the same person who worked on https://bugs.launchpad.net/bzr/+bug/177855 ?
[16:22] <jam> ignas: I am, though today is release day, so I might not have a lot of time
[16:22] <jam> ignas: "reconcile" fixes the local repository
[16:22] <ignas> jam: how do i fix the remote one then?
[16:23] <jam> ignas: bzr reconcile sftp://url/to/repository
[16:23] <jam> though I might recommend
[16:23] <jam> ssh host
[16:23] <jam> bzr reconcile /repository
[16:23] <vila> jam: If there is a joke, I miss it 8-/
[16:23] <ignas> i think the fix is not in ubuntu yet
[16:23] <ignas> or is it?
[16:23] <jam> vila: you added --starting-with, I'm asking for -without
[16:23] <jam> ignas: bug #177855 is not in ubuntu yet
[16:23] <jam> well, the fix
[16:24] <vila> what will that means ?
[16:24] <jam> ignas: I think it is in bzr.dev, and if so, it will be in 1.5rc1 which I am releasing today
[16:24] <ignas> if it's not then I would have to get a bzr checkout working on the remote server somehow, then run it there and take care so it would not mess up permissions on the central repository ...
[16:24] <ignas> jam: i see
[16:24] <jam> vila: I have no idea, it is just the "opposite" of whatever you were trying to do
[16:24] <ignas> jam: thanks for fixing it
[16:25] <vila> jam: ha ! A joke then ;-) Sorry, a bit slow today
[16:25] <jam> vila: well, it wasn't a very good joke, either
[16:28] <fullermd> A good joke needs puns, and dancing sheep.
[16:29] <jam> vila: could you make it --starting-without-dancing-sheep then?
[16:29] <fullermd> Yeah.  They're better when they don't come in 'till the second act.
[16:31] <jam> vila: so you didn't do the 'auto-prefix' right?
[16:32] <vila> no, I think defining aliases is my prefered solution, we could add an auto-prefix for 'bzrlib.' later, I' always very cautious when it comes to UI tweaks a-priori ;-)
[16:33] <jam> vila: I don't think you can do it with an alias, just because it won't stack
[16:33] <jam> but yeah, I'm okay with bringing this in first
[16:33] <jam> as I think it is something we can add later
[16:33] <jam> I was also thinking something like
[16:33] <jam> bzr selftest -s B.T.aoeuaoeu
[16:33] <jam> and have B.T always expand to bzrlib.tests
[16:33] <jam> and maybe B.P to bzrlib.plugins, etc
[16:34] <jam> but that is for discussion
[16:34] <jam> certainly not for your review right now
[16:34] <vila> jam: exactly, you just came up with someting better than a raw bzrlib. , let's get more people playing a bit and I'm sure a better scheme will emerge
[16:35] <vila> another idea was to find a way to enable some completion mechanisms for shell users
[16:37] <jam> vila: autocomplete seems hard to do, since you would need to load the tests to figure out how to complete them
[16:37] <jam> though I guess if you had bzrlib.tests/plugins/etc autocomplete it might be a start
[16:38] <vila> jam: *I* will settle for something updated one a day...
[16:38] <vila> s/one/once/
[16:38] <jam> vila: ahh, but how do you handle that I have 20 different branches with different tests available?
[16:38] <jam> B.T works fine for me :)
[16:39] <jam> I don't have tab completion for bzr turned on yet anyway
[16:41] <vila> jam: I just ignore the differences between the 20 branches, that why I said '*I*'ll settle for a good enough solution', but the truth is that, as an emacs user, I already have some completion available ;-)
[16:42] <vila> and my experience is that in most of the cases I will use the option for some test that has failed and for which the ID is one copy/paste away...
[16:44] <igc> jam: "Zen" User Guide patch updated and sent to the list
[16:45] <jam> vila: I would tend to run "--starts-with bzrlib.tests.test_module_I_am_working_on"
[16:45] <igc> jam: I'm off to sleep so please merge it if you think it's now worthy of being approved.
[16:45] <igc> night all
[16:45] <jam> igc: well, robert and I seem to be debating
[16:45] <jam> so I'll look at it
[16:45] <jam> but won't guarantee anything
[16:45] <jam> I'm pretty loose about merging docs, though
[16:45] <jam> something better than nothing, and all
[16:47] <igc> jam: sure. What I meant was, if you think robert would no longer think it was confusing
[16:47] <jam> igc: I'll try to channel my inner lifeless
[16:47] <jam> vila: do you have your patches sent to the PQM ?
[16:47] <jam> I don't see them showing up
[16:47] <jam> and I have to wait for them to get in before I can finish working on 1.5rc1
[16:52] <fullermd> jam: Is bug 211661 still likely to be handled for 1.5?
[16:55] <vila> jam: hold on a sec, I'm working on sending them
[16:55] <jam> fullermd: it works for me
[16:56] <jam> fullermd: You can still see it failing?
[16:56] <fullermd> Yah.  Logging my local bzr.dev over bzr+ssh://localhost/ still dies every time.
[16:57] <fullermd> (with system-wide 1.4 or local bzr.dev, any combo client/server)
[16:57] <jam> fullermd: it works with "--short"
[16:57] <jam> that was my problem
[16:57] <jam> --long fails
[16:57] <jam> ugh
[16:57] <fullermd> Hm.
[16:57] <fullermd> Well, --short fails too, in a different way.
[16:57] <jam> fullermd: can you confirm on your side?
[16:58] <fullermd> ObjectNotLocked: KnitPackRepository('bzr+ssh://localhost/home/fullermd/src/bzr/.bzr/repository/') is not locked
[16:58] <jam> fullermd: do you have a weird plugin installed?
[16:58] <fullermd> bzrtools, gtk, heads, cvsps.
[16:58] <fullermd> (well, and lp of course)
[16:58] <jam> fullermd: try '--no-plugins' and '--no-aliases'
[16:58] <jam> fullermd: ahh, you know what, my public bzr.dev repo is knits
[16:58] <jam> which don't give that error
[16:59] <fullermd> % env BZR_REMOTE_PATH="dbzr --no-plugins --no-aliases" dbzr --no-plugins --no-aliases log --short bzr+ssh://localhost/home/fullermd/src/bzr/bzr.dev/
[16:59] <fullermd> Password:
[16:59] <fullermd> bzr: ERROR: bzrlib.errors.ObjectNotLocked: KnitPackRepository('bzr+ssh://localhost/home/fullermd/src/bzr/.bzr/repository/') is not locked
[16:59] <jam> fullermd: unfortunately, I don't know if anyone would be around to review a patch for 1.5rc1
[16:59] <jam> but maybe a 1.5rc2 or something
[16:59] <jam> I'll check into it for a bit
[17:00] <fullermd> Oh, well.  It's been around a month or so; a few days won't hurt more.
[17:00] <fullermd> Just making sure it's at least on a list somewhere   :)
[17:00] <jam> fullermd: confirmed both ways
[17:01] <jam> The ObjectNotLocked
[17:01] <jam> and the ValueError
[17:02] <fullermd> Well, as long as you're safe from being bored, my work here is done   ;>
[17:02] <jam> fullermd: I seem to be missing the patch in my bzr.dev
[17:02] <jam> weird
[17:02] <jam> fullermd: what do you see in log.py line 526
[17:03] <jam> I think there might be something wrong with the merge back into bzr.dev
[17:03] <jam> because of how we handled the transaction cache stuff
[17:03] <fullermd>         graph.iter_ancestry(mainline_revs) if value is not None))
[17:03] <jam> basically, we wanted to pull most of the 1.4 branch back in, but not that patch
[17:03] <jam> fullermd: yeah, that should be 'mainline_revs[1:]'
[17:03] <jam> according to my patch
[17:04] <fullermd> I have that in 515
[17:04] <fullermd> (on)
[17:04] <jam> fullermd: you need it in *both*
[17:04] <jam> 515 is --short
[17:04] <jam> 526 is --long
[17:04] <fullermd> Ah, but that sets revision_ids, which is used....
[17:04] <jam> fullermd: and then returns right away
[17:04] <fullermd> ...  ah, IC.
[17:05] <jam> fullermd: so does the bzr 1.4 client work for you?
[17:05] <fullermd> One sec, testing that sub.  Server is spinning, but hasn't output anything yet.
[17:06] <fullermd> Mmph.  Passing a minute of CPU time with no output yet...   I guess it's working, but wow that needs some work...
[17:07] <jam> fullermd: hmm.. I don't see it in 1.4 either
[17:07] <jam> fullermd: you can do "bzr log --long -r ..10"
[17:07] <jam> so it doesn't have to do the whole thing
[17:07] <fullermd> 2 minutes...
[17:07] <fullermd> Now I just gotta wait it out and see how long it takes to say anything...
[17:08] <jam> fullermd: ok, this is weird
[17:08] <jam> I see the patch show up in 3360.1.7
[17:09] <jam> but the final merge 3363 doesn't have it
[17:10] <jam> fullermd: ahhhhhh..... different code paths
[17:10] <jam> there is one at 526
[17:10] <jam> and another one at 467
[17:10] <fullermd> OK, up to 4.5 minutes of CPU time...  the client-side python process is finally starting to eat some CPU, but still no output   :|
[17:10] <jam> The fix that made it in only fixed 467
[17:11] <fullermd> 'k, screw it.  6 minutes of CPU burned with no output is Too Damn Long.
[17:11]  * fullermd kills it.
[17:13] <fullermd> --limit 10 passed a minute before I killed it...
[17:15] <jam> fullermd: it is important to log the first revision
[17:15] <jam> --limit 10 might not
[17:16] <fullermd> On bzr.dev it won't   :p
[17:16] <jam> fullermd: which is why I recommend -r ..10
[17:16] <fullermd> Grabbing ..10 worked, and fairly fast.  But there weren't any merges that early in the history, so...
[17:16] <jam> just to log the first 10
[17:17] <fullermd> Now I'm prepping another bug report about the time issue...
[17:17] <jam> fullermd: ok, in my patch I clean up all implementations to refuse to handle None
[17:17] <jam> and I can see that we are still doing the wrong thing here
[17:17] <jam> fullermd: if the object isn't locked at the right point
[17:17] <jam> that could certainly effect performance
[17:18] <fullermd> log --limit 10 locally runs in about 9 seconds.  I'm over 2 minutes of CPU time on the server doing it over bzr+ssh://localhost/ now.  So, there's sure something beating it down.
[17:18] <fullermd> (not that 9 seconds is busting any records, but in comparison...)
[17:21] <jam> fullermd: that is --long format, right?
[17:22] <fullermd> Yah, I don't have any aliases affecting 'log'.
[17:22] <jam> 'time bzr log --limit 10' is 1.3s here
[17:22] <jam> well, that is --short
[17:22] <jam> --no-aliases is 2.5s, though
[17:22] <fullermd> You probably have a somewhat faster machine than I.
[17:23] <jam> fullermd: can you do "grep -a len .bzr/repository/pack-names"
[17:23] <jam> just curious
[17:24] <fullermd> 8
[17:24] <jam> fullermd: not terrible, then
[17:24] <jam> I've had it up closer to 20
[17:24] <fullermd> --short --limit 10 runs on 0.6.
[17:24] <jam> vila: any chance you would feel comfortable reviewing by bug fix for 211661 ?
[17:24] <fullermd> (in)
[17:25] <fullermd> --line is essentially indistinguishable.  --long runs 8.5-9.
[17:28] <vila> jam: I don't think so, I still have to be more familiar with the smart server :-/ And gf is has already thrown a priority interrupt currently masked while I finish sending submissions to pqm...
[17:28] <vila> s/is//
[17:29] <jam> vila: it isn't really smart server code
[17:29] <jam> it is log.py code
[17:29] <jam> the fix is pretty trivial
[17:29] <jam> but I understand about priority interrupts
[17:30] <jam> vila: and your second submission won't work
[17:30] <jam> you have it set as "bzr+ssh:///"
[17:31] <jam> vila: Merge bzr+ssh://bazaar.launchpad.net/~vila/bzr/199440-auth-ssh-user-no-pass http://bazaar-vcs.org/bzr/bzr.dev
[17:31] <jam> vila: however, I'll submit something for you
[17:32] <vila> jam: rats, I usually do a single submission using the same branch :-/
[17:32] <fullermd> Filed bug 228740 for log speed.
[17:32] <fullermd> Sad.  8 seconds vs. 7.5 minutes.
[17:33] <jam> vila: the other advantage of me submitting it
[17:33] <jam> is that if it fails
[17:33] <jam> I can resubmit, etc
[17:33] <jam> while you go sleep
[17:33] <jam> or GF time, whatever
[17:33] <fullermd> Locking sounds like a good candidate source for the problem.
[17:34] <vila> ok, that'be better, I will then tweak 183705 as per your review and let you submit then, I'm a bit worried about NEWS conflicts while doing several submissions like that
[17:35] <jam> vila: just send me something I can submit
[17:35] <jam> I'll try to work out NEWS
[17:36] <jam> fullermd: even weirder is that show_log() calls lock_read() and then hands off to _show_log
[17:36] <jam> so everything should be locked
[17:39] <jam> ok, weird
[17:39] <jam> branch.is_locked() == True, branch.repository.is_locked() == False
[17:41] <vila> jam: fix for 183705 mergeable from http://bazaar.launchpad.net/~vila/bzr/183705-auth-doc-unclear
[17:41] <jam> vila: thanks
[17:42] <jam> vila:  I'm glad you have the bandwidth/latency to push stuff up to lp.net
[17:43] <vila> That surely helps a lot...
[17:44] <jam> vila: submitted
[17:44] <jam> vila: as an aside, I prefer if you use "#BUGNUM" rather than just "NUM"
[17:45] <jam> just because it makes it possible to grep for bug numbers
[17:45] <vila> damn it, I wrote bug NUM ? Endless typos today :-/
[17:45] <jam> though the numbers are big enough now that it is pretty unlikely to have a false positive if you are looking for a specific bug
[17:45] <jam> '(vila) Fix 199440 by taking allowing no password in a section'
[17:45] <jam> vila: and then I, of course, just copied your message and did the same
[17:46] <fullermd> It was corrupted by being transfered over hhtps.
[17:46] <vila> grr, sure, same here :-/
[17:46] <vila> hehe, typed hhtp yesterday but caught it before it was too late ;)
[17:46] <jam> vila: have a great weekend, by the way
[17:48] <vila> gf re-raising interrupt, thanks jam, can you also submit --starting-with from http://bazaar.launchpad.net/~vila/bzr/faster-selftest/ ?
[17:48] <vila> It may be a loom, but that's the last thread so it should be easy to find the relevant patch
[17:49] <vila> thanks a lot for your work on 1.5rc1, all the reviews, being a good guy, have a nice week-end too, say hi to your son ;-)
[17:50] <jam> vila: of course, that means I need to install looms here :)
[18:00] <jam> vila: checking out "lp:~vila/bzr/faster-selftest" gives me a non-loom branch which is already merged into bzr.dev
[18:07] <vila> jam: first priority handled, 5 minutes freed, you don't have looms installed ?
[18:09] <vila> hmmm, I thought that branch was a checkout, it wasn't, pushing right now
[18:13] <vila> ok, lp:~vila/bzr/faster-selftest should be good to merge now
[18:14] <vila> jam: sorry for the mess :)
[18:14] <vila> on to interrupt #2 now, this one will take longer :)
[18:15] <jam> vila: nothing in NEWS?
[18:33] <vila> jam: regarding --starting-with ? It should in TESTSING section
[18:33] <jam> bzr diff -r ancestor:../../bzr.dev NEWS
[18:33] <jam> is empty
[18:33] <vila> gee, It should be in TESTING section
[18:34] <jam> vila: you might have put it in another doc
[18:34] <vila> ancestor on a loom branch (or son of a loom), I'm not sure it does what you think it does...
[18:37] <vila> or may be push from a loom branch doesn't do what I thought it should be doing...
[18:37] <vila> >-/
[18:41] <vila> Ok, I forgot the 'bzr record' before pushing, re-pushing a bunch of revisions
[18:43] <vila> jam: the correct revno is 3345
[18:44] <jam> vila: when I branched from you, the local one is *not* loom
[18:45] <vila> the remote one is not either (I think) but anyway, the current tip on that branch should now be at 3345 and ok for you to branch even without loom
[18:45] <jam> vila: 3345: merge bzr.dev, fixing simple conflicts
[18:45] <jam> vila: and the change is in NEWS
[18:45] <jam> looks good
[18:46] <vila> I really appreciated loom for that branch, but I lack the deep understanding when it comes to sharing a loom,
[18:50] <jam> vila: well, AIUI there have been some bugs about pushing stuff out of a loom
[18:51] <vila> yeah, I saw  a patch about that, may be I've just been lucky that bzr record allowed to push the right revisions a few minutes ago :)
[19:27] <nysin> When trying to rebase, I see "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified." (this is accurate as far as bzr knows but they in fact roughly do. If necessary I can try to supply an exact analog-revision but hopefully it's not.)
[19:29] <nysin> I've tried using --onto but without success - so, can one specify 'I, the user, am stating that revision X from branch Y and revision Z from branch W are the same'?
[20:14] <james_w> nysin: specifying a merge base means to give a start to the range in the -r argument
[20:14] <james_w> if you say "merge -r 20" it will merge in revision 20 of the other branch
[20:15] <james_w> and all of it's ancestors
[20:15] <james_w> if you say "merge -r 10..20" it will merge in revisions 10 to 20 of the other branch
[20:15] <nysin> Hm. The error message I get from -r suggests that it's looking at the current branch
[20:15] <james_w> if you say "merge -r0..-1" then it will merge the two branches, whether or not they have a common ancestor.
[20:16] <davidge> Hi all
[20:16] <nysin> "$ bzr rebase --dry-run -v -r1021 ../dp/" is the command but when then I see "does not exist in branch: BzrBranch6('file:///home/nysin/mod/')"
[20:16] <davidge> Is there a way to convert a dir-with-subtree repository to another (no subtree) format?
[20:18] <james_w> nysin: sorry, completely missed you were using rebase
[20:18] <james_w> davidge: I'm not sure, it's theoretically possible to convert it to a rich-root repository if you have not used any subtree features.
[20:19] <nysin> james, ah, okay.
[20:20] <james_w> nysin: in that case I'm not sure what the answer is I'm afraid.
[20:20] <davidge> james_w: it's a plain repository without subtree features. But in practice, all 'bzr upgrade' commands fail with an error :(
[20:21] <james_w> davidge: what's the error for bzr upgrade --rich-root-pack?
[20:22] <davidge> james_w: bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack4>.  Does not support nested trees
[20:23] <james_w> davidge: ok, it seems that it's not possible then.
[20:23] <james_w> davidge: hopefully soon upgrading between formats in this way will become a lot smoother.
[20:24] <davidge> davidge: you mean there is work in bazaar upcoming releases for that?
[20:24] <davidge> james_w i mena :D
[20:24] <james_w> heh
[20:25] <james_w> I'm not sure it's exactly this case, but there has been a plan to make the converters much more friendly to this sort of thing.
[20:25] <james_w> I'm not sure whether it's in 1.5
[20:26] <davidge> james_w: i'm glad to hear that there is some of kind work for that...
[20:26] <davidge> james_w: maybe i'll give a try to 1.5rc1
[20:27] <jam> james_w:  the way to go from -subtree => rich-root is via 'bzr init && bzr pull'
[20:27] <james_w> ah, thanks jam
[20:27] <jam> it isn't *supposed* to work, but it does, and is the current workaround
[20:29] <fullermd> Well, that's encouraging   :p
[20:31] <james_w> jam: are you at UDS by any chance?
[20:31] <davidge> jam: hmm, thanks, i'll try that...
[20:31] <jam> james_w: nope
[20:31] <jam> where is it this time?
[20:31] <james_w> ah, shame.
[20:31] <james_w> Prague.
[20:35] <jam> lifeless, poolie: The PQM seems to be unhappy with me. When I do 'pqm-submit' nothing shows up on https://pqm.bazaar-vcs.org/
[20:36] <jam> And I don't get an email about failure, either.
[20:38] <rick_h_> anyone know how to use this now that the bug is fixed? https://bugs.edge.launchpad.net/bzr-svn/+bug/120768
[20:39] <rick_h_> I'm not seeing any docs on how to force the password on first push
[20:39] <james_w> hi ricardokirkner
[20:39] <james_w> hi rick_h_
[20:39] <rick_h_> hey james_w
[20:40] <ricardokirkner> hi james_w
[20:40] <james_w> rick_h_: do you have subversion 1.5 installed?
[20:41] <vadi2> Is it possible to get an output similar to "bzr log" on a web server not hosting the bzr repository? The server that is hosting has loggerhead installed, but that only gives a web interface to it.
[20:41] <rick_h_> james_w: oops, got me. I assumed hardy had 1.5
[20:41] <rick_h_> shoot, ok thanks
[20:41] <james_w> rick_h_: nope, I don't think 1.5 is out yet.
[20:42] <james_w> vadi2: bzr log will work against remote branches, is that what you want?
[20:42] <jam> rick_h_: hardy has 1.3.1, IIRC
[20:42] <jam> I'm putting together 1.5rc1 today
[20:42] <jam> 1.4 final was just released last thursday
[20:42] <vadi2> ﻿james_w: i'm afraid the server doesn't have and can't have bzr on it
[20:42] <rick_h_> james_w: well I'm just getting started with bzr and trying to demo bzr-svn for a lightning talk
[20:42] <jam> It is available in the launchpad ppa
[20:42] <rick_h_> I checked out a public svn repo, but wanted to demo push, which required auth
[20:42] <rick_h_> hmm, dpkg -l lists 1.4.6 for svn
[20:42] <rick_h_> in default hardy
[20:43] <james_w> jam: svn 1.5, it has bzr 1.3.1, yes.
[20:43] <jam> ah, wrong version, you are talking svn. sorry for the noise
[20:43] <rick_h_> in my normal work case the branch required auth so it worked fine, but didn't want to demo with the work's stuff
[20:44] <james_w> rick_h_: I believe the old way to do it was to make the svn client auth, as this was cached and bzr-svn could use it, did you try that?
[20:44] <LaserJock> what do you call the .bzr/ directory? I'm trying to refer to that as opposed to the entire branch/working tree
[20:44] <jam> james_w: dpkg -l lists 1.4.6dfsg1-2ub here
[20:45] <james_w> vadi2: I'm not sure then, sorry.
[20:45] <jam> LaserJock: the Bazaar control directory
[20:45] <rick_h_> james_w: not sure how to set up the svn client to auth since there's no .svn there.
[20:45] <rick_h_> it was a straight branch from the svn repo
[20:45] <LaserJock> jam: would that work as a DVCS generic term?
[20:45] <LaserJock> "control directory" I mean
[20:45] <vadi2> ﻿james_w: alright no problem.
[20:45] <james_w> rick_h_: an "svn ls http://wherever" doesn't require authentication
[20:45] <james_w> ?
[20:45] <jam> LaserJock: well other ones would generally call it something different, but IMO it is still a control directory
[20:46] <jam> a lot of them call it a "repository" which doesn't match Bazaar/SVN/CVS terminology
[20:46] <LaserJock> I'll just use control directory, I think people will get it
[20:47] <rick_h_> james_w: no, ls does not require auth.
[20:47] <rick_h_> public access to pull, need perms to commit
[20:47] <james_w> rick_h_: I'm not sure then, sorry. I don't know where the auth is cached, so another svn checkout to commit may do it.
[20:48] <rick_h_> cool, no problem. just for a demo so no worries
[20:48] <james_w> rick_h_: or if you have one lying around you could perhaps try and find the credentials.
[20:48] <rick_h_> it's coming is the asnwer I can give for now
[20:48] <jam> lifeless, poolie: unping, it is probably PEBKAC, I think I was leaving --dry-run on ...
[22:26] <jelmer> rick_h_: hi