| lifeless | down to two failing tests | 00:11 |
|---|---|---|
| lifeless | one failing test | 01:03 |
| bob2 | stacking? | 01:06 |
| poolie | jam, if you're still around, and spiv | 01:10 |
| poolie | in jam's review of the protocol version patch | 01:10 |
| lifeless | bob2: VersionedFiles; pluralised VersionedFile for stacking performance | 01:10 |
| lifeless | bob2: needs a better name | 01:10 |
| poolie | he said "my concern with this is the problem we had with call_with_body_bytes | 01:10 |
| bob2 | spiffy | 01:11 |
| poolie | lifeless: i think we talked about this the other day but i want to confirm | 01:16 |
| poolie | andrew's current v3 patch will make it drop the connection and restart if the remote server is too old | 01:17 |
| poolie | in doing so we eliminate the initial hello command | 01:17 |
| poolie | do you think this is reasonable? | 01:17 |
| lifeless | I think so | 01:22 |
| lifeless | hello was bad | 01:22 |
| lifeless | getting stateless is very beneficial | 01:22 |
| lifeless | yay | 01:24 |
| lifeless | all tests passing for initial add_lines | 01:24 |
| spiv | poolie: I don't think it's the same problem at all | 01:24 |
| spiv | poolie: because a remote bzr server that sees "bzr message 3 (bzr 1.5)\n..." as the first bytes will either know how to handle it or immediately know it can't. | 01:26 |
| spiv | And if it can't, it'll stop reading, send back an error (in whatever version it likes), and drop the connection. | 01:27 |
| spiv | Even v1 servers will do that, because they'll see "bzr message 3 (bzr 1.5)\n" as a unrecognised verb. | 01:28 |
| spiv | All later versions by design check the bytes up to the first newline for a protocol marker precisely to make it possible to reliably tell if a message is in an understood encoding or not. | 01:29 |
| spiv | poolie, jam: btw, I just sent my reply to that review to the list | 01:34 |
| MattCampbell | Has there been any work on TortoiseBZR lately? When I looked last night, there was a significant to-do list, including switching from GTK to native Win32 dialogs (BTW, that's needed for accessibility as well as native look and feel). | 01:34 |
| MattCampbell | I can't help much with the TortoiseBZR UI; though I'm pretty good at low-level Win32 API and COM stuff, I'm terrible at native Win32 dialog design. | 01:35 |
| MattCampbell | TortoiseBZR also doesn't seem like a very good name. I know it's carried over from TortoiseCVS and TortoiseSVN. But "tortoise" seems to be a derogatory characterization of the UI preferred by Windows GUI users. How about WinBzr? | 01:43 |
| Odd_Bloke | MattCampbell: This discussion has already happened on the list, though without much of a conclusion (as regards the name). | 01:45 |
| i386 | MattCampbell: they should hack it in .NET then | 01:49 |
| i386 | you can do shell extensions really easy with a bit of pinvoke | 01:49 |
| MattCampbell | Another option would be wxPython, though wxPython is kinda big (some would say bloated). | 01:51 |
| Odd_Bloke | Hacking it in .NET wouldn't be that great, as it would require ugly callouts to Python... | 01:52 |
| MattCampbell | Agreed. | 01:52 |
| poolie | spiv: yeah that was what i thought too | 01:55 |
| poolie | spiv, i think his point with _default_headers is that your code (at least on Tuesday) looked like a caller could also override it for particular calls | 01:56 |
| poolie | which might be consistent with how some http toolkits work | 01:56 |
| spiv | Well, we have a lack of use cases driving the API here. | 01:57 |
| poolie | right | 01:58 |
| poolie | i don't think we need to add that until we need it, but i think that explains john's comment | 01:58 |
| poolie | um | 01:58 |
| spiv | If we do find we want _SmartClient.call(..., extra_headers={}) or similar, then we can rename private variables appropriately then. | 01:59 |
| poolie | fwiw i think foo.copy() is clearer abount intention, but i suppose less clear that you get a dict :) | 01:59 |
| poolie | sure | 01:59 |
| poolie | i'm going out to the shops, biab | 02:00 |
| spiv | At the moment there's only "headers", so talking about "default headers" would just muddy the picture for no benefit. | 02:00 |
| === mw is now known as mw|out | ||
| === kiko is now known as kiko-zzz | ||
| lifeless | poolie: gnip | 02:59 |
| lifeless | poolie: I'd like to hallway test an idea | 02:59 |
| * igc lunch | 04:00 | |
| poolie | lifeless: poing? | 04:10 |
| lifeless | hi | 04:11 |
| lifeless | igc: I just called a spade a spade; sorry!. | 04:47 |
| igc | lifeless: np - thanks for the feedback | 04:49 |
| lifeless | igc: I hope my explanation of the confusing aspects is clear enough to help find replacements for them | 04:56 |
| lifeless | igc: (if you can see why they are confusing; if you can't I can attempt to describe it differently) | 04:56 |
| igc | lifeless: let me digest your input ... | 04:56 |
| lifeless | k, I'll grab a bite to eat | 04:57 |
| igc | much of the intent is to stop git/hg users trying to use bzr exactly the way they do now | 04:57 |
| lifeless | so hg's pull and push are fundamentally different to bzr's | 04:57 |
| lifeless | describing how something might look with 'push' when you mean 'hg push' -> havoc | 04:58 |
| igc | in particular, the git model of there's ONE true DAG just doesn't translate to bzr | 04:58 |
| lifeless | eh? bzr has one true dag | 04:58 |
| lifeless | revision X always has the same content and parents, or chaos ensues | 04:59 |
| igc | yes, but ... | 04:59 |
| Odd_Bloke | lifeless: But we favour one path through the DAG. | 04:59 |
| Odd_Bloke | Potentially per user. | 04:59 |
| Odd_Bloke | (IIUC) | 04:59 |
| lifeless | Odd_Bloke: I think you'll find that git also chooses a particular search path consistently | 04:59 |
| igc | our branches provide views - they aren't simply a tag for a revision | 05:00 |
| lifeless | igc: do you know how git log orders its output? | 05:00 |
| igc | and two developers syncing each other operates differently in bzr to how git users expect | 05:01 |
| lifeless | igc: in what way? | 05:01 |
| Odd_Bloke | git's search path is by date of commit, so long as it's reachable from the tip (as far as my limited use of git suggests). bzr's has the concept of a mainline. | 05:01 |
| igc | git merge can become a fast forward; for us, fast forward is pull | 05:02 |
| lifeless | Odd_Bloke: git-log suggests its topological ordering to me | 05:05 |
| lifeless | Odd_Bloke: ah, found the details: | 05:07 |
| lifeless | Commit Ordering | 05:07 |
| lifeless | By default, the commits are shown in reverse chronological order. | 05:07 |
| lifeless | --topo-order | 05:07 |
| lifeless | This option makes them appear in topological order (i.e. descendant commits are shown before their parents). | 05:07 |
| lifeless | --date-order | 05:07 |
| lifeless | This option is similar to --topo-order in the sense that no parent comes before all of its children, but otherwise things are still ordered in the commit timestamp order. | 05:07 |
| lifeless | --topo-order will have the same behaviour our log does, though the oredering could be different (there are many topological sorts) | 05:09 |
| igc | lifeless: see https://lists.ubuntu.com/archives/bazaar/2008q1/039738.html. the goal of this patch is to capture the gist of that thread | 05:09 |
| lifeless | --date-order will, when the topological sort has multiple parallel options apparently choose based on datestamp | 05:09 |
| igc | I clearly haven't succeeded though if you found it confusing | 05:10 |
| lifeless | igc: So concretely; I think you must *only* use terms that are well defined; if by 'merge' you mean 'how git does it' or 'how hg does it' it will cause confusion | 05:10 |
| lifeless | A lot of my issues are in the examples of how one 'might' do it | 05:11 |
| lifeless | because: | 05:11 |
| lifeless | - you can do precisely that in bzr | 05:11 |
| Odd_Bloke | lifeless: Ah right, that'll explain it. :) | 05:11 |
| lifeless | - bzr's underlying model works completely fine there | 05:11 |
| lifeless | - the english description resonates badly with the semantics of the bzr commands | 05:12 |
| lifeless | from memory I think the description of merge collapsing was ok, and without the interferance from the contra examples above probably useul | 05:13 |
| lifeless | *useful* | 05:13 |
| lifeless | I need food, back soon | 05:13 |
| igc | lifeless: hmm. I find it hard to write this particular section. | 05:14 |
| igc | I feel it needs to come early in the manual so I haven't explained any bzr commands yet, just the high level concepts | 05:15 |
| igc | getting the point across without going into details of bzr (let alone hg and git) is ... tricky to say the least | 05:17 |
| cbarrett | How do bzr revision numbers and cherry picking work? | 05:17 |
| igc | I'll take a fresh look at the wording and see what I can tweak | 05:18 |
| igc | time to fix the fastimport out of memory issue now though | 05:18 |
| cbarrett | My branch's tip: 100.1.3. Mainline tip: 200. I want: 150. So, 150 becomes 100.1.4. What happens when I merge back? | 05:18 |
| lifeless | abentley: how big a memory buffer did you find good for iter_file_byutes? | 05:19 |
| igc | cbarrett: as it happens, I'm in the process of trying to explain that in a patch I'm putting up to the User Guide | 05:22 |
| cbarrett | igc: Interesting :) | 05:22 |
| abentley | lifeless: 1M seemed to work nicely. | 05:22 |
| igc | cbarrett: we're just decided my explanation isn't good enough though :-) | 05:23 |
| cbarrett | :) | 05:23 |
| poolie | hm on reflection having the assertion patch finished and not merging it seems wasteful | 05:24 |
| cbarrett | Another question is what happens if: Alice Bob Carol & Dave all branch from 100. Alice merges Bob, creating 100.1.x in her repository. Dave merges Carol, creating 100.1.x in his repository. What happens if Alice tries to merge with Dave? | 05:24 |
| igc | cbarrett: here's my proposed text fwiw: http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html#bazaar-zen | 05:24 |
| igc | cbarrett: it's still a work in progress but hopefully it helps answer your questions | 05:25 |
| igc | let me know either way | 05:26 |
| cbarrett | igc: Thanks. | 05:26 |
| cbarrett | igc: I don't think it answers my question. | 05:27 |
| cbarrett | My second one anyway. | 05:27 |
| cbarrett | And it doesn't seem to talk about cherry picking (taking a revision out of context of its ancestors and children) | 05:27 |
| cbarrett | It is definitely a good idea and an improvement over the old bzr numbering scheme. | 05:28 |
| igc | cbarrett: cherrypicks aren't currently tracked in bzr | 05:28 |
| cbarrett | igc: Ahh, that's unfortunate -- it's a really common operation for a lot of folks. | 05:28 |
| igc | you can *do* them - they just aren't recorded (so you'll get more merge conflicts than you ideally would) | 05:30 |
| cbarrett | Just like using svn (bleh) | 05:30 |
| igc | cbarrett: so extending my example in 2.7.4, Alice merging Dave will show ... | 05:31 |
| igc | Carol's changes are 100.2.x | 05:32 |
| igc | Dave's changes as 100.3.x | 05:32 |
| igc | or perhaps vice versa depending on whether Dave did anything before merging from Carol | 05:33 |
| cbarrett | Hmm, I see. | 05:33 |
| cbarrett | igc: So what happens Dave merges with Alice later? | 05:34 |
| igc | I'd expect Alice's changes to be numbered 100.x.y in Dave's branch ... | 05:35 |
| igc | the key point is that the numbering is local to each branch and ... | 05:35 |
| cbarrett | So she would see her own revisions numbered as 100.x.y? | 05:35 |
| cbarrett | Oh, interesting. | 05:35 |
| igc | they all start with 100 because they all originally branch from that revision | 05:36 |
| cbarrett | right | 05:36 |
| cbarrett | There's a global revID though right? | 05:36 |
| cbarrett | Some SHA-1 hash of some sort? | 05:36 |
| igc | yes - it doesn't change | 05:36 |
| bob2 | uuid rather than a hash | 05:36 |
| igc | revision-ids are global | 05:36 |
| igc | revision-numbers are local per branch | 05:36 |
| bob2 | and not stable | 05:37 |
| LaserJock | sorry, I've been watching. so how do people refer to each other's revisions? do they say "100.x.y in Alice's branch"? | 05:38 |
| cbarrett | Seems like it could get annoying to figure out from "Well, the bug is in r67 in my branch" which revision that is in YOUR history, so you can go back in time. I guess you'd need to send the UUID in that case. | 05:38 |
| igc | they're stable across branches in a limited way | 05:38 |
| cbarrett | Or worse, "the bug is in 67.5.2338 in my branch" | 05:38 |
| cbarrett | Oi. | 05:38 |
| bob2 | LaserJock: in practice it seems people usually refer to branches or mainline revisions | 05:39 |
| igc | yes, as http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html#bazaar-zen explains, revision numbers need to be given in the context of a branch | 05:40 |
| igc | if no branch is given, developers typically mean "the trunk" | 05:40 |
| bob2 | they're not even stable in a branch | 05:40 |
| cbarrett | One thing that I like about mercurial is that it isn't hard to give the short hash of a revision if you need to "6ab6a519692d" is not that many characters, and while it isn't pretty to look at, it's easy to figure out where that is in your own history. | 05:42 |
| cbarrett | but I'm intrigued by the dotted notation. | 05:42 |
| * cbarrett ponders | 05:42 | |
| spiv | Mostly I don't even use the dotted revnos. | 05:43 |
| spiv | A lot of the time I'm only really interested in the mainline of a branch. | 05:43 |
| * cbarrett nodes | 05:43 | |
| cbarrett | *nods | 05:43 |
| spiv | It depends on why you want to know, of course. | 05:43 |
| lifeless | abentley: thanks; did you profile over sftp or anything like that? | 05:44 |
| abentley | lifeless: no, that was based on local testing. | 05:44 |
| igc | cbarrett: following on from spiv's comment, I never say "the bug is in 67.x.y of my branch" | 05:45 |
| abentley | Actually, 100 K seemed fine for local, but I multiplied it for remote. | 05:45 |
| lifeless | abentley: cool | 05:45 |
| cbarrett | igc: Ah, you'd say "the bug in 78 of steve's branch" | 05:45 |
| lifeless | abentley: I'm going to implement get_text(key) as self.get_record_stream([key], 'unordered', delta_closure=True).next().get_bytes_as('fulltext') | 05:46 |
| igc | from the view of my branch, the interesting point is when I merged steve's branch and got the 67.x.y. revision as a result | 05:46 |
| lifeless | abentley: to avoid needing multiple code paths to extract texts | 05:46 |
| igc | that might be version 80 of my branch say | 05:46 |
| cbarrett | igc: Ah, interesting. | 05:47 |
| cbarrett | So you kind of collapse history there a bit. | 05:47 |
| igc | Now, if I merged the trunk ... | 05:47 |
| lifeless | note that hg has teh same thing with its revnos | 05:47 |
| igc | I might be seeing a bug in 67.x.y. as a result | 05:47 |
| lifeless | its linear numbers are *only* valid in a single repository | 05:47 |
| cbarrett | lifeless: *nod* | 05:47 |
| cbarrett | A little simpler. | 05:47 |
| igc | but for external communication, that version 75 (say) of the trunk | 05:48 |
| igc | and I'd find that easily by running log --short' on my trunk mirror and matching on the commit message (if not the revision-id) | 05:49 |
| lifeless | cbarrett: I'm not sure its simpler - its quite possible to have revno X in a hg repository not be present in a given branch | 05:49 |
| lifeless | I've seen that cause frequent confusion in #hg :) | 05:49 |
| cbarrett | Hm? | 05:49 |
| lifeless | cbarrett: hg's revno's are the index in the revision revlog | 05:49 |
| cbarrett | Right. | 05:50 |
| * cbarrett is familiar with mercurial | 05:50 | |
| lifeless | cbarrett: multiple branches can share a revlog though various means | 05:50 |
| cbarrett | Right. | 05:50 |
| lifeless | cbarrett: if you have two heads, then there is at least 1 revision which is reachable from head A and not from head B | 05:50 |
| cbarrett | By definition, yes. | 05:50 |
| lifeless | cbarrett: (trivially - B is not reachable from A or it wouldn't be a head :)) | 05:50 |
| lifeless | so if A has revno 100 | 05:51 |
| lifeless | and B has revno 80 | 05:51 |
| lifeless | revno 80 isn'tpart of branch A | 05:51 |
| cbarrett | Yes. | 05:51 |
| LaserJock | lifeless: btw, I found an interesting blog post from 2006 doing some performance comparisions between git and bzr on the linux tree (http://blog.jozilla.net/2006/03/03/bzr-versus-git/) | 05:51 |
| LaserJock | lifeless: so last night I duplicated it but with present versions of git and bzr | 05:52 |
| lifeless | this is confusing for people that don't know the implementation details - what a revlog is and broadly what it does and how revisions are managed | 05:52 |
| LaserJock | gave some interesting results | 05:52 |
| cbarrett | lifeless: *nod* | 05:52 |
| cbarrett | lifeless: Usually when I want to tell someone about a revision and they're not using my repository, I use a hash. | 05:52 |
| lifeless | cbarrett: I was challenging that hg's revnos are simpler, because to me, when you have to know implemetnation details that far down the stack, there is something funky going on. | 05:53 |
| lifeless | LaserJock: oh? | 05:53 |
| cbarrett | lifeless: I don't see them as something to share with others though | 05:53 |
| cbarrett | just a shortcut to refer to things in that repo | 05:54 |
| cbarrett | but I might be wrong about intent | 05:54 |
| * cbarrett is not mpm | 05:54 | |
| cbarrett | :P | 05:54 |
| lifeless | well, clearly they aren't sharable; because they are not reproducible without physical access to the repo | 05:54 |
| LaserJock | lifeless: I guess I'll probably blog it since that's the thing to do | 05:56 |
| LaserJock | lifeless: but bzr has gotten a lot better | 05:56 |
| lifeless | good :) | 05:56 |
| LaserJock | *but* bzr diff got a whole lot slower in comparision | 05:56 |
| LaserJock | or rather git-diff got a ton faster | 05:57 |
| LaserJock | in the original one bzr diff was roughly twice as fast as git | 05:57 |
| LaserJock | but in mine git was about twice as fast as bzr | 05:57 |
| lifeless | damn! | 05:57 |
| LaserJock | but the areas where bzr was waaaaay slower it's now pretty reasonable | 05:58 |
| LaserJock | bzr diff on an unchanged tree was dramatic | 05:58 |
| LaserJock | anyway, it was an interesting experiment | 06:00 |
| LaserJock | doing a commit after a minor change has improved significantly | 06:00 |
| LaserJock | took this other guy over 2min. to do a commit | 06:01 |
| LaserJock | for me it only took 9s | 06:01 |
| Odd_Bloke | poolie: I probably wouldn't use forums, I'd forget even if I intended to. It seems to me that this is the sort of thing that Launchpad should cater for (given that we as a Free Software Project want it or something like it). | 06:12 |
| mneptok | cbarrett! | 06:12 |
| mneptok | holycrap | 06:12 |
| cbarrett | mneptok: Ahoy there. | 06:12 |
| cbarrett | What's new, Peggy Sue? | 06:12 |
| mneptok | 'allo sah. how goes? | 06:12 |
| cbarrett | Pretty good. Still in the Bay Area. No longer at Moz, though. | 06:13 |
| mneptok | poking at d/vcs'eseses again? :) | 06:13 |
| cbarrett | Doing contracting (currently working on iPhone stuff) | 06:13 |
| cbarrett | mneptok: Yup. | 06:13 |
| mneptok | ok, nosy time. /m | 06:13 |
| Verterok | moin | 06:14 |
| Odd_Bloke | Verterok: Morning. What timezone are you in ATM? | 06:15 |
| Verterok | Odd_Bloke: Hi, GMT-3 | 06:16 |
| Verterok | Odd_Bloke: 2:15 here, and heading to bed | 06:17 |
| Odd_Bloke | Verterok: Fair enough. | 06:17 |
| Odd_Bloke | 6:15 here and I should have head to bed. ¬.¬ | 06:17 |
| Verterok | Odd_Bloke: indeed (but depends on your plans for the day) :) | 06:18 |
| Odd_Bloke | Well, I have a deadline at noon, but then got distracted by the baseball. And now I'm kinda too tired to risk doing any work. :p | 06:18 |
| Verterok | Ouh, deadlines! :P | 06:19 |
| poolie | Odd_Bloke: so there's a kind of chicken and egg project | 06:21 |
| poolie | if projects want forums, lp ought to provide them | 06:21 |
| * Verterok reading this ¿new? DVCS comparsion: http://www.infoq.com/articles/dvcs-guide | 06:22 | |
| Odd_Bloke | I didn't strictly mean forums, but a solution to the class of problems that forums are designed to solve. I unhelpfully have no useful ideas on what that might look like, but I think that Questions could be it with some tweaking... | 06:23 |
| poolie | Questions is pretty close to it | 06:23 |
| Odd_Bloke | I also wonder if there's a better way of keeping the mailing list and the (bug tracker|Questions) better sync'd, which would reduce the need for _another_ 'easier' forum for users to ask questions. | 06:24 |
| Odd_Bloke | Also, to continue spewing out ideas, a forum-esque frontend onto the mailing list might disguise it enough to make people feel comfortable. | 06:25 |
| Odd_Bloke | Sort of like what Gmane does, but themed and closer to a forum. :p | 06:25 |
| poolie | yeah, all those things would be interestig | 06:36 |
| poolie | hopefully some of them will even exist in the future | 06:36 |
| Odd_Bloke | :D | 06:36 |
| poolie | lp integration of teams and lists is meant to be just a start | 06:36 |
| poolie | i think BB is really interesting in the way it fuses mail and web interfaces too | 06:37 |
| poolie | spiv: ping | 06:42 |
| spiv | poolie: pong | 06:43 |
| poolie | spiv, i'm trying to pull your loom and get bzr: ERROR: The revision andrew.bennetts@canonical.com-20080508013609-jk12992zhs18nlp0 is not recorded in the loom LoomBranch('http://people.ubuntu.com/%7Eandrew/bzr/protocol-v3-loom/'). | 06:43 |
| spiv | Hmm. | 06:44 |
| * spiv makes sure he has the latest loom plugin and that the loom is recorded | 06:45 | |
| spiv | poolie: try now, maybe? | 06:47 |
| spiv | poolie: I can push the current tip to a non-loom if necessary | 06:48 |
| poolie | trying | 06:48 |
| poolie | got it | 06:49 |
| poolie | that was odd | 06:49 |
| poolie | and is that branch current with your work? | 06:50 |
| spiv | Some combination of upgrading my loom plugin, running "bzr record" and doing another push must have sorted it out. | 06:50 |
| spiv | Yep. | 06:50 |
| poolie | spiv, i'm going to read through the overall diff from trunk | 06:56 |
| poolie | should i give feedback here or in mail? | 06:56 |
| poolie | or maybe i should just send an update patch | 06:57 |
| spiv | poolie: mail is probably best, on the assumption that with a diff that large you're sure to have a non-trivial number of comments :) | 06:57 |
| poolie | i see RemoteBzrDirFormat.probe_ | 07:00 |
| poolie | * probe_transport | 07:00 |
| poolie | is still doing protocol_version, we're going to remove that right? | 07:01 |
| spiv | Right. | 07:01 |
| poolie | kk | 07:01 |
| spiv | Although we'll still need it for HTTP. | 07:01 |
| poolie | i was just going to say that! | 07:02 |
| spiv | (Because HTTP transports are only sometimes smart, RemoteBzrDirFormat needs to actually try an RPC to find out if smart is possible for any given HTTP transport) | 07:02 |
| spiv | I have some changes almost ready to commit to that implement that. | 07:03 |
| spiv | I'm just chasing a regression I just found interactively :) | 07:04 |
| poolie | spiv: how were you going to handle it? | 07:12 |
| spiv | poolie: add a 'should_probe' method to SmartClientMedium. It'll return False, except for the HTTP implementation. | 07:13 |
| spiv | probe_transport will use that to decide if it should do the current logic (issue a test RPC) or just assume smart is ok. | 07:14 |
| poolie | ok | 07:14 |
| poolie | hm, maybe that code should be inside get_smart_medium, or something called on the medium? | 07:15 |
| spiv | Hm, maybe. | 07:16 |
| poolie | rather than just exposing a boolean that means "call me back to check" why not just have a method that does the check if necessary? | 07:16 |
| poolie | just an idea | 07:16 |
| spiv | There's some overlap with what we've made _SmartClient responsible for too. | 07:16 |
| spiv | Keep in mind that the check itself is cached, though. | 07:17 |
| spiv | i.e. medium.protocol_version(); medium.protocol_version() already issues just one RPC. | 07:17 |
| poolie | i don't have a strong opinino | 07:17 |
| poolie | it just seems this is not really the job of BzrDir | 07:18 |
| spiv | So the practical difference would be fairly small at the moment. | 07:18 |
| spiv | I agree there's something here that needs cleaning up. | 07:18 |
| spiv | There's also a bit of tension bugging me in that everything shares the medium, but I think perhaps we want things to share the _SmartClient instead. | 07:19 |
| spiv | But I'm pretty comfortable that tidying that up is a lower priority than other work. | 07:20 |
| poolie | ok | 07:20 |
| poolie | i found one bug we should fix before merging | 07:20 |
| poolie | there may be a few occurences | 07:20 |
| poolie | will send mail soon | 07:20 |
| spiv | Excellent. | 07:21 |
| poolie | btw does a bare 'raise' preserve the original stack in the exception? | 07:22 |
| poolie | i think it does | 07:22 |
| spiv | It does. | 07:23 |
| poolie | this is a big diff! | 07:26 |
| spiv | Yeah :/ | 07:30 |
| poolie | this MessageHandler is nice | 07:50 |
| poolie | spiv, i thought we were going to allow requests to have streamed body too | 07:54 |
| poolie | i guess i don't understand why ConvRequestHandler is different to ConvResponseHandler | 07:54 |
| spiv | Partly it's different because they have a different interface. | 07:55 |
| spiv | A request handler has no use for read_response_tuple, for instance. | 07:55 |
| poolie | right, i can see the client needs to call into the response handler | 07:55 |
| poolie | but isn't the protocol symmetrical? | 07:56 |
| spiv | There's nothing about ConventionalRequestHandler that disallows streamed bodies. | 07:56 |
| spiv | It just doesn't support them, if you see what I mean. | 07:56 |
| poolie | if it gets a streamed body, won't bytes_part_received be called multiple times? | 07:57 |
| spiv | When we decide to write a request that wants a streamed body, we can either extend ConvRequestHandler to cope with that, or make it a different type of request. | 07:57 |
| spiv | Right. | 07:58 |
| spiv | I've been a bit indecisive about what to do on this part, I'm happy to make this more symmetrical with ConvResponseHandler. | 07:58 |
| poolie | so it seems like if you send a streamed request to a server running this version of the code | 07:59 |
| spiv | An earlier revision of this code had an XXX in ConvRequestHandler.bytes_received_part about this. | 07:59 |
| poolie | it will break, because it assume the body finishes after the first part | 07:59 |
| spiv | Well, it will break anyway. | 07:59 |
| spiv | Because the server won't know the verb :) | 07:59 |
| poolie | but what if we want to make a currently active verb stream? | 08:00 |
| spiv | (But the server will still be able to consume the entire request so that it can read the next one) | 08:00 |
| poolie | s/active/supported | 08:00 |
| spiv | I don't think that's a good idea. | 08:00 |
| poolie | or, for example, make everything stream | 08:00 |
| spiv | I think we should just make a new verb for that. | 08:00 |
| poolie | that might be a good idea in practice | 08:01 |
| spiv | (semantically, I see a streamed body as being a series of chunks, rather than just as a single string that is delivered more efficiently) | 08:01 |
| poolie | i guess i was hoping that when we landed this, we would have all the mechanisms supported on both ends | 08:02 |
| poolie | so that in future we would only need to think about whether particular verbs are supported | 08:02 |
| spiv | Well, the important mechanisms are; the ones that allow graceful fallback. | 08:02 |
| spiv | I'm looking forward to filling in this little gap in the puzzle. If you have a strong opinion about what should go there, I'm happy to do that :) | 08:04 |
| poolie | i think i see a small change for it | 08:04 |
| poolie | hm only 20% through... | 08:05 |
| lifeless | poolie: its not really symmetrical though, in that while we can decide to send less data we can't decide to recieve less data (without dropping the connection) | 08:15 |
| poolie | well, sure, not symmetrical in the way it's used but in structure | 08:16 |
| lifeless | later all | 08:48 |
| poolie | night | 08:48 |
| poolie | have a good trip! | 08:48 |
| poolie | spiv, comments on the first 1/3rd sent | 08:55 |
| * igc dinner | 09:06 | |
| === cprov is now known as cprov-afk | ||
| === cprov-afk is now known as cprov | ||
| vila | hi all | 12:16 |
| james_w | Bonjour vila | 12:18 |
| vila | lifeless, poolie : pqm is refusing my submission saying "Sender not authorised to commit", could that be related to my launchpad id change ? | 12:18 |
| vila | james_w: hi ! | 12:18 |
| === mrevell is now known as mrevell-lunch | ||
| Le-Chuck_ITA | Hi there | 13:29 |
| Le-Chuck_ITA | there's one thing I can't grasp of bzr | 13:29 |
| Le-Chuck_ITA | can it host two branches efficiently in the same directory/local repository/local branch whatsoever? | 13:29 |
| vila | jam: ping, any idea about the next episode in my pqm submissions :) ? | 13:46 |
| titusg | hi, how do I pull a particular revision number? | 13:50 |
| titusg | what I want to do is revert a file to the version from a different revision, and I don't know how... | 13:51 |
| james_w | titusg: "bzr pull -r revno" | 13:52 |
| james_w | titusg: ah, that sounds like you want revert | 13:52 |
| james_w | "bzr revert -r revno filename" | 13:52 |
| titusg | james_w: thankyou! | 13:52 |
| LeoNerd | Hrm.. it's annoying how bzr picks a file ID based on the filename... I want to rename a file, but I don't like the unneatness in my head that would cause :P | 14:13 |
| === mrevell-lunch is now known as mrevell | ||
| === kiko-zzz is now known as kiko | ||
| vila | jam, poolie lifeless : sorry for the noise, it appears I can't submit for http://bazaar-vcs.org/bzr/bzr.dev/ , but if I delete the trailing '/' all is fine. I added it myself while hand-editing the branch.conf file, so no need to search for a bug there ;-) | 14:45 |
| === thekorn_ is now known as thekorn | ||
| === mw|out is now known as mw | ||
| awilkins | jelmer: Is there a branch of bzr-svn that works with 1.4 yet? | 16:23 |
| jelmer | awilkins: the 0.4 one does | 16:28 |
| awilkins | jelmer: I'll speak to you tomorrow ; train time | 16:30 |
| === kiko is now known as kiko-fud | ||
| === threeve_ is now known as threeve | ||
| === kiko-fud is now known as kiko | ||
| ignas | hi, how do I make an existing shared repo have --no-trees set? | 18:42 |
| LeoNerd | touch .bzr/repository/no-working-trees | 18:44 |
| LeoNerd | Seems to be a 0byte file I have present in mine | 18:44 |
| ignas | LeoNerd: thanks | 18:44 |
| === mw is now known as mw|food | ||
| === mw|food is now known as mw | ||
| Vantage | hi. Somewhat off topic question. What was used to make the diagrams in http://bazaar-vcs.org/Workflows ? | 20:44 |
| james_w | Vantage: hi, I think that was igc's work. | 20:46 |
| Vantage | james_w: any idea what program/icon set was used? | 20:47 |
| james_w | nope, sorry. | 20:48 |
| === phanatic_ is now known as phanatic | ||
| igc | Vantage, james_w: the workflow diagrams were borrowed and tweaked from http://gigo-ice.org/scm/bazaar/index.html with permission | 21:26 |
| igc | there's a contact email address on that web site if you have any questions about the details | 21:27 |
| === NfNitLoo` is now known as NfNitLoop | ||
| lifeless | morning igc | 21:37 |
| lifeless | sick child? | 21:37 |
| igc | morning lifeless | 21:57 |
| igc | kids are good but wife working today so I'm squeezing in email before breakfast/morning-rush | 21:57 |
| igc | which starts about now ... | 21:58 |
| fullermd | Wanna borrow my bullwhip? | 21:58 |
| igc | fullermd: can it make breakfast and lunches? | 22:00 |
| igc | time to go - bbl | 22:01 |
| === rockstar_ is now known as rockstar | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!