[00:00] <abentley> jam: turns out there's a downside of lp: URLs, too.  They can't address private branches.
[00:08] <abentley> jam: actually, that's wrong.
[00:18] <august> is there an easy way to copy somebody's branch into a new branch under me on launchpad?
[00:19] <thumper> august: only to get a copy yourself and push it
[00:19] <august> hmm
[00:19] <august> ok
[00:23] <poolie> august: or bzr branch lp:~him/thin/1 lp:~me/thing/2
[00:23] <august> that's simpler
[00:23] <poolie> lifeless: interesting but nothing earthshattering; the review queue is growing again and needs love
[00:32]  * a_c_m is FINALLY understanding branches vs checkouts... god bzr rocks
[01:03] <lifeless> 13G
[01:06] <jml> a_c_m: :)
[02:05] <cafuego> Hi all, I have a question about merging unrelated trees into one, whilst keeping all history. is that possible?
[02:05] <cafuego> And if so, how? :-)
[02:06] <jonoxer> cafuego: Interesting question, I'm going to put it to the test right now
[02:06] <thumper> cafuego: yes it is possible
[02:07] <thumper> cafuego: but I can't remember the special magic words
[02:07] <thumper> spiv: can you help?
[02:07] <cafuego> jonoxer: Oh, hi there!
[02:07] <jonoxer> cafuego: hi!
[02:07] <jonoxer> I'm just a bzr noob here to figure out how things work
[02:07] <jonoxer> So questions like that are interesting
[02:08]  * cafuego is also a bzr noob, so asks questions like that ;-)
[02:08] <cafuego> I had  aperv at bzr merge, and then mentions a mergebase, but then doesn't say how to specify it or what it is
[02:11] <jonoxer> cafuego: merge has an "--lca" flag! And the help text says "LCA-newness merge"!
[02:11] <jonoxer> Not that it helps you, it's just funny
[02:11] <cafuego> Yeah, I saw that <heh>
[02:11] <cafuego> I think it means "merge now and worry later" ;-)
[02:11] <thumper> I think adding --force to the merge command gets it to work
[02:12] <jonoxer> thumper: nope, still says "branches have no common ancestor"
[02:12] <thumper> hmm..
[02:13] <spiv> -r 0..-1
[02:13] <thumper> spiv: I was just thinking about something like that
[02:13] <spiv> cafuego: bzr merge -r0..-1 unrelated_tree
[02:13] <jonoxer> spiv: interesting, that worked in my test
[02:13] <jonoxer> Neat trick
[02:14] <spiv> Yeah, it's handy.  It's a bit of a special case.
[02:14] <cafuego> spiv: Ta, and hi also
[02:14] <spiv> cafuego: hi :)
[02:14]  * cafuego goes back to his clean tree and runs it in a subdir this time
[02:14] <jonoxer> spiv: Makes for a cool-looking vis graph, too! I've never seen a convergence like that before
[02:15] <jonoxer> Or a rev "0.1.1"
[02:15] <spiv> Heh :)
[02:15]  * fullermd has plenty of branches with rev 0.4.1   :p
[02:16] <jonoxer> spiv: by the way, thanks to you (and others on #bzr as well): http://jon.oxer.com.au/blog/id/290
[02:18] <lifeless> 13.6GB
[02:21] <spiv> jonoxer: awesome.  Thanks :)
[02:31] <cafuego> Whee, all done.
[04:05] <emmajane> I'm just setting up JungleDisk+Amazon S3 as a backup network. I know I can rsync files to it as well. If I wanted to have my "personal" bzr repositories somewhere other than my office network, could I push commits to S3 as well? And does that even make sense as a question? :)
[04:08] <jonoxer> emmajane: if you can rsync to it then yes, you should be able to push the repo to it. However, see here: http://research.operationaldynamics.com/blogs/andrew/software/version-control/bzr-repository-rsync.html
[04:09]  * emmajane reads
[04:09] <jonoxer> That's from a couple of years ago, I don't know if things have changed since
[04:10] <jonoxer> AfC was just on the channel but left 10 mins ago, we could have asked him
[04:10] <emmajane> I don't usually branch... just tag. So I think I'll be ok.
[04:11] <emmajane> jonoxer: i'm backing up the directories that contain the bzr repos, so I'm not sure I also need to push them as well...
[04:11] <jonoxer> emmajane: It sounds like all you're wanting is somewhere to put them for disaster-recovery purposes, in which case you don't need to "push" in the bzr sense. Just update your backup with rsync from time to time
[04:12]  * emmajane nods
[04:12] <emmajane> yes. :)
[04:13] <jonoxer> Cool. Just treat your S3 storage like an extra disk then and dupe your directory onto it
[04:13] <emmajane> excellent. :)
[04:13] <emmajane> I love it when life is easier than originally expected. :)
[04:16] <lifeless> the only caveat is don't commit or pull while rsyncing
[04:16] <lifeless> there is a database in the repo that rsync can copy in an inconsistent state - unless you use a file system snapshot
[04:17] <emmajane> lifeless: good call re. commit and pull. I don't use a file system snapshot for this backup (although I have used it in the past for other things)
[04:17] <jonoxer> lifeless: good point. I'd assumed it would be done as a manual process so emmajane wouldn't be likely to be doing both at the same time, but if you cron-jobbed it you could have a problem
[04:20] <jonoxer> lifeless: are you going to OSDC or LCA?
[04:24] <lifeless> http://paste.ubuntu.com/58644/
[04:25] <lifeless> jonoxer: well the LCA miniconf invite actually put me off
[04:25] <lifeless> I might swing by LCA for a day
[04:25] <lifeless> jonoxer: more details in a bit, phone call right now
[04:28] <jonoxer> lifeless: I'm very curious now
[04:31] <poolie> the problem with S3 is it does not, in itself, provide ordering between different writers
[04:31] <emmajane> writers?
[04:32] <poolie> ah, i was talking about treating S3 as an actual repository
[04:32] <poolie> ratherthan just backing up to it
[04:32] <emmajane> ah :)
[04:32] <emmajane> would there be an advantage to using S3 instead of launchpad?
[04:33] <poolie> well, no, because it won't actually work :)
[04:33] <emmajane> hehe
[04:36] <emmajane> Although the PPA option on launchpad is always free + open and cannot be private/restricted, IIRC?
[04:37] <bob2> are sure you can rsync to s3?
[04:41] <emmajane> bob2: via jungledisk
[04:41] <emmajane> bob2: not directly though, no.
[04:41] <emmajane> bob2: www.jungledisk.com
[04:42] <thumper> poolie: are there any blockers to making format 1.6 the default for bzr 1.9?
[04:43] <bob2> emmajane: ah, interesting
[04:43] <emmajane> bob2: I'm just setting it up now. I'm quite impressed so far.
[04:43] <emmajane> bob2: I like that it's scalable. Dropbox was also nice but it was either 2G free, or 50G paid at $10/month.
[04:50] <jml> lifeless: wanna make subunit part of pyunit-friends too?
[04:51] <jdm> Has anyone had success using bzr-svn with Sourceforge?
[04:51] <jdm> specifically, committing using your account?
[04:52] <jdm> I've created a checkout for https://account@project.svn.sourceforge.net/svnroot/project
[04:52] <jdm> And it took my password just fine checking out
[04:52] <jdm> But committing doesn't seem to work
[04:53] <jdm> It just gives me a permission denied error
[05:01] <lifeless> thumper: yes, its too new
[05:02] <thumper> lifeless: given that it changes very little in the way of actual disk format, I find that surprising
[05:03] <lifeless> thumper: its nothing to do with what it changes
[05:03] <lifeless> thumper: I didn't say unstable :P
[05:03] <thumper> lifeless: this is somewhat screwing up the wonders of stacking with LP
[05:04] <thumper> lifeless: until it becomes the default, it looses a lot of its appeal
[05:04] <lifeless> thumper: changing the default tends to be disruptive because availability of the minimum version to use that bzr hasn't propogated out far into the ecosystem
[05:05] <lifeless> thumper: we cop a lot of flack about formats already; doing churn on the default will only make that worse
[05:06] <lifeless> thumper: branch --stacked and push --stacked will convert automatically, so I'm not sure why its screwing up LP
[05:06] <lifeless> I need food, lightheaded - back soon
[05:06] <jonoxer> lifeless: while you're eating, think about the miniconf story you're going to tell  :P
[05:23] <lifeless> jonoxer: back
[05:23] <lifeless> so miniconfs - did you see the generic RFP a few days back ?
[05:24] <jonoxer> Yes, linking to a number of miniconf sites IIIRC
[05:24] <lifeless> this sentence really bugged me: "Each miniconf is looking for a select range of talks from industry leaders and professionals alike."
[05:24] <jonoxer> Sounds like marketing-speak
[05:24] <lifeless> what happened to the grass roots community amateurs-are-as-good-or-better conference I knew and loved
[05:25] <lifeless> anyhow, I read that, and thought "I don't want to see a conference organised by people with that attitude"
[05:25] <jonoxer> Hopefully it hasn't been lost in translation and the conf itself will still have the same character
[05:25] <jonoxer> Rather, *has* been lost in translation
[05:25] <lifeless> jonoxer: hopefully; at this point I'm not interested enough to gamble time, leave and money in finding out
[05:26] <lifeless> I may blog about it once its had a full week to ruminate
[05:26] <jonoxer> I've been totally de-looped re LCA this time around, it's quite a weird feeling after being so much a part of it the last few years
[05:27] <lifeless> heh
[05:27] <lifeless> I got delooped after sydney
[05:28] <jonoxer> You're a Sydneysider, right? OSDC is in Sydney, but it may not be hard-core enough for you
[05:28] <lifeless> yah
[05:28] <lifeless> as I said re OSDC, I may drop by
[05:28] <lifeless> its right on the border of conflicting with other stuff IIRC
[05:30] <jonoxer> OSDC's content seems to converge closer toward LCA's each year. The first year it was very webby, very "let's do FOSS on Windows and MacOS". By last year it had Rusty doing rants on threading models
[05:32] <fullermd> I remember 10 years ago or so when I used to think once in a while, "Hm, I should try to hit a conference once in a while"...   eventually I saw the light   :p
[05:32] <lifeless> jonoxer: neat; sounds like LCA is a moving target though; question is if OSDC are smart enough to stop at peak :>
[05:32] <jonoxer> fullermd: Saw the light and realised you should go, or saw the light and realised you shouldn't?
[05:33] <fullermd> Well, realized it was never going to happen, and I probably wouldn't care for it if it did anyway   :p
[05:40] <lifeless> jam: btw - http://code.google.com/p/hypertable/wiki/ArchitecturalOverview - uses bloom filters
[05:40] <lifeless> poolie: 18.4GB
[05:50] <cafuego> you should see the number of webby talks we rejected for lca
[05:51] <jonoxer> cafuego: you mean for Melb, or are you on the papers ctte for Hobart?
[05:51] <cafuego> hobart
[05:51] <jonoxer> Glad I didn't submit any then!
[05:51] <cafuego> i cna't rember the submisisons for '08 - all repressed now ;-)
[05:52] <lifeless> cafuego: so if you're reading backlog, whats with the commercialoid nonsense in the RFP ?
[05:52] <cafuego> lifeless: I think it's just that - and won't affect the conference itself.
[05:52] <cafuego> At the end of the day the conf is made by the speakers and attendees, but by the press releases
[05:53] <cafuego> s/but/not/
[05:53] <cafuego> Keep in mind that Ben works for gov't
[05:53] <lifeless> cafuego: that press release implied no hobbyist or amateur talks
[05:53] <cafuego> lifeless: Oh, but there will be
[05:53] <jonoxer> Well, my talk about hotted up cars got in, so it's bound to be an "interesting" LCA!
[05:53] <lifeless> cafuego: then that press release needs reissuing asap; though perhaps I'm the only one reading it this way
[05:54] <lifeless> cafuego: cause I can't emphasise how big a turn off it is
[05:54] <cafuego> lifeless: I'll ping ben and let him know
[05:54] <lifeless> thanks
[05:55] <cafuego> but don't let it turn you off submitting or attending
[05:56] <lifeless> (unless of course it really means professional and industry leaders only, in which a blog post or something explaining is something I would read with interest)
[05:56] <emmajane> Heh. Ignore the public call for papers and submit regardless of what we've said. ;)
[05:56] <lifeless> cafuego: it's already turned me off; the work now is to get excited again
[05:56] <cafuego> lifeless: I'
[05:56] <cafuego> lifeless: I've tested the Daquiri machines at the casino .. they rock ;-)
[05:57] <lifeless> cafuego: they have a machine to make daquiri's!
[05:59] <cafuego> Yup. green and red.
[05:59] <cafuego> red sucks, green rocks.
[05:59] <lifeless> lol
[06:00] <bob2> commendable thoroughness!
[06:00] <fullermd> Bad time to be R/G colorblind   :p
[06:00] <cafuego> fullermd: I am actually.
[06:01] <cafuego> though not completely, which is a blessing ;-)
[06:01] <fullermd> Well, so much for trusting your advice on the matter now...
[06:01] <cafuego> you mean you're going to have to attend LCA and find out for yourself?
[06:01]  * jonoxer things lifeless may have just found the motivation he needs
[06:01] <jonoxer> s/things/thinks
[06:02]  * fullermd doesn't actually even know what LCA is, so....
[06:02] <lifeless> fullermd: linux.conf.au
[06:02]  * cafuego should decide whether he'll go to osdc
[06:03] <fullermd> Oh, heck.  I can't stand on my head long enough to be on the upside-down side of the world...
[06:03] <cafuego> fullermd: that's where the daquiri comes in
[06:06] <fullermd> I'm not sure I'd call that "helping".
[06:13] <lifeless> so, 41K revisions copied
[06:28] <jdm> hooray, apparently I was just giving bzr-svn the wrong password for sourceforge
[06:28] <jdm> the world is right again
[06:31] <lifeless> poolie: the usertest run is 4/5ths complete
[06:32] <lifeless> poolie: more than 41K out of 54K revisions copied
[07:05] <vila> hi all
[07:20] <vila> lifeless: what are those GB you keep announcing, I don't know if I should be rejoiced or frighten...
[07:32] <lifeless> http://benchmark.bazaar-vcs.org/usertest/log/usertest.log.inprogress
[07:32] <lifeless> its the CHK based inventory
[07:32] <lifeless> vila: pulling mysql-server into it
[07:33] <gour> hi, it's not very high priority but would be nice if bzr-svn could serve svn-externals. what is missing in bzr?
[07:35] <gour> http://bazaar-vcs.org/BzrForeignBranches/Subversion mentions need for 'nested branch' and the other issue which i'm not clear about
[07:36] <vila> lifeless: what do those GB represent ? The repo is around 620MB with packs...
[07:36] <lifeless> vila: well its not really
[07:37] <lifeless> vila: grab the plugin I just posted and the repository branch, and then analyse an existing repo
[07:37] <lifeless> vila: the raw data is _much_ bigger than 620MB; the CHK inventory is smaller in raw data
[07:37] <lifeless> vila: its just not being delta compressed at all at the moment
[07:39] <vila> lifeless: haaa, good, so you're *creating* a complete repo, uncompressed, with CHK invs ?
[07:40] <lifeless> vila: read the code
[07:40] <lifeless> vila: it will accomplish many things
[07:41] <lifeless> vila: you will know exactly what I'm doing; and you'll get a handle on the CHK inv work, and it will answer that question
[07:41] <vila> lifeless: hehe, touche, I must do that :)
[07:41] <lifeless> vila: I believe you will find it interesting
[07:42] <vila> I already know that and hope I can come in the game before it's too late :)
[07:45] <fullermd> Hm.  So, is 1.8 officially released?
[07:46] <fullermd> I see the tarball, and the wiki says so...   but the /topic and launchpad both still say 1.7.1, and I haven't seen an email about it.
[07:47] <lifeless> vila: is something making it difficult for you to get involved?
[07:49] <vila> shyness ? not knowing enough about the internals ? doubts about how to prioritize between the other areas I'm involved in ?
[07:49] <vila> Maybe
[07:50] <vila> Lack of brain power due to that damn wisdom teeth still hurting ?
[07:50] <vila> Surely
[07:51] <lifeless> wisdom teeth are a pain
[07:51] <lifeless> very distracting
[07:52] <lifeless> the first is in your court; the second is la poulet et la <egg>
[07:52] <spiv> ouef, IIRC?
[07:52] <lifeless> for the third, I'm happy to let you bounce this-or-that questions of me anytime
[07:52] <lifeless> spiv: oui
[07:53] <spiv> (as usual, I have no idea why I know that)
[07:56]  * vila goes to dentist for a control and hope for an explanation about why he can't open his mouth more than 1,5 cm wide
[07:57] <lifeless> vila: perhaps the rubber bands are too tight
[07:57] <vila> egg =oeuf (very close spiv but no cigar)
[07:57] <vila> lifeless: no user serviceable  parts :)
[07:57] <spiv> vila: ah, I feel better now :)
[07:58] <vila> lifeless: in retrospect I may change my first one (shyness) with can't open  my mouth these days :)
[07:59]  * vila realizes laughing is painful too o_O
[08:04] <lifeless> >
[08:04] <lifeless> :
[08:04] <vila> { ?
[08:40] <poolie> hey vila, lifeless
[08:40] <vila> hey poolie
[08:52] <fullermd> poolie: ^^ re 1.8
[08:53] <poolie> fullermd: hi?
[08:54] <fullermd> Hm.  So, is 1.8 officially released?
[08:54] <fullermd> I see the tarball, and the wiki says so...   but the /topic and launchpad both still say 1.7.1, and I haven't seen an email about it.
[08:54]  * awilkins knows the pain of wisdom teeth
[08:55] <awilkins> I had all four done surgically ; the lower set were growing downward and forward
[08:55] <awilkins> My days were becoming a haze of internal skull pressure
[08:56]  * fullermd has all 4 wisdom teeth.
[08:56] <lifeless> 43000 done, 11K to go
[08:56] <lifeless> hi poolie
[08:56] <poolie> fullermd: i've been taking it a bit slower and automating things or updating them as i go
[08:57] <poolie> mail will be sent soon
[08:57] <awilkins> My jawbone is still remodelling some years later - I have days where the lymph nodes in my tongue really swell and ache. I still keep a little dextropropoxyphene in reserve just in case.
[08:58] <awilkins> My teeth are nearly back where they started now...
[08:58] <fullermd> Ah, OK.  I had the port all updated and was getting ready to send it in, then I realized, "Hey...   I haven't even heard that this thing is really there yet".
[08:59] <awilkins> Which branch of bzr-svn are you using to convert MySQL?
[08:59] <lifeless> awilkins: ?
[08:59] <awilkins> Sorry, are you not doing that?
[09:00] <lifeless> awilkins: its in bzr already, this is converting to my testin format
[09:00] <lifeless> awilkins: mysql's master is in bzr :>
[09:01] <awilkins> Groovy!
[09:01] <lifeless> awilkins: you didn't know ?
[09:01] <poolie> lifeless: woo, it looks like your run finished
[09:02] <awilkins> lifeless: I dont do a lot of mysql hacking....
[09:02] <lifeless> poolie: no...
[09:02] <lifeless> poolie: its still running, 11K to go
[09:02] <poolie> oh, strange
[09:03] <poolie> why did the load jump up to 2.0 there?
[09:03] <lifeless> poolie: I'm running analysis on the partial data
[09:03] <poolie> ok
[09:03] <lifeless> I'm also prepping to copy the result out
[09:11] <lifeless> oh foo, just ctrl-c'd it
[09:11] <poolie> mail sent
[09:12] <poolie> lifeless: are you serious, you killed the main run? :P
[09:14] <lifeless> poolie: yah, meant to stop a tail -f
[09:15] <lifeless> poolie: i've backed up the data and am finishing by hand :(
[09:43] <jonoxer> Noob question #47: does bzr support something analogous to svn's "externals"?
[09:44] <ronny> hi
[09:44] <jonoxer> :)
[09:44] <ronny> is there a way to set up aliases for push/pull locations of branches?
[09:44] <bob2> try the bzr-bookmarks plugin
[09:45] <lifeless> jonoxer: not stably; its intended to arrive, but EDEFERRED
[09:45] <lifeless> jonoxer: there is config-manager, which is somewhat similar
[09:46] <jonoxer> lifeless: thanks for the pointers. I'd prefer to avoid it entirely if I can, so I may just restructure our tree a bit anyway
[09:46] <jonoxer> A useful thing to know though
[09:55] <ronny> hmk
[09:56] <ronny> bob2: just needed to figure if it makes sense to have it as part of the generic vcs api in the pida ide (we are about to get a good bzr integration by the gedit-bzr author)
[10:12] <vila> awilkins: trying to scare me ? YOU WON'T ! The reason my wisdom teeth are coming back to haunt me is because I became younger by around 20 years working on bzr, two painful weeks are a drop in the ocean of my felicity :-) fullermd: I'm perfectly happy to *not* have them anymore if that's the price for becoming that young again :)
[10:13] <fullermd> Well, I'd be happier not having them too   :p
[10:19] <Odd_Bloke> poolie: Good job on the release. :)
[10:52] <Odd_Bloke> Where is .bzr.log kept on Windows machines?
[11:04] <james_w> Odd_Bloke: ask "bzr --version"
[11:11] <AnMaster> hm
[11:11] <AnMaster> website for says "Bazaar 1.8 was released on the 16th of October, 2008.
[11:11] <AnMaster> topic says "bzr-1.8 released 17 Oct"
[11:11] <AnMaster> so which one is it?
[11:12] <lifeless> AnMaster: both
[11:13] <lifeless> AnMaster: the world is wide
[11:13] <AnMaster> lifeless, which timezones?
[11:13]  * AnMaster consider it from UTC
[11:13] <jonoxer> spiv, poolie, lifeless: thanks to all your assistance I now have 1.1M lines of code migrated from svn to bzr   :-)
[11:13] <lifeless> AnMaster: yeah I think different folk looked at the clock ~ the same time
[11:13] <lifeless> jonoxer: sweet
[11:13] <poolie> jonoxer: sweet
[11:13] <poolie> goodnight!
[11:13] <jonoxer> night!
[11:17] <AnMaster> lifeless, so what day was it in UTC?
[11:17] <lifeless> AnMaster: I don't know, I'd have to think
[11:18] <AnMaster> lifeless, well what time was it in second since epoch then? ;P
[11:18] <lifeless> AnMaster: right now, its the 17th where I am
[11:18] <AnMaster> so it is here
[11:18] <AnMaster> 12:18
[11:18] <AnMaster> and that is UTC+2 currently
[11:21] <AfC> "It was the dawn of the 3rd Age..."
[11:21] <AnMaster> heheh
[12:07] <ronny> hmm, does the threadlocal chdir issue of bzr 1.8 affect linux?
[12:49]  * lamont wonders how soon 1.8 will land ar launchpad.net/~bzr/+archive
[12:49] <lamont> at, even
[12:50] <Odd_Bloke> poolie is most likely to know (IMPLICIT PING).
[12:51] <lamont> Odd_Bloke: OTOH, he called g'night almost 2 hours ago
[12:52] <Odd_Bloke> Then I'd expect it tomorrow sometime. :)
[12:55] <lamont> which means I'll probably worry about it on monday or so
[12:56] <lamont> though it's only 2355 in Sydney right now..
[12:56] <Odd_Bloke> Yeah, I probably meant Monday by 'tomorrow', now that I recall that it's Friday.
[12:58] <lamont> and fwiw, the topic change occurred at 0812 UTC, so there wasn't much of the world left where it was Oct 16
[14:08] <vila> jam: ping, regarding bug #277537 I can't understand if we agree or not, chatting seems easier to sort that out, pong me back when you're available
[15:13] <jam> vila: sure let's chat about it for  bit. I'll need to go in about 30min, but then I'll be back later
[15:13] <jam> I think what you've done is probably fine (and probably what 'reconcile' would have done anyway)
[15:13] <vila> ok
[15:13] <jam> my concern is that code like 'annotate' isn't ready for it
[15:14] <jam> but we want to make the code handle it anyway
[15:14] <vila> My understanding is that you're right but time shifted
[15:14] <vila> the bug already shows that annotate isn't ready for it
[15:15] <vila> fixing the repo seems to please annotate very much
[15:17] <vila> Does that make sense ?
[15:17] <jam> vila: I think you are misunderstanding my concerns with annotate. And if *I'm* wrong then it seems something much more serious is going on
[15:17] <vila> That's I wanted to chat, there are surely grey areas for me
[15:17] <jam> Looking at the annotate code, I'm 95% sure that it assumes that the compression_parent == parent_ids[0]
[15:17] <jam> (left-hand parent)
[15:18] <vila> Did you read my replies ?
[15:18] <jam> I haven't got to that yet, I'll look
[15:19] <vila> I agree with you on that part but I wonder if annotate is not getting these parents but some others and then assuming they are the same. In that case your diagnosis *is* already correct about the matching blocks use
[15:21] <vila> I also agree that if my fix (modulo the tweak for more than 2 refs) is correct but incomplete then we have a bigger problem because reconcile use that same way to fix inconsistent parents
[15:21] <jam> vila: well the patch to annotate should be merged regardless
[15:22] <jam> When I look at my local graph, I didn't see a single case where 'compression_parent' wasn't parent_ids[0]
[15:22] <jam> which is why it seems weird that swapping it, which *should* break annotate actually ends up "fixing" annotate
[15:23] <jam> vila: I'm also rather positive that the converter isn't actually to blame, but the version of bzr that was used during conversion
[15:23] <jam> this was a known bug in bzr
[15:23] <vila> which is why I suggest that annotate is not using the compression_parent
[15:23] <jam> which is why reconcile already tries to fix it
[15:23] <jam> and the reason to make _generate_text_key_index faster is just to make 'reconcile' *usable*
[15:24] <jam> 30+hrs isn't in the very usable category
[15:24] <vila> 1) we should clearly identify the oldest bzr version that fixes that
[15:25] <vila> 2) check is 32 hours, reconcile is 20 hours, as I said I think we should keep them that way and focus elsewhere
[15:26] <vila> and make sure they are never needed
[15:26] <vila> I don't have a problem with a verification tool that take days if it save *me* days
[15:28] <vila> but anyway, I think this bug should be fixed without requiring users to update bzr so even if we optimize check/reconcile they won't be able to use them
[15:29] <jam> so, #1 I think your plugin is probably fine
[15:29] <jam> #2 I think we need a better understanding of what is going on in annotate
[15:29] <vila> ha, ok, I was unsure about that
[15:29] <jam> because it doesn't fit *my* mental model
[15:29] <jam> and I've been neck deep in it for a long time
[15:30] <vila> I respect that and share the concern
[15:30] <jam> looking at bzrlib/knit.py line 955, we pull 'compression_parent' directly from '_index.get_build_details()'
[15:30] <jam> so I'm quite sure it is getting the info from the file graph
[15:31] <jam> sorry, the line in question is 2587
[15:31] <jam> but it is doing the same thing
[15:32] <vila> compression_parent is not changed by my fix
[15:32] <jam> vila: yeah I know, which is why it is getting weird
[15:32] <vila> where are the parents coming from ?
[15:32] <jam> I'd like to try just always setting "left_matching_blocks = None" and see what that does
[15:32] <jam> so... _KnitAnnotator should be completely focused within the per-file graph
[15:33] <jam> and not know anything about the whole tree graph
[15:33] <vila> tell me where, I have buggy and fixed repos at hand
[15:35] <jam> bzrlib/knit.py has the _KnitAnnotator code
[15:35] <jam> alternatively, you can go to bzrlib/annotate.py
[15:35] <jam> and in the "reannotate()" function
[15:35] <jam> just set the 'left_matching_blocks = None'
[15:35] <jam> right at the beginning
[15:40] <vila> I fired 4 gblames, setting left_matching_blocks to None has no effect
[15:41] <jam> vila: did you try "_left_matching_blocks" I was missing the underscore
[15:41] <vila> yes
[15:43] <vila> I just checked I used the right bzr by adding a print '_left_matching_blocks set to None'
[15:43] <jam> so, I probably need to swap back some state in my head to test it here.
[15:44] <jam> can you link the rev-ids that are 'correct'?
[15:44] <jam> I think: sp1r-anozdrin/alik@quad.opbmk-20080322080224-35901
[15:44] <jam> is  correct revision
[15:44] <jam> and merging it with sp1r-anozdrin/alik@quad.opbmk-20080322083224-09299
[15:44] <jam> broke it in the ancestry
[15:44] <jam> but doing it manually gives the "right" answer
[15:45] <jam> vila: does that sound right to you?
[15:45] <vila> yes
[15:45] <vila> err no wait, let me check
[15:47] <vila> jam: checked, yes
[15:48] <jam> k, I'm working on reproducing here, give me  a sec
[15:49] <vila> But I mentioned that the "right" answer is not as right as I thought, my fix reveals different annotations (because that file has 71 inconsistent parents in its ancestry, the manual merge fix only one pair out of the 71)
[15:53] <jam> vila: sure, I just want *a* test case :)
[15:53] <jam> Even if it is only this one hunk
[15:53] <jam> What I'm seeing is:
[15:53] <jam> _left_matching_blocks was already None
[15:53] <vila> ok, so the manual merge gives the right one
[15:53] <jam> And no case where _left_matching_blocks was not None
[15:54] <jam> which is really weird
[15:54] <vila> Haaa, at least it explains your misunderstanding ! We're making progress :)
[15:54] <jam> anyway, I have to go right now, but I'll be back later
[15:54] <jam> I'll also mention that there are no cases of: print "compression parent is not left-parent: %s, %s" % ("
[15:55] <vila> ok, don't forget  that you're using a *weird* repo, that could explain the weirdness
[16:36] <maestrolinux> http://s2.ar.bitefight.org/c.php?uid=19732
[16:49] <jam> vila: so the reason _left_matching_blocks is None is because of the code to check about using "_fallback_vfs"
[16:50] <jam> and that is because someone hijacked it in bzr.dev:
[16:50] <jam> if True or len(self._knit._fallback_vfs) > 0:
[16:50] <jam>     # stacked knits can't use the fast path at present.
[16:50] <jam>     return self._simple_annotate(key)
[16:50] <jam> Note the "if True" portion
[16:50] <jam> ugh
[16:51] <vila> I remember reading that but thought it was intended :-/
[16:52] <jam> vila: no, we found that annotate was a lot slower, so poolie brought in the "if len() > 0"
[16:52] <jam> I think he forgot to take out the "if True" block
[16:52] <jam> Merge unoptimized annotate code for stacking, and only use it when needed
[16:52] <jam> is the comment for that line
[16:52] <jam> poolie: shame on you. I trusted you :)
[16:54] <jam> vila: so it could be a bug in the '_simple_annotate' code
[16:54] <jam> which is why they aren't getting the right ordering
[16:54] <vila> Didn't you tell me one day that you used to check what code was checked in ? :-P
[16:55] <jam> vila: before we had 30 patches a week, yeah. I would read the diff everytime I did 'bzr up'
[16:55] <vila> yes, it's on the path, I have some commented out import pdb; pdb.set_trace() there
[16:55] <vila> jam: you should know better than quitting good habits
[16:56] <vila> So, does that path get different parents than the pack index ones ?
[16:57] <jam> vila: I'll have to look
[16:57] <jam> it doesn't *look* like it does, but lifeless wrote that code
[16:58] <jam> vila: try takeing out the "if True" and see if we get different results
[16:58]  * vila taking out the 'True or' instead :)
[17:00] <jam> I seem to get the same results
[17:00] <jam> I just get them a bit faster :)
[17:01] <vila> no difference for broken repo, tracenack for fixed repo :-/
[17:02] <vila> AssertionError: mismatched new_lines and annotated_lines
[17:04] <jam> vila: I'm glad we at least caught the bug
[17:05] <vila> can't reproduce o_O
[17:06] <jam> vila: can't reproduce?
[17:06] <jam> (it is still giving bad results, but it gives them in 1.3s instead of 2+)
[17:06] <vila> I traceback once but not twice...
[17:06] <jam> vila: different files?
[17:07] <jam> vila: the check is: if len(new_lines) != len(annotated_lines):
[17:07] <vila> nope, same exact command
[17:07] <jam> So there has to be a line length mismatch or we won't catch it
[17:07] <jam> Though I don't see any reason it would be a heisenbug
[17:07] <vila> I know after the traceback I changed the format to display the lens and since then the traceback vanished...
[17:08]  * vila check ghosts
[17:08] <jam> vila: I would check your modification to make sure you aren't overwriting a variable, etc.
[17:08] <vila> I reverted it !
[17:12] <vila> Ok, wrong shell, got it back:
[17:12] <vila> AssertionError: mismatched new_lines (732) and annotated_lines (721)
[17:15] <jam> vila: I'm sending a patch to the list which fixes these 2 things with the annotate code.
[17:15] <jam> And then I'll try to debug why we are getting the wrong annotations regardless
[17:15] <jam> as 'reannotate' shouldn't really care whether a text is the left or right parent.
[17:17] <vila> hold on
[17:18] <vila> If my fix is wrong it means reconcile is wrong too, you understood something I don't here :)
[17:20] <vila> jam: and I fixed only one thing: 'deleting the True or' what is the second one you're referring to ?
[17:20] <jam> vila: the first fix is "True or" the second fix is changing the 'fast path' code to not re-use a matching block if compression_parent isn't the left-parent
[17:21] <jam> so it should not trigger the AssertionError
[17:21] <jam> vila: can you apply the patch and make sure 'bzr annotate' works properly after your reconcile
[17:29] <vila> jam: ok, it fixes the traceback (pfew)
[17:30] <vila> I suppose your fix will have an impact on the 80s slow annotate case, no ?
[17:38] <jam> vila: right, it drops from 60s => 16s on my machine
[17:39] <vila> yeah, two birds with one stone ;)
[17:39] <jam> vila: well, it still doesn't give the correct result for their "broken" repo
[17:40] <vila> true, but my fix address that
[17:41] <vila> Are you sure annotate doesn't recalculate the parents with another source ?
[17:42] <vila> I never looked at the code path that is active now so my prior experiments are useless now
[17:44] <jam> vila: they both go through "reannotate()"
[17:44] <jam> it is just that one does a lot of work to pass in 'left_matching_blocks" when it can
[17:44] <jam> as well of other work to be memory friendly
[17:44] <vila> My tooth (or rather its lack now) is waking up again. 6 hours is definitely the time it takes for Advil to become ineffective :-(
[17:44] <jam> and go in pack read order
[17:45] <jam> vila: feel better with more drugs :)
[17:45] <vila> I hate that but has done it for the last two weeks ;(
[17:47] <vila> Hmmm, your patch may not be active after my fix (except the blocks = None) , let me check
[17:47] <vila> rats, I need a more sophisticated breakpoint
[17:53] <jam> so.. I'm trying to look more closely at the parent ordering thing. The first thing that I see is that it seems this particular code block is *repeated* inside one of the parents
[17:53] <vila> Indeed, when annotating in a broken repo I stop after compression_parent == parent_ids[0], but not with a fixed repo
[17:54] <vila> Indeed, when annotating in a broken repo I stop after compression_parent == parent_ids[0], but I don't with a fixed repo
[17:55] <jam> vila: so *with* my patch and the old repo it is breaking?
[17:56] <vila> jam: yes
[17:57] <jam> hmm... it gives the 'bad' results but it works here
[17:58] <jam> so... I think we have a case of a code block being moved, and that confusing the annotation code
[17:58] <jam> if it gets one parent first, it lines up this particular portion
[17:58] <jam> if it gets the other parent it gets a different alignment
[17:58] <jam> and then can't match this portion because it considers it moved
[17:58] <jam> still investigating
[18:00] <jam> vila: but I'm thinking... fixing the per-file graph will make "bzr diff" use the same texts as "bzr annotate". but both annotations are legally correct
[18:01] <jam> because there is an ambiguity in the system
[18:02] <vila> The bug report was about annotate giving a different result than diff and *that* was the problem
[18:03] <jam> vila: though if you did "bzr diff" versus the other parent you would agree with annotate
[18:03] <jam> I'm fine fixing the graph, I just wish our diff an annotate could handle moved blocks a bit better
[18:04] <vila> Be aware of the conclusions you draw from the "manual" merge, the annotations it gives are far from the one I can see with a fixed repo, may be you try to get one  (it's only 312 seconds away ;-)
[18:05] <vila> Be aware of the conclusions you draw from the "manual" merge, the annotations it gives are far from the one I can see with a fixed repo, may be you should try to get one  (it's only 312 seconds away ;-)
[18:05] <vila> I leave now, I'll check later or even pass a bit if I'm in better shape
[18:12] <jam> vila: rest well
[18:24] <jfroy|work> jelmer: you do use launchpad for bug reports, right?.
[21:21] <jfroy|work> jelmer: new failures this morning since I updated bzr and bzr-svn to the latest trunk revision
[21:21] <jfroy|work> AttributeError: 'CachingRevisionMetadata' object has no attribute 'generate_revision_id'
[21:59] <fynn> how do I get a list of all monitored files in a repo?
[22:02] <fynn> "bz ls" seems to show non-monitored files and directories as well, at least at the top-level.
[22:03] <fynn> OK, "bz ls --versioned" seemed to do the trick...
[22:20] <jfroy|work> I am getting a "bzr: ERROR: A nested progress bar was not 'finished' correctly." exception when running a merge command...
[22:20] <jfroy|work> Any ideas?
[22:37] <lifeless> jfroy|work: file a bug, and you could try running with PDB=1 if you want to analyse the cause yourself
[22:41] <jfroy|work> I tend to ask in IRC before filing bugs, in case it's a "duh don't do that" :p
[22:44] <lifeless> jfroy|work: sure; I didn't criticise your asking :>
[22:44] <jfroy|work> I didn't mean it as a rebuttal, sorry if it sounded that way. Your advice is, of course, well founded and appreciated :)
[22:45] <lifeless> :)
[22:45] <lifeless> anyhow it smells like a bug
[22:45] <lifeless> probably a rare code path not cleaning up well
[22:54] <lifeless> win 40