| lifeless | spiv: so, I'm nearly human again | 00:14 |
|---|---|---|
| lifeless | spiv: want to pop over? | 00:15 |
| spiv | lifeless: to Epping? Sure. | 00:16 |
| lifeless | cool | 00:16 |
| spiv | I'll finish humanising myself and head over. I'll let you know my eta. | 00:16 |
| lifeless | kk | 00:16 |
| === kiko-fud is now known as kiko-zzz | ||
| lifeless | Odd_Bloke: if you're looking at bzr send | 00:33 |
| lifeless | Odd_Bloke: apparently we should us xdg-email | 00:33 |
| lifeless | *use* | 00:33 |
| Odd_Bloke | lifeless: My next few cycles are going to be spent looking at shelf. | 00:36 |
| Odd_Bloke | s/shelf/shelves/ | 00:36 |
| r0bby | yeh if only i initialized the String :x | 00:36 |
| r0bby | that wouldn't have made it less wrong | 00:36 |
| Odd_Bloke | r0bby: Wrong channel? :) | 00:37 |
| Odd_Bloke | What's brisbane-core? I keep seeing references to it, but missed the kicking off point. | 00:37 |
| lifeless | Odd_Bloke: next gen format | 00:41 |
| ronny | is there any schema on how the database of the in bzr works? | 00:42 |
| ronny | (and if there are ways to extend it) | 00:42 |
| lifeless | ronny: you can't really extend the core (though you can use it to do different things for you) | 00:42 |
| lifeless | ronny: in terms of docs, there are the Classes stuff on the wiki, and docstrings in the code - pydoctor gives quite good results on that I believe | 00:43 |
| ronny | hmm, any listing ? i missed the stuff in the wiki | 00:44 |
| lifeless | http://bazaar-vcs.org/Classes | 00:47 |
| spiv | lifeless: eta 1220 | 00:56 |
| lifeless | roger wilco | 00:57 |
| ronny | lifeless: at what part of the src should i look? | 00:58 |
| lifeless | ronny: well, what are you interested in? If you're interested in the 'db' implementation, btree_index, knit.py (the pack mapped index and access objets), and repofmt/pack_repo.py's RepositoryPackCollection class) | 01:00 |
| ronny | lifeless: mainly the db stuff | 01:01 |
| lifeless | if you're more interested in the model, I don't think there is a single good reference | 01:01 |
| ronny | the model is important for me, too | 01:01 |
| ronny | just researching the different stuff | 01:01 |
| lifeless | I'd cast an eye over doc/developers/ | 01:01 |
| ronny | so far git's model seems the most reasonable | 01:02 |
| ronny | just the rest of git isnt | 01:02 |
| lifeless | :P | 01:03 |
| ronny | any reason why bzr did choose uuid's over content hashes other than the rehashing (aka switch hash algo) issue? | 01:05 |
| * ronny waves for attention | 01:12 | |
| mwhudson | well, bzr-svn includes more information in the uuid | 01:13 |
| * RAOF is by no means a bzr hacker, but IIRC it allows better tracking of file moves. | 01:13 | |
| ronny | RAOF: nope, not at all | 01:14 |
| ronny | mwhudson: like what? | 01:14 |
| mwhudson | ronny: uuid of the repository + revno of the import | 01:15 |
| ronny | ok, also nothing that would reqire a uuid | 01:15 |
| mwhudson | i think it's more a matter of style of approach than requirement | 01:17 |
| mwhudson | but way way before my time | 01:17 |
| ronny | RAOF: git's bad move tracking is derived in the fact that trees dont have parents, thus the parent/child relation is only in commits | 01:18 |
| ronny | so any comments? | 01:26 |
| Odd_Bloke | ronny: I'm not sure the IRC channel is the most appropriate place to look for this kind of discussion. The mailing list might be better... | 01:31 |
| ronny | hmk | 01:32 |
| ronny | i mostly just want to know the reason tho, not discuss it over again | 01:33 |
| Odd_Bloke | ronny: I still think a post to the ML is most likely to get a useful response. | 01:33 |
| Odd_Bloke | Anyway, I intended to go to bed half an hour ago. | 01:34 |
| Odd_Bloke | So, good night #bzr. | 01:34 |
| lifeless | ronny: we chose uuids for revisions for a couple of reasons; not wanting to redo everything when sha1 is broken, and supporting imports from arbitrary systems is the other (and its been very susccessfuly) | 01:34 |
| lifeless | ronny: for file ids, we use uuids as a memo, but equally could use just history pointers | 01:34 |
| ronny | hmm, why does import from others require uuid's? | 01:36 |
| lifeless | ronny: transitive history is not always available | 01:41 |
| ronny | i dont see how that makes uuid's an requirement | 01:43 |
| ronny | i need to sleep | 01:44 |
| mwhudson | oh that's right, ghosts | 01:44 |
| mwhudson | i always forget that one... | 01:45 |
| jelmer | not just that | 01:49 |
| jelmer | having to calculate the contents in the native format for all contents in the ancestry of a revision is expensive | 01:50 |
| jelmer | never mind, just read up on what transitive means :-) | 01:52 |
| mlh | ronny's design questions remind's me that poolie's design notes used to be available somewhere | 01:57 |
| mlh | like old.bazaar-vcs.org or bazaar-vcs.org/old (I've checked there) | 02:00 |
| spiv | mlh: http://doc.bazaar-vcs.org/obsolete-docs/ ? | 02:01 |
| mlh | thanks spiv | 02:02 |
| mlh | that's an excellent historical document. I remember meaning to give that link to ESR when he was going to (threatening to ? :-) write a history of (D)VCSs | 02:02 |
| * igc lunch | 02:20 | |
| lifeless | jml: we need to spend a few hours on 'how to represent skip etc for .unittest | 02:21 |
| lifeless | ' | 02:21 |
| jml | lifeless: yes. | 02:22 |
| jml | lifeless: in fact, a mini-sprint on pyunit-friends stuff would probably be a Good Thing | 02:22 |
| jml | lifeless: let's go to Perth and visit jamesh :) | 02:22 |
| lifeless | jml: :P | 02:33 |
| jamesh | lifeless: that reminds me. I uploaded a testresources branch implementing the make/reset/clean API I suggested. | 02:34 |
| lifeless | yes, its in my aroundtuit pile :( | 02:34 |
| jamesh | you said my original description was a bit hard to understand, so maybe some code will make it clearer :) | 02:35 |
| lifeless | thank you | 02:35 |
| jamesh | and I don't know whether you'd want to come to Perth at this time of year. It may be a bit dryer, but it is also a lot hotter | 02:39 |
| lifeless | jamesh: yeesh, don't need more heat | 02:47 |
| lifeless | jml: I was thinking dinner, wine, laptops | 02:47 |
| jml | lifeless: sounds delightful | 03:19 |
| === mthaddon_ is now known as mthaddon | ||
| lamalex | Can I version a single file only? For example I want to keep my .emacs file in sync across a few computers, is there a simple way to do this? | 03:58 |
| lifeless | lamalex: bzr init ~/my-emacs | 03:59 |
| lifeless | mv ~/.emacs ~/my-emacs | 03:59 |
| lamalex | lifeless: so "no" | 03:59 |
| lifeless | ln -s ... | 03:59 |
| lifeless | lamalex: yeah, sorry | 03:59 |
| lamalex | no problem | 03:59 |
| lamalex | it's not the point of bzr | 03:59 |
| lamalex | that will probably be cleaner anyway, I'll just make a dir of my misc files, then link to them | 04:00 |
| bob2 | sure, cd ~/ ; bzr init ; bzr add .emacs ; bzr ignore ".*" ; bzr ignore "*" ; bzr commit | 04:00 |
| lamalex | can someone help me set up a shared repo? I can't get it to not do working trees in the repo | 04:39 |
| bob2 | bzr init-repo --no-trees | 04:39 |
| bob2 | you can alias init-repo to 'init-repo --no-trees' if you like | 04:39 |
| lamalex | :P as soon as I asked i got it | 04:42 |
| lamalex | thanks | 04:42 |
| lifeless | vila: your --load-list is quite nice, thank you | 04:53 |
| * jml <3 branch-todo | 04:53 | |
| lifeless | jml: ? | 04:54 |
| jml | lifeless: I'll explain later :) | 04:54 |
| lifeless | jml: I have a feedback loop going with tests | 04:56 |
| lifeless | jml: bzr selftest --load-list=foo.list, where foo.list is from selftest --subunit | subunit-filter | tail -n +2 > foo.list | 04:57 |
| lifeless | jml: 'run only failing tests' | 04:57 |
| jml | lifeless: *nod* that'd be very handy to have for lp | 04:58 |
| lifeless | I'll do some more on it this evening I hope | 04:59 |
| lifeless | would likst to get foo.list by $() rather than a file on disk, or something like that | 04:59 |
| lifeless | jml: so, see my most recent post to bazaar@, it has the glue needed for a pyunitish runner | 05:09 |
| jml | lifeless: cool | 05:10 |
| ronny | moin | 06:37 |
| * ronny still fails to see how transitive history needs uuid's | 06:38 | |
| ronny | mlh: thanks | 06:53 |
| lifeless | jml: what are you doing tomorrow evening? | 06:59 |
| vila | hi all | 07:03 |
| vila | lifeless: glad you like it :-) | 07:03 |
| dholbach | hiya | 07:41 |
| dholbach | pushing a branch to LP with bzr 1.11-1 I get "Permission denied (publickey)" although my pub key is exactly the same as the one I have on LP | 07:42 |
| dholbach | is there any known issue? | 07:42 |
| mthaddon | dholbach: sure you're connecting as the right username? | 07:44 |
| dholbach | mthaddon: I don't think I changed anything | 07:45 |
| dholbach | email = Daniel Holbach <daniel.holbach@canonical.com> | 07:45 |
| dholbach | launchpad_username = dholbach | 07:45 |
| mthaddon | dholbach: ok, just checking - not sure if it's a known issue, haven't used bzr 1.11-1 myself | 07:45 |
| dholbach | it's in jaunty now | 07:46 |
| mthaddon | brave soul - still on intrepid here | 07:46 |
| dholbach | where do I use "-Dhpss"? | 07:47 |
| dholbach | it tells me to use it | 07:47 |
| dholbach | argh, now it worked | 07:48 |
| dholbach | ok... whatever | 07:48 |
| dholbach | I'll let you know when I run into it again | 07:48 |
| mthaddon | I won't be much use - not an expert in any way, just happened to be idling here... | 07:49 |
| mthaddon | but I'm sure someone else will | 07:49 |
| jml | lifeless: travelling to Hobart | 07:52 |
| vila | poolie: ping | 07:58 |
| spiv | lifeless: you'll be happy to know I have a working right arrow key again. | 09:16 |
| lifeless | spiv: cool | 09:21 |
| lifeless | spiv: you hit it harder? | 09:21 |
| lifeless | jml: well then, upon your return | 09:21 |
| fullermd | Obviously, it started acting right :p | 09:21 |
| spiv | lifeless: if by "hit" you mean "took the cap off and removed a pile of impacted crud", then I guess so... | 09:25 |
| spiv | It doesn't quite like new, but it basically works... | 09:26 |
| mbp__ | hello spiv, lifeless | 09:27 |
| mbp__ | lifeless: thanks for the post this morning about gc | 09:29 |
| fullermd | I've managed to not have to do a significant keyboard cleaning on this one yet. Next month is its 18th birthday, too. | 09:30 |
| mbp__ | kiko, i'm writing up http://bazaar-vcs.org/Roadmap/BrisbaneCore | 09:30 |
| * fullermd should throw a party. | 09:30 | |
| mbp__ | wow | 09:30 |
| mbp__ | fullermd: it must even predate PS/2 connectors? | 09:31 |
| fullermd | Wikipedia says PS/2 was 1987. | 09:31 |
| fullermd | But the cable is detachable, so it could have come with an AT connector originally I guess. | 09:32 |
| === kiko-zzz is now known as kiko | ||
| mbp__ | kiko ^^ | 09:34 |
| kiko | I don't know a lot about PS/2 but brisbane sounds like just the place for summer | 09:34 |
| * fullermd recalls laughing his head off at http://ars.userfriendly.org/cartoons/?id=20010211 | 09:37 | |
| kiko | mbp__, can you tablify that? tables beat lists | 09:57 |
| kiko | well maybe.. hmm | 09:57 |
| mbp__ | for the tasks? | 09:57 |
| mbp__ | working on it | 09:57 |
| kiko | maybe | 09:57 |
| mbp__ | at least a table is better if we have estimates | 09:57 |
| kiko | indeed, indeed | 09:58 |
| mbp__ | at the moment i'm adding more descripiton of the changes and digging up some numbers | 09:58 |
| mbp__ | yay numbers | 09:59 |
| mbp__ | the infallible indicator of objective truth :) | 09:59 |
| fullermd | Except 8. I don't trust him. Shifty eyes and all that. | 10:04 |
| Toksyuryel | and 13 | 10:05 |
| Toksyuryel | unlucky n' such | 10:05 |
| fullermd | Yeah, but it's reliably unlucky. So it's infallible in a way :p | 10:05 |
| awilkins | Yegods, this "Python DVCS comparison" thread is long | 10:07 |
| awilkins | I think the attitude that "We want all the benefits of a DVCS without changing how we work" attitude is rather blinkered though | 10:08 |
| fullermd | If only that were the most blinkering I ran across in a day... | 10:09 |
| AfC | But it's worse than that - many people have already fought the learning curve to learn git, and now we seem both cumbersome and slow as a result. | 10:09 |
| Odd_Bloke | awilkins: I dunno, we claim to be flexible, but are we actually? | 10:10 |
| Odd_Bloke | (I think so, but maybe we could be more flexible) | 10:10 |
| fullermd | Considering that the complaints all seem to boil down to "TOO flexible", how would that help? :p | 10:11 |
| Toksyuryel | that's a silly thing to complain about though | 10:11 |
| Toksyuryel | if you don't want to use the flexibility, don't | 10:11 |
| fullermd | It's a silly world. | 10:11 |
| AfC | I suspect a global [per user, anyway] revision cache would help enormously. | 10:11 |
| AfC | bit late now, though | 10:11 |
| Toksyuryel | it's not foisted on you | 10:11 |
| fullermd | I don't see it, personally. | 10:11 |
| fullermd | To be much use, it would have to be several times the size of a "large" project. Otherwise anything you want would be cycled out by the time you'd profit from it. | 10:12 |
| fullermd | And that's *BIG*. | 10:12 |
| AfC | fullermd: (if you're talking to me) no, I'm not talking about in-memory, I'm talking about never ever forcing someone to network transfer the same revision twice in from a remote location. I imagine `bzr init-repo ~` would do it. | 10:13 |
| fullermd | Of course, the solution to the direct problem is "If you want to work just like svn, just use co --lightweight". Then we can move on to "zomfg that's slow" and make forward progress on letting them keep marching toward the cliff. | 10:13 |
| fullermd | I don't mean in-memory, I mean wherever; it would have to be a couple gig at least to get a high enough hit rate to be worth it. I don't have a could gig to spare. | 10:14 |
| AfC | fullermd: but since that isn't what the Bazaar hackers expect you to do, it's not a good idea to suggest. | 10:14 |
| fullermd | And "Use bzr, it'll keep anything you ever pass to it around forever cluttering your hard drive" isn't the best advertising either :p | 10:15 |
| AfC | fullermd: assume for a minute you don't know about a) shared repos and b) creating local mirrrors of remote branches. Then do bzr log on a large remote branch a few times and you'll start appreciating how awful Bazaar appears to people. | 10:15 |
| AfC | That is, in essence, the critique that the Python crew have levelled, and it has as a result disqualified us. | 10:16 |
| fullermd | Did I say something that gave the impression that I fail to appreciate how awful performance is in many cases? | 10:16 |
| Odd_Bloke | AfC: 'bzr init-repo ~' has a couple of problems. Firstly, it's not a cache (you can't delete ~/.bzr safely), and secondly, as noted on the mailing list, it assumes people work underneath a single directory. | 10:16 |
| AfC | Odd_Bloke: sure. Admittedly, though, most people work under ~ :) | 10:17 |
| * fullermd branches into /tmp with some regularity. | 10:17 | |
| Odd_Bloke | AfC: Windows users don't. | 10:17 |
| AfC | fullermd: I don't really think any of us in this channel qualify as normal users in so far as Bazaar (or any DVCS) is concerned | 10:17 |
| AfC | Odd_Bloke: that's fine. They can `bzr init-repo c:`. Suckers. | 10:18 |
| AfC | ENOSYMPATHY | 10:18 |
| AfC | :) | 10:18 |
| fullermd | Anyway, the solution to logging large remote is to use a dumb server. | 10:18 |
| fullermd | log --limit 10 bzr.dev. sftp: 7 seconds. bzr+ssh: 40 seconds. | 10:18 |
| fullermd | Doesn't help when they branch into d: now does it? :p | 10:19 |
| AfC | fullermd: it doesn't matter that there is a "solution". The problem is that out of the box the way that most people try to use Bazaar turns out not to be wise. So then we tell them how they should use the tool (thus voiding most of the supposed flexibility) and then they bitch at us for being so presumptuous. | 10:19 |
| fullermd | Er. I was being ironic... | 10:19 |
| * AfC has, in essence, given up advocating Bazaar. I'm tired of shouting at the rain. It's too bad we picked bzr because we really appear to be zealots out in left field for using it. | 10:20 | |
| fullermd | You seem to keep getting this impression that I'm defending the status quo and mocking the poor silly users who just don't Get why it's so vital to use the DUMB SERVER to get good performance... | 10:20 |
| AfC | Such a shame, because I'm very happy with it. | 10:20 |
| AfC | fullermd: I would advise against sarcasm in discussions like this. Most people won't get it. | 10:21 |
| AfC | fullermd: especially when we're exploring the question of whether it's too late for this project. | 10:21 |
| fullermd | But back to the thread in question, the activity of hg would be exactly the same; a fresh clone would still pull everything across the network. The activity of git would be example the same; a fresh clone would still pull everything across the network. | 10:22 |
| AfC | fullermd: right, but in the Git case, the *second* transaction would NOT pull everything - or anything - across the network. | 10:22 |
| fullermd | The difference is only when you pull another branch into an existing repo. That brings us back to metabranches. | 10:22 |
| AfC | fullermd: since we support NOT forcing a full mirror since we support anonymous remote operations, we look bad for doing 100s of MB of transfer just to do a log only to force another 100 MB of transfer to run the same command again. | 10:22 |
| AfC | Like I said, too late now. | 10:23 |
| fullermd | Again, what are you trying to convince me of? Have you EVER seen me advocate to ANYBODY to do `log URL`? | 10:24 |
| AfC | fullermd: I'm not talking about YOU. Relax. I'm talking about the tool that you and I both have stuck our necks out for. The tool permits that behaviour, and so people think that's what they're supposed to do, and so they do, and then the tool looks horrible. | 10:24 |
| * fullermd shrugs. | 10:25 | |
| fullermd | I've lost much ability to care about those people. The train has long since pulled out of the station, and it doesn't matter anymore. | 10:25 |
| AfC | fullermd: you're lucky, then. I work in a community where virtually every other project has adopted Git, or will. So I'm odd man out, and suffering for it. | 10:26 |
| AfC | it sucks. | 10:26 |
| fullermd | Projects will use bzr because political forces dictate (like emacs) or somebody with enough clout likes bzr and decides to impose it (like I did). Anybody else will look at it and say "slower than other choices", and game over. | 10:26 |
| AfC | yup | 10:26 |
| awilkins | I use Bazaar because I had a project that needed really good merge support, it's being used by neophytes, on Windows ; hg can't handle the tree because it's too deep for it on Windows, git is too scary | 10:26 |
| awilkins | The performance leaps of bzr between 0.9 and 1.6 on win32 were really gratifying | 10:27 |
| fullermd | On the day when bzr reaches performance parity, it still won't gain much, because then it'll be "the program that's no longer as slow as it used to be" | 10:27 |
| AfC | fullermd: shit, I've been trying that line for over a year now. | 10:27 |
| awilkins | It started off just "ooh, much faster than SVN" and became "wow, that's nice and fast" | 10:27 |
| AfC | fullermd: and indeed, it didn't help | 10:27 |
| AfC | Whatever. It's nice and fast for me. That's good enough. | 10:27 |
| AfC | But as you said, game over. | 10:28 |
| awilkins | You then use it on Linux and go "Holy crap, WTF is windows DOING under the bonnet?" | 10:28 |
| awilkins | The fact that it's written in a langauge I grokked easily enough to pick up was a real plus ; several windows bugs have been fixed that way | 10:29 |
| fullermd | Obviously, the real trick is to slow everybody else down. | 10:29 |
| fullermd | Look how well that strategy has worked for web browsers. | 10:29 |
| awilkins | I'd like to see a 4-way DVCS/SVN benchmark on Windows | 10:29 |
| fullermd | Remember when you refused to move to Netscape 4, because it was a stupidly slow unbelievably bloated pile of crap? | 10:29 |
| awilkins | I'm not sure git would be such a clear winner on Win32 | 10:29 |
| * fullermd laughs in his past self's face. | 10:30 | |
| fullermd | The flaming death for bzr is network. The platform won't affect network that much. | 10:30 |
| fullermd | I'm left with the assumption that, for whatever reason, bzr didn't grab enough mindshare early on, and the manpower deficiency has left it permanently in the hole. | 10:31 |
| Lo-lan-do | I think bzr can still prevail within the "enterprise". | 10:32 |
| Lo-lan-do | It is, after all, easy to use, and seeing how much effort is required to get people to switch from CVS to SVN, getting them to switch to git is going to be *ugh*. | 10:33 |
| Lo-lan-do | Remember not all paid developers are uber-elite geeks :-) | 10:33 |
| awilkins | Linux format had a "bluffers guide to git" this month | 10:33 |
| Lo-lan-do | (And not every VCS user is a developer, either) | 10:33 |
| fullermd | Paid developers do whatever the paymaster says. | 10:33 |
| ronny | hmm | 10:33 |
| fullermd | Heck, we just covered "bzr is way more flexible than everything else". Flexible is kinda the opposite of what enterprise aims for ;p | 10:33 |
| ronny | i came to the conclusion that all dvcs's suck | 10:34 |
| awilkins | What DVCS really needs for use in the enterprise is gui tools with a good visual metaphor for the distributed-ness | 10:34 |
| Odd_Bloke | fullermd: I think Lo-lan-do's point is that it'll be easier to convince the paymaster than the paid developers. | 10:34 |
| ronny | awilkins: i will probably do such a gui tool that manages git/hg/bzr | 10:34 |
| Lo-lan-do | My point was that it took me *years* to get people to use CVS at a previous job, and I left before managing to get them to switch to SVN even though the syntax/UI is identical. | 10:35 |
| fullermd | I dunno if that's true. Really, the business case is pretty much like the open source case. | 10:35 |
| fullermd | You'll never convince the bulk of the project to move to foo. | 10:35 |
| awilkins | I always do think that Tortoise[DVCS] should just be one codebase with backend plugins | 10:35 |
| fullermd | Some group of sufficiently interested and clouted parties will make the decision, and drag everybody else along. | 10:35 |
| ronny | awilkins: im working on such a thing ^^ | 10:35 |
| ronny | the catch is i dont yet have history/sync support implemented ^^ | 10:36 |
| fullermd | bzr's advantages in flexibility and workflow just aren't obvious unless you (a) think carefully about it, or (b)(1) use it for a while without (2) trying to make it act like $OTHER_VCS. | 10:36 |
| fullermd | Performance, however, is trivially easy to test and very easy to natter on about to convince people. | 10:36 |
| ronny | and the comclusion is - all dvcs's suck and are awfull (just less bad than the centralized ones) | 10:36 |
| ronny | -m+n | 10:37 |
| fullermd | So really, there are 3 types of people who end up with bzr. | 10:38 |
| fullermd | (1) the people who are already there | 10:38 |
| fullermd | (2) the people who are drug there by someone with enough persuasive power | 10:38 |
| AfC | fullermd: re your original "flexibility and workflow just aren't obvious unless you (a) think carefully about it, or (b)(1) use it for a while without (2) trying to make it act like $OTHER_VCS", hear, hear | 10:38 |
| fullermd | (3) the people who like VCS's in particular or tools in general enough to spend a lot of time playing and fiddling with the options, and have usecases where the performance is "good enough". | 10:38 |
| ronny | fullermd: i just recently moved some bzr managed projects i inherited to hg cause bzr wont let me do my workflow | 10:39 |
| fullermd | Me, I'm used to using totally superior solutions that most people bypass for mostly ill-thought-out reasons. I run FreeBSD. | 10:39 |
| Lo-lan-do | Is FreeBSD still totally superior? | 10:40 |
| Lo-lan-do | (Genuine question -- it's been years since I last tried it) | 10:40 |
| fullermd | Of course. That penguin doesn't stand a chance against something with horns and a trident. | 10:41 |
| ronny | it certainly has less stupid | 10:41 |
| Odd_Bloke | ronny: What's your workflow? | 10:41 |
| fullermd | I think so, obviously. It's just so much easier to manage long-term. | 10:41 |
| ronny | Odd_Bloke: inherited from using monotone, i want multiple heads in one place, and i dont particulary have to care if they get names | 10:41 |
| fullermd | (now, if we could harness the elastic force of yanking that far off-topic...) | 10:42 |
| ronny | fullermd: bsd seems to be generaly free of micro-otimizing bullshit (compilers evolve for a reason) | 10:42 |
| ronny | bbl, gona eat | 10:42 |
| bob2 | ronny: bzr can do that | 10:52 |
| fullermd | Ono, not this discussion again... | 10:58 |
| === kiko is now known as kiko-afk | ||
| Mez | are nested branches working yet ? | 11:09 |
| ronny | bbl, gona eat | 11:18 |
| ronny | bob2: until collated branches it can do it | 11:19 |
| ronny | eh cant | 11:20 |
| bob2 | ronny: the ui is a bit dodge, but you can do it | 11:26 |
| bob2 | ronny: push to a repository and the tips will just hang around forever. use 'bzr heads' to see the current ones. | 11:26 |
| * fullermd blinks. | 11:27 | |
| fullermd | Using explicit branches is too obnoxious for him, so you suggest grubbing around under the hood instead? :p | 11:27 |
| bob2 | haha | 11:28 |
| ronny | bob2: fuck unnatural hacky in particular unplanned workflows - either it works good or it's useless | 11:28 |
| fullermd | "I'd like a sandwich, but until bzr's bread comes presliced, it's too much trouble." "Well, bzr lets you grind wheat..." | 11:28 |
| bob2 | ronny: ok! | 11:29 |
| ronny | anyway, on the conceptual level i dislike all common dvcs's | 11:33 |
| Odd_Bloke | ronny: How would you do it differently? | 11:34 |
| awilkins | Whoa, python just ate 101% of CPU time doing a bzr-fast-export | 11:36 |
| ronny | Odd_Bloke: collated branches for bzr will mostly solve it | 11:36 |
| awilkins | Is that a known bug in `top` ? | 11:36 |
| Odd_Bloke | awilkins: How many CPUs do you have? | 11:36 |
| awilkins | This is a 1 CPU boxy (with HT) | 11:36 |
| Odd_Bloke | That might do it. | 11:37 |
| Odd_Bloke | I don't really know. | 11:37 |
| ronny | Odd_Bloke: oh, you mean how i would do dvcs different? | 11:38 |
| fullermd | Rounding errors like that are hardly unknown in top :p | 11:38 |
| Odd_Bloke | ronny: Yeah. | 11:38 |
| fullermd | (rather, in stats reporting like that in general) | 11:38 |
| fullermd | Race conditions and observer skew and yada yada yada. | 11:39 |
| Toksyuryel | this has me curious too | 11:41 |
| ronny | Odd_Bloke: gits model is nice, but it needs more metadata | 11:41 |
| ronny | and of course no git around it ;P | 11:41 |
| Toksyuryel | I bet you could write a bzr plugin to do it | 11:41 |
| ronny | no | 11:42 |
| ronny | bzw wont get content addressing | 11:42 |
| awilkins | More like a git porcelain that looks like bzr | 11:42 |
| awilkins | I dunno, people rate about gitk but I just fast-exported my big branch here and it looks a right mess in gtik | 11:42 |
| awilkins | Maybe I'm not giving it enough hints | 11:43 |
| ronny | duno, git only tracks snapshoots of trees | 11:43 |
| ronny | makes it very messy for tracking history | 11:44 |
| awilkins | Damn.... git _is_ fast | 12:05 |
| awilkins | Just did git reset --hard on my fresh imported repo with no tree - p'chow! | 12:06 |
| Mez | any of the devvies around ? | 12:16 |
| Odd_Bloke | Mez: Don't ask to ask, etc. :) | 12:19 |
| Mez | Odd_Bloke: I asked earlier :D noone responded :D | 12:19 |
| Odd_Bloke | In re: nested branches? | 12:21 |
| Odd_Bloke | I think the short answer is 'no'. | 12:21 |
| Mez | :( | 12:22 |
| Mez | long answer? | 12:22 |
| Odd_Bloke | Real Soon Now. :) | 12:22 |
| * Mez headwalls | 12:24 | |
| Odd_Bloke | I believe LarstiQ is working on it. | 12:27 |
| beuno | Mez, there are very strong rumors that someone will be working on it full time-ish soon | 12:27 |
| beuno | so maybe we'll get that in a few months | 12:27 |
| === asabil_ is now known as asabil | ||
| === bac` is now known as bac | ||
| === kiko-afk is now known as kiko | ||
| mrevell | vila: ping | 14:40 |
| vila | mrevell: pong | 14:41 |
| LarstiQ | Odd_Bloke, beuno: http://bazaar-vcs.org/NestedTreeProgress should be the focal point of nt progress | 14:56 |
| Odd_Bloke | Mez: ^ | 14:58 |
| Odd_Bloke | LarstiQ: Thanks. :) | 14:59 |
| LarstiQ | now, I'm down to a couple of conflicts in merge.py and transform.py, so updating that page is next | 14:59 |
| LarstiQ | we're going to visit my girlfriend's brother now, so ciao :) | 15:00 |
| Odd_Bloke | LarstiQ: Have fun. :) | 15:04 |
| * vila doesn't quite follow how the nested boyfriend comes into play... | 15:10 | |
| === kiko is now known as kiko-afk | ||
| === thekorn_ is now known as thekorn | ||
| jam | morning vila | 16:46 |
| vila | hi jam, stop loonking above my shoulder I am *already* reviewing your patch ! | 16:47 |
| jam | :), I was just saying good morning | 16:47 |
| vila | :) | 16:47 |
| beuno | healthy paranoia | 16:48 |
| jam | well.. paranoia, we can discuss the "healthy" part | 16:48 |
| jam | 8) | 16:49 |
| vila | On my right screen I was looking into bbc tests, I think the first failing ones are for you, but obviously your plate is already pretty full today | 16:49 |
| vila | I say for you because they seem to be related to some '\n' splitting | 16:49 |
| vila | ./bzr selftest -s bzrlib.tests.per_repository_chk.test_supported.TestCHKSupport.test_pack_preserves_chk_bytes_store | 16:49 |
| vila | should include them all | 16:49 |
| vila | -s rocks :-) | 16:50 |
| Goundy | guys I want your advices on organizing my project repository | 16:51 |
| Goundy | I'm writing a server/client gaming suite (for poker atm) | 16:51 |
| Goundy | So I have the client + the server + the project website | 16:52 |
| awilkins | Is it a problem to just have it all in the same tree :-) | 16:52 |
| Goundy | Atm I've two branches: One branch mainline which contains two directotries (client and server) | 16:52 |
| Goundy | and another one for the website | 16:52 |
| awilkins | Why separate client/server branches? | 16:52 |
| Goundy | someone think i can do better ? | 16:52 |
| Goundy | awilkins they're not seperated | 16:52 |
| awilkins | Ah, sorry, | 16:53 |
| awilkins | Misread | 16:53 |
| beuno | Goundy, is the client open source? | 16:53 |
| Goundy | it's the same branche and it contains the sources in different dirs :) | 16:53 |
| beuno | (is the server?) | 16:53 |
| Goundy | beuno all's open source :) | 16:53 |
| Goundy | I'm hosted on launchpad :) | 16:53 |
| beuno | Goundy, then I'd think the separation is good | 16:53 |
| Odd_Bloke | Heh, 'in before'. | 16:53 |
| beuno | client + server on one side, and webpage on the other | 16:53 |
| Odd_Bloke | Goundy: Sounds good to me. | 16:53 |
| Goundy | beuno well I thought the same thing also but guess what a serie can only have one branche :/ | 16:53 |
| Goundy | beuno client and server in the same branch ? | 16:53 |
| Odd_Bloke | Goundy: It does depend how closely linked they all are. | 16:53 |
| Goundy | That's what you're saying ? | 16:54 |
| beuno | Goundy, a LP series you mean? | 16:54 |
| Goundy | beuno yes | 16:54 |
| Odd_Bloke | If the website is going to heavily depend on code from the other branch, maybe you want it in the same branch... | 16:54 |
| Goundy | Odd_Bloke well the link is the networking heh client <> server :è) | 16:54 |
| Goundy | well the website is totaly in xhtml atm | 16:54 |
| Goundy | the server is in C and the client in Java :è) | 16:54 |
| Goundy | The server and the client aren't linked at a source level | 16:55 |
| Goundy | and the website isn't linked to these sources. | 16:55 |
| Goundy | ( https://code.launchpad.net/~auresdev ) | 16:55 |
| Goundy | Here's my current organization | 16:55 |
| Goundy | So you think I'm good keeping it that way guys ? | 16:59 |
| === kiko-afk is now known as kiko | ||
| === bac is now known as bac_lunch | ||
| === bac_lunch is now known as bac | ||
| === thekorn_ is now known as thekorn | ||
| === KangOl_ is now known as KangOl | ||
| jam | vila: yeah, that failing test is because we changed the serialization format, and didn't change it there | 19:23 |
| jam | it isn't really about '\n', just about having another line of data | 19:23 |
| jam | vila: fixed in brisbane-core | 19:28 |
| funkychicken818 | hey | 19:30 |
| funkychicken818 | i have a merge a repository and it want me to run bzr update but i do not want to run the merge i want to simply remove it cause it screws up my files | 19:31 |
| funkychicken818 | and when i try to run a push from another repository i says that nothing has changed | 19:31 |
| funkychicken818 | hello? | 19:33 |
| Demosthenes | regarding nesting, isn't there some support for nesting in bazaar? | 19:39 |
| Demosthenes | i'm trying to model several users with a copy of their own data, centralized into on place for reporting, by pulling from the user branches.... | 19:40 |
| bialix | fullermd: what do you mean by: "(b)(1) use it for a while without" | 19:55 |
| bialix | fullermd: you talk about: "flexibility and workflow just aren't obvious unless you..." | 19:58 |
| lifeless | Mez: its not finished, and I don't know anyone currently developing it | 20:27 |
| === kiko is now known as kiko-afk | ||
| Mez | lifeless: apparently LarstiQ is... | 20:59 |
| Mez | though, by-value should suffice for my needs | 20:59 |
| lifeless | Mez: 'actively' :P | 21:11 |
| lifeless | jam: ping, test_sprout_uses_bzrdir_branch_format | 21:11 |
| jam | lifeless: pong | 21:12 |
| lifeless | vila: "is used as an id by several tests" -> does this load them all, or fail to laod ? | 21:13 |
| lifeless | jam: hi, I replied to the mail | 21:13 |
| lifeless | jam: like to get this bedded down today so I can put the branch (which contains a lot more fixes :P) up | 21:14 |
| jelmer | if somebody could have a quick look at my InterBranch patch, that would help me a lot | 21:14 |
| jam | so what are you trying to change that would cause this test to break? | 21:14 |
| jam | I can sort-of agree that RemoteBranchFormat doesn't contain a lot of info | 21:15 |
| jam | but I don't see why the test would specifically break because of it | 21:15 |
| lifeless | jam: the direct cause is that branch_implementations was testing RemoteBranch using the real branch object | 21:15 |
| lifeless | due to round about things | 21:15 |
| jam | and so it was passing by accident? | 21:16 |
| lifeless | oh yes | 21:16 |
| lifeless | and when I looked at it | 21:16 |
| lifeless | I could see it actually ends up asserting that the proxy object is a proxy object, which while it meets the letter, doesn't meet the spirit | 21:17 |
| jam | so what we want to assert is "source.sprout()" creates a target branch in the type that was initialized by the bzrdir object. | 21:17 |
| jam | I don't know that it matters for Remote | 21:17 |
| lifeless | well sure, because if I sprout into a remote url, I want to copy across still | 21:18 |
| jam | If you push into a remote url, you want to preserve the source format, yes. But that isn't what this is testing. | 21:18 |
| jam | If you push "--stacked" into a remote url | 21:18 |
| jam | you want a stackable format on the target | 21:19 |
| lifeless | what you specifically test though is, 'branch.sprout(a_bzrdir) uses a_bzrdir's branch format' | 21:19 |
| jam | lifeless: right | 21:19 |
| jam | as that is how "branch --stacked" support is implemented | 21:19 |
| lifeless | spiv and I were nearly quoting zork looking through this yesterday :) | 21:20 |
| lifeless | so | 21:20 |
| lifeless | if I change | 21:21 |
| lifeless | self.assertIs(self.branch_format.__class__, target._format.__class__) | 21:21 |
| lifeless | to | 21:21 |
| lifeless | self.assertIs(target_bzrdir.branch_format.__class__, target._format.__class__) | 21:21 |
| lifeless | would that still be correct? It seems more obviously so to me, because its testing the direct behaviour | 21:22 |
| lifeless | rather than relying on the assumption that self.branch_format == target_bzrdir.branch_format | 21:22 |
| jam | umm... if "self.make_bzrdir('target').branch_format != self.branch_format" we have a serious problem with the test permutations code | 21:23 |
| jam | as it means we aren't actually testing the permutations we think we are testing. | 21:23 |
| lifeless | jam: one is backed by a real bzr dir object | 21:23 |
| lifeless | one is completely fictional | 21:23 |
| poolie | hello | 21:23 |
| jam | lifeless: but it is important to be testing the "fictional" apis | 21:23 |
| jam | hi poolie | 21:23 |
| jam | We *need* to be testing that RemoteBranch conforms to the api that the rest of Branch does | 21:24 |
| jam | I could accept that _format members may not be identical, etc. | 21:24 |
| jam | So if you have a case that "X._format != self.branch_format" I can accept that | 21:25 |
| lifeless | jam: get_cloning_metadir gets a real branch format, not a RemoteBranchFormat | 21:25 |
| lifeless | jam: *because* of the way stacking is addressed | 21:25 |
| jam | As long as isinstance(X, ?) is still correct | 21:25 |
| lifeless | jam: so we need to test the apis that are used, not the fictional ones | 21:25 |
| lifeless | jam: self.branch_format is a RemoteBranchFormat; target_bzrdir is a RemoteBzrDir; target_bzrdir.branch_format is a BranchFormat5/BranchFormat6/BranchFormat7 | 21:26 |
| lifeless | hi poolie | 21:26 |
| poolie | hi | 21:27 |
| jam | lifeless: I'm willing to give in to someone who is focused on that portion of the code right now. | 21:27 |
| jam | But if target_bzrdir is a RemoteBzrdir then it seems that target_bzrdir.branch_format *should* be RemoteBranchFormat | 21:27 |
| jam | I need to go pick up my son to be back in time for the standup. | 21:28 |
| jam | I don't want to block you | 21:28 |
| jam | and I'll admit to not having a perfect understanding of what the code should be | 21:28 |
| jam | get_cloning_metadir() probably needs real objects | 21:29 |
| lifeless | jam: I would have thought so to, but then I looked :) | 21:29 |
| lifeless | and cloning_metadir() on remote delegates to _real_bzrdir | 21:29 |
| lifeless | so yes, we end up with real objects being initialized on a remote branch | 21:29 |
| lifeless | one side effect of that is that we initialize via VFS calls | 21:29 |
| lifeless | 100 or so in fact | 21:29 |
| jam | lifeless: which seems incorrect | 21:30 |
| lifeless | andrew and I would like to fix this | 21:30 |
| jam | anyway, I do need to go, bbiab | 21:30 |
| lifeless | ciao | 21:30 |
| * lifeless is fooding | 21:43 | |
| bialix | a while ago I've read the article about dagger fixes. I can't find it anymore with google. Anybody has the link or the saved article text? | 21:44 |
| lifeless | 'dagger fixes?' | 21:44 |
| jelmer | s/dagger/dag ? | 21:44 |
| mwhudson | poolie: can you explain to me the relationship between progresstask and progress bars? | 21:44 |
| lifeless | bialix: oh, 'daggy fixes' | 21:44 |
| bialix | daggy? mmm, perhaps | 21:45 |
| jelmer | bialix: a dagger is a kind of knife IIRC | 21:45 |
| bialix | it sound similar, is not? | 21:45 |
| lifeless | http://monotone.ca/wiki/DaggyFixes/ | 21:45 |
| lifeless | bialix: yes, its a false friend | 21:45 |
| bialix | yes, it's what I need | 21:46 |
| poolie | it is kind of similar, being a pointy bit | 21:46 |
| poolie | mwhudson: um | 21:46 |
| bialix | "daggy" -- queer word | 21:47 |
| mwhudson | poolie: bzrlib.ui.ui_factory.nested_progress_bar returns a task it seems | 21:47 |
| poolie | mwhudson: we used to have just one ProgressBar class | 21:48 |
| bialix | lifeless: thanks | 21:48 |
| poolie | i'm now doing a model:view separation | 21:48 |
| mwhudson | ah right | 21:48 |
| poolie | the model object is a ProgressTask | 21:48 |
| poolie | however some of the apis have not been renamed yet | 21:48 |
| poolie | does that help? | 21:49 |
| mwhudson | yes | 21:50 |
| mwhudson | what launchpad wants to do is intercept all progress reports | 21:50 |
| mwhudson | i just don't quite see how to impose my own progressbar class any more | 21:51 |
| mwhudson | (or indeed, if attacking this at the view level is the right place) | 21:51 |
| mwhudson | it seems like i could do this by overriding _progress_updated in my uifactory, but um | 21:52 |
| poolie | you should provide your own ui | 21:53 |
| poolie | modulo bugs, that should be able to completely replace any concept that progress bars are being drawn on a tty | 21:53 |
| mwhudson | right | 21:53 |
| mwhudson | i'm just not completely sure what this ui should do :) | 21:53 |
| mwhudson | maybe it should override _progress_updated | 21:54 |
| poolie | nested_progress_bar should not be overridden | 21:55 |
| poolie | yes | 21:55 |
| poolie | progress_updated is the main one you should care about | 21:55 |
| mwhudson | the _ scared me off | 21:55 |
| poolie | do you just care about "it's still alive"? | 21:55 |
| mwhudson | yep | 21:55 |
| mwhudson | the process gets killed after 15 mins of inactivity or something | 21:55 |
| poolie | calls to that indicate that it is | 21:55 |
| poolie | um | 21:55 |
| poolie | possibly we should give the ui a chance to return an object upon which progress_updated will be called | 21:56 |
| poolie | ie the view object | 21:56 |
| poolie | but i didn't do that yet | 21:56 |
| poolie | then it would make sense for the model just to be directly constructed | 21:56 |
| mwhudson | you mean get rid of nested_progess_bar? | 22:01 |
| mwhudson | anyway, i'm at least moderately happy as i can delete some code now :) | 22:02 |
| igc | morning | 22:02 |
| jam | poolie: I just missed it, ring again | 22:03 |
| mwhudson | though overriding a _method means that i'll get to do this again in a month | 22:03 |
| poolie | sorry | 22:04 |
| poolie | it is the intended method | 22:04 |
| mwhudson | cool | 22:04 |
| mwhudson | it's hard to distinguish between "don't call this unless you know what you are doing" and "this may go away" | 22:05 |
| lifeless | mwhudson: 'method' is for 'clients of bzrlib use/fully public/fully supported' | 22:05 |
| lifeless | mwhudson: '_method' is for 'for subclassing/private do not use/unsupported use but be ready to update'/ | 22:06 |
| poolie | mwhudson: also and "this is public for subclassing" and "for calling" | 22:06 |
| lifeless | mwhudson: too many bits, not enough space | 22:06 |
| poolie | wot he said | 22:06 |
| lifeless | mwhudson: so ready the docstring, we try to be clear there :) | 22:06 |
| mwhudson | yeah, this says "Should be specialized to draw the progress." | 22:07 |
| mwhudson | so woot | 22:07 |
| poolie | mwhudson: i'd like to come back and clean it up more | 22:09 |
| poolie | will ping you when i do | 22:09 |
| mwhudson | poolie: thanks | 22:09 |
| === bac is now known as bac_afk | ||
| Odd_Bloke | lifeless: I think LarstiQ has been doing some nested tree stuff recently. | 22:14 |
| vila | lifeless: they are loaded, that's how I detect that several ones have the same id (which may be a problem or not, it seems wrong to me in general, but I don't know that it can cause a problem except when one fails and you try to understand which one) | 22:15 |
| Odd_Bloke | He and jelmer were pairing on it at FOSDEM, possibly... | 22:15 |
| lifeless | vila: cool, we should fix them, but not-right-now | 22:15 |
| vila | jam: thks for the fix | 22:15 |
| lifeless | vila: did you see my two patches yesterday (in bzr.dev now) | 22:15 |
| vila | lifeless: if you found same, mail them to me, I'll record them in my TODO list | 22:16 |
| lifeless | vila: the second one has a plugin for bzr/subunit, which you will probably like :P | 22:16 |
| lifeless | vila: '"bzrlib.tests.tree_implementations.test_walkdirs.TestWalkdirs.test_walkdir_versioned_kind(DirStateRevisionTree)" is used as an id by several tests | 22:16 |
| lifeless | ' | 22:16 |
| vila | lifeless: I would like to look at the one around the command, but didn't find th etime yet | 22:16 |
| lifeless | vila: you can just drop the code in the second one into ~/.bazaar/plugins/subunit | 22:16 |
| lifeless | vila: as long as you have subunit installed :P | 22:17 |
| jelmer | subunit \o/ | 22:17 |
| lifeless | jelmer: yeah, I got around to my long threatened 'I should be able to use this with bzr' | 22:17 |
| jam | vila: which fix would that be? | 22:18 |
| vila | subunit appeared on my radar quite strongly today especially the 'reports to the parent as tests begin and end' since I'm currently thinking about parallelizing the test suite... | 22:18 |
| vila | jam: hehe, the bbc one :) | 22:19 |
| jam | ah, yeah no prob | 22:19 |
| jam | are the tests close to all passing now? | 22:19 |
| jam | (did you get poolie's work?) | 22:19 |
| vila | I didn't work much on them I wanted to review igc patch about log multiple files and directory | 22:20 |
| vila | I've seen poolie's work yet | 22:20 |
| vila | In fact, I'm not there, I'm in bed and I sleep :) | 22:21 |
| vila | I've *NOT* seen poolie's work yet | 22:22 |
| vila | grr | 22:22 |
| vila | sleeping indeed :) | 22:22 |
| lifeless | spiv: can I delete FakeRemoteTransport? used in one, disabled, test | 22:22 |
| spiv | lifeless: sounds good | 22:22 |
| poolie | vila, i'll send today i promise | 22:23 |
| vila | poolie: I asked nothing ! I don't even know what you're talking about :-) But I'm curious now... will I be able to sleep ? :) | 22:24 |
| jam | lifeless: I'd like to chat quickly about '\n' delimited chk records | 22:25 |
| jam | vila: poolie did some work on making the test suite pass | 22:25 |
| jam | he claims he made progress | 22:26 |
| jam | nobody else has seen the results :) | 22:26 |
| jam | I think he is secretly planning on actually doing the work | 22:26 |
| jam | and then sending it | 22:26 |
| lifeless | jam: sure thing | 22:26 |
| jam | lifeless: so... I think it is a good decision to use '\n', as it means we don't have to try quite as hard to make a compressor that is not line based | 22:27 |
| jam | my main concern is "compatibility" | 22:27 |
| lifeless | with? | 22:27 |
| jam | I introduced the hash prefix stuff | 22:27 |
| jam | in such a way that we can read -dev4 or hash based ones | 22:27 |
| jam | should I try to do the same for this | 22:27 |
| lifeless | so the hash thing I think thats worth doing, because we're still comparing IMO | 22:27 |
| lifeless | however this \n is trivial its not a strategic decision, if you like | 22:28 |
| lifeless | its should have little to no long term impact | 22:28 |
| lifeless | so JFDI imo | 22:28 |
| jam | k | 22:28 |
| lifeless | twiddle a bit in the dev3 and dev4 disk format labels to stop confusion | 22:28 |
| jam | it makes *my* life a lot easier :) | 22:28 |
| jam | doing it means fixing a lot of serialization dependent tests, so getting the answer up-front is important | 22:29 |
| jam | I sent my hash prefix stuff to the list just now | 22:29 |
| jam | igc: I think I know why you couldn't reproduce bug #328135 | 22:30 |
| ubottu | Launchpad bug 328135 in bzr "bzr init-repos --development-wt5-rich-root gives: "AttributeError: 'module' object has no attribute 'WorkingTreeFormat4'"" [High,Fix committed] https://launchpad.net/bugs/328135 | 22:30 |
| jam | I would guess you had a plugin that did "import bzrlib.workingtree" | 22:30 |
| jam | which was happening *before* the initialize() code was doing it | 22:30 |
| === Guest65438 is now known as mxab | ||
| === mxab is now known as maxb | ||
| jam | I'm not sure why I *don't* have a plugin which does that | 22:31 |
| jam | though I did spend a bit of time to make a couple of my installed plugins a bit more "lazy" | 22:31 |
| igc | jam: interesting. Thank you *so* much for tracking this down | 22:36 |
| jam | igc: you can test yourself with "python -c 'import bzrlib.workingtree_4'" | 22:36 |
| jam | that should break | 22:36 |
| jam | (even with my fix) | 22:36 |
| jam | but at least it isn't user-visible for now | 22:36 |
| igc | jam: yep, that breaks for me | 22:37 |
| jam | lifeless: do you think we need to keep -dev3 around? | 22:37 |
| jam | igc: now, in theory, this would pass "python -c 'import bzrlib.plugin; bzrlib.plugins.load_plugins(); import bzrlib.workingtree_4'" | 22:38 |
| lifeless | jam: I think its clearly substandard, so no | 22:38 |
| jam | lifeless: that was my feeling | 22:38 |
| jam | if I was going to change the format string, I may as well get rid of it | 22:38 |
| lifeless | jam: sure | 22:38 |
| igc | jam: yes, that works | 22:40 |
| jam | igc: there you go :), I assume "bzr init --development-wt5 --no-plugins" would also fail for you | 22:40 |
| igc | jam: yes | 22:42 |
| jam | I believe that should work on the bzr.1.12 branch | 22:42 |
| igc | lifeless: so groupcompress has a minor bug - it needs to import repo_registry before the 'if chk' test | 22:42 |
| igc | lifeless, jam: also, so we please start using WorkingTreeFormat5 in the new dev formats | 22:43 |
| igc | s/so/can/ | 22:43 |
| igc | that will increase testing | 22:43 |
| jam | igc: not by a lot, but sure | 22:44 |
| jam | I'll go ahead and bump everything to v5 | 22:45 |
| jam | just to make it obvious | 22:45 |
| lifeless | jam: have you looked at performance with mmap? | 22:45 |
| jam | lifeless: I have a branch which changes LocalTransport.readv() to use mmap to return the strings | 22:46 |
| jam | My initial tests showed no real difference | 22:46 |
| jam | But I didn't test thoroughlty | 22:46 |
| lifeless | jam: I'd like to try minimising the open() calls | 22:46 |
| jam | lifeless: yeah, it cached the mmap | 22:46 |
| jam | and then trapped for rename(), tec. | 22:46 |
| lifeless | ok call | 22:46 |
| lifeless | ok cool | 22:46 |
| jam | lp:~jameinel/+junk/bzr-mmap-readv | 22:47 |
| igc | jam: were you going to send the development-wt5 to bzr.dev or wait for poolie to merge the 1.12 changes across? | 22:47 |
| jam | It does a "trace.note()" when used | 22:47 |
| jam | just to be sure | 22:47 |
| jam | igc: I was just waiting for 1.12 | 22:47 |
| jam | since it is ~today | 22:47 |
| igc | jam: np. I'll update the bug report to say as much | 22:48 |
| lifeless | do teams have +junk? | 22:49 |
| lifeless | spiv: so, the disabled test turns out to be one that would have trapped the double get_stacked_on verb call :) | 22:52 |
| Demosthenes | regarding nesting, isn't there some support for nesting in bazaar? | 22:52 |
| Demosthenes | i'm trying to model several users with a copy of their own data, centralized into on place for reporting, by pulling from the user branches.... | 22:52 |
| Demosthenes | the master doesn't seem to like committed when subdirs are branches. | 22:54 |
| Demosthenes | er, committing | 22:54 |
| lifeless | Demosthenes: there isn't user-ready code, no. | 22:55 |
| lifeless | LarstiQ: you need a bot to pipe up here | 22:55 |
| lifeless | spiv: bzr: ERROR: [Errno 2] No such file or directory: '/tmp/testbzrG-RDn6.log' | 22:55 |
| lifeless | spiv: I think there is a bug actually, in the log related test code, cause I'm getting that and I'm not working on write groups ;P | 22:55 |
| lifeless | spiv: something like a gc event causing it | 22:56 |
| Demosthenes | lifeless: so i'm better off symlinking or putting the "child" branches in sibling directories then. | 22:59 |
| lifeless | Demosthenes: or merging them into subdirs - see the merge_into plugin | 23:00 |
| spiv | lifeless: chatting to thumper atm | 23:00 |
| lifeless | spiv: when you can, I have a nontrivial issue in this branch | 23:01 |
| mwhudson | poolie: this is the ui factory code i have now, does it look vaguely sane? http://pastebin.ubuntu.com/117472/ | 23:01 |
| garyvdm | poolie,luks: Alex is not around so I'm asking you guys. We have a regression in qbzr 0.9.7 - bug 327395 - we allready have a fix - should we do another release with just a cherrypick of that fix - to be included in bzr 1.12 finial? | 23:14 |
| ubottu | Launchpad bug 327395 in qbzr "qinit does not work" [Medium,Fix committed] https://launchpad.net/bugs/327395 | 23:14 |
| poolie | hey | 23:15 |
| poolie | mwhudson: yes that looks good | 23:15 |
| poolie | i'd also like to factor out the various types of questions we ask the user into abstracted methods | 23:15 |
| poolie | so you don't need the icky string compare | 23:15 |
| mwhudson | poolie: yes, that would be nice :) | 23:16 |
| mwhudson | poolie: thanks for the sanity check | 23:16 |
| poolie | garyvdm: so where would this change have to be included? | 23:23 |
| lifeless | woo nearly there | 23:23 |
| poolie | in the bzr branch, or just in the windows installers? | 23:23 |
| lifeless | poolie: windows / macosx installers from the look of it | 23:23 |
| lifeless | garyvdm: doing a release makes it clearer to folk, I'd say do one | 23:24 |
| garyvdm | Ok - | 23:24 |
| garyvdm | Should I call it 0.9.8 or 0.9.7-rc2 or ...? | 23:24 |
| poolie | what was your previous release, rc1? | 23:25 |
| garyvdm | Just 0.9.7 | 23:25 |
| poolie | if you're just changing that i'd just call it final | 23:25 |
| garyvdm | I guess that because we did not specify rc1 on the prev release - we have to call it 0.9.8 | 23:27 |
| lifeless | spiv: ok, that fail list all passes now. | 23:28 |
| lifeless | whew | 23:28 |
| lifeless | spiv: so I'm running all tests again, see if there are any new fails | 23:28 |
| spiv | lifeless: woo | 23:34 |
| spiv | lifeless: yeah, I'm pretty sure from yesterday that the test infrastructure's handling of the log file is busted, because I kept hitting it | 23:35 |
| spiv | something to do with raising an exception during a cleanup func perhaps? | 23:35 |
| spiv | So long as my tests weren't erroring it was fine ;) | 23:35 |
| mthaddon | anyone able to comment on https://bugs.launchpad.net/pqm/+bug/191393/comments/3 - I'm assuming this is a bug in bzrlib rather than PQM, but just checking | 23:54 |
| ubottu | Ubuntu bug 191393 in pqm "PQM outputs 'No handlers could be found for logger "bzr"'" [Undecided,New] | 23:54 |
| lifeless | mthaddon: its likely a case where pqm needs to setup a handler or some such | 23:55 |
| mthaddon | lifeless: but how come I can reproduce it in such a simple test? doesn't that suggest bzrlib.branch should be doing something different? | 23:56 |
| lifeless | mthaddon: maybe :P | 23:58 |
| mthaddon | who'd be best to comment on that? | 23:58 |
| lifeless | mthaddon: its coming from the pytohn logging stuff | 23:58 |
| jelmer | would somebody perhaps have time to have a look at my InterBranch patch? | 23:58 |
| lifeless | bzr uses that to output progress data to ~/.bzr.log | 23:58 |
| lifeless | we kindof want that facility to work | 23:59 |
| lifeless | possibly a better thing to do would be to check if there are no handlers, and if not setup either our normal ones, or null handler | 23:59 |
| jelmer | It's blocking my bzr-git work a bit atm, as it's required to do bzr pull from remote git branches | 23:59 |
| lifeless | jelmer: I'll try | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!