| Verterok | heya! | 00:00 |
|---|---|---|
| * Verterok waves greetings | 00:00 | |
| Verterok | jfroy: it looks like a bug un setuptools :( | 00:00 |
| Verterok | jfroy: or an old version | 00:01 |
| jfroy | Verterok: not part of setuptools, that's part of bdist_mpkg | 00:02 |
| Peng_ | How do you get "bzr: ERROR: No module named tests" when running from source?! :( | 00:02 |
| Peng_ | Ahh! Plugin! Heh | 00:02 |
| Verterok | jfroy: right, it seems to be fixed in trunk | 00:02 |
| Peng_ | That's what I get for not reading hte traceback first. | 00:03 |
| jfroy | Verterok: Ah, I see | 00:03 |
| Verterok | jfroy: the trac instance seems to be down, but you can get it from the svn: "< impl> I didn't realize Aerdan had prioritized the animals he wants to have sex with"] | 00:04 |
| Verterok | 19:48 < mxpxpod> jelmer: ok, thanks | 00:04 |
| Verterok | worng paste :p | 00:04 |
| Verterok | jfroy: http://svn.pythonmac.org/bdist_mpkg/bdist_mpkg/trunk/ | 00:04 |
| jfroy | yeah I got it :) | 00:04 |
| Verterok | ok | 00:04 |
| jfroy | Verterok: seems to work great | 00:05 |
| Verterok | nice | 00:06 |
| jam | poolie: can you call back? | 00:07 |
| poolie | sure | 00:07 |
| lifeless | hi poolie | 00:09 |
| jfroy | Verterok: yup, works :) | 00:09 |
| Verterok | jfroy: yay! | 00:09 |
| jfroy | It is Very Good™ not to have to type my svn passwords 3 times or more for operations on svn repositories (with my experimental bzr+keychain branch) | 00:11 |
| jfroy | :) | 00:11 |
| jfroy | Need to get that out of experimental now :p | 00:12 |
| lifeless | poolie: sorry, missed it | 00:13 |
| lifeless | poolie: pls ring again | 00:13 |
| jfroy | Verterok: It's kind of sucky that you have to maintain two builds to target 1.4 and 1.5 | 00:13 |
| Verterok | jfroy: yeap, don't have an idea of how much I agree on that | 00:14 |
| jfroy | Tiger is so long ago for me, was svn even bundled with it? | 00:14 |
| Verterok | jfroy: but I know there are a lot of people still on 1.4.x | 00:14 |
| Verterok | jfroy: nope, you must install it from "somewhere" (macports, collabnet, etc) | 00:14 |
| jfroy | Verterok: that's incredibly crappy :/ | 00:18 |
| Verterok | jfroy: yeap, that's the reason I only build it against collebnet binaries :) | 00:19 |
| jfroy | Honestly, I'd just make 2 packages, one for svn 1.4 and one for svn 1.5, installed in /usr/local/ (e.g. the collabnet binary packages). If they have it elsewhere, I'd just tell them to build bzr-svn from source... | 00:19 |
| Peng_ | Eek, there's a test that builds everything? | 00:19 |
| Verterok | jfroy: imagine building it for macports, fink, collabnet (all x2 (1.4 amd 1.5)) :p | 00:20 |
| jfroy | Verterok: no thanks ;p | 00:20 |
| Verterok | me neigther :) | 00:20 |
| jfroy | If you wanted to be *reaallly* clever, you could build against 1.4 only in /usr/local, then use an installer script to find the actual install, then muck around the Mach-O headers to change the import paths, and hoping the 1.5 libraries are binary compatible with the 1.4 libraries :p | 00:21 |
| jfroy | Sounds like a lot of unpleasant installer script work :p | 00:21 |
| Verterok | indeed :p | 00:22 |
| jfroy | Verterok: oh, you'd also have to weak import all symbols and modify the bzr-svn source to check for NULL function symbols, in case someone decides to build from source and omit support for https, or keychain, or what have you :p | 00:23 |
| Verterok | jfroy: that sounds way too complicated :), I'll stick with the script that build both version against collabnet binaries. as far I know, is the more complete dmg for 10.4 | 00:25 |
| Verterok | if someone builds svn from source, I'm pretty sure the 'll be able to build bzr-svn ;) | 00:26 |
| jfroy | Verterok: I wasn't being serious :p | 00:26 |
| Verterok | jfroy: I supposed that, but just in case :) | 00:26 |
| === jamesh_ is now known as jamesh | ||
| poolie | markh, could you try to build 1.7.1 exes sometime? | 03:08 |
| poolie | i did not set up that server yet | 03:08 |
| poolie | i'd like to | 03:08 |
| markh | poolie: sure - I'll try and do that this afternoon | 03:09 |
| poolie | thanks | 03:09 |
| markh | I've been working on porting pywin32 to py3k recently - that is an interestng experience :) | 03:11 |
| markh | well - more like watching/helping some other person do it :) | 03:12 |
| markh | I figured I should get a little hands-on experience before the first official release - even if only by a few days | 03:12 |
| jml | spiv: is there a config option I can use so that -dHPSS is always on? | 04:00 |
| spiv | jml: "alias bzr='bzr -Dhpss'" in your bashrc ;) | 04:16 |
| jml | incidentally, MemoryTransport.rename's behaviour varies based on dict ordering. | 04:21 |
| spiv | jml: that doesn't sound good. | 04:26 |
| jml | spiv: it doesn't feel good eiter. | 04:26 |
| mwhudson | in other sucky news | 04:27 |
| mwhudson | mwh@grond:init-stack-pull$ bzr push | 04:27 |
| mwhudson | Using saved push location: bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/init-stack-pull | 04:27 |
| mwhudson | bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('bzr+ssh://bazaar.launchpad.net/%7Emwhudson/launchpad/init-stack-pull/.bzr/repository/') | 04:27 |
| spiv | mwhudson: pastebin the traceback? | 04:28 |
| mwhudson | spiv: there is no traceback | 04:28 |
| spiv | mwhudson: ~/.bzr.log is your traceback-recording friend! :) | 04:29 |
| mwhudson | hey guess what guys!!! | 04:29 |
| mwhudson | it was autopacking | 04:29 |
| spiv | It might be caused by the same sort of situation that has caused TooManyConcurrentRequestErrors in the past. | 04:29 |
| spiv | Heh. | 04:29 |
| jml | number one bzr bug | 04:29 |
| mwhudson | at least it's fixed now | 04:30 |
| spiv | mwhudson: I'd still like to see the traceback :) | 04:30 |
| mwhudson | spiv: https://pastebin.canonical.com/9805/ | 04:31 |
| mwhudson | spiv: happens with bzr.dev 3731 too fwiw | 04:32 |
| spiv | Yeah, I think it does have the same root cause. | 04:32 |
| spiv | mwhudson: thanks | 04:32 |
| mwhudson | my bzr.dev may be a little out of date tho | 04:32 |
| jml | spiv: bug 276972 if you are interested. | 04:33 |
| ubottu | Launchpad bug 276972 in bzr "MemoryTransport.rename behaviour varies with dict ordering" [Undecided,New] https://launchpad.net/bugs/276972 | 04:33 |
| spiv | jml: ta | 04:39 |
| mwhudson | spiv: happens with bzr.dev too, but maybe upgrading the bzr on the server would fix it? not sure | 04:44 |
| mwhudson | (as would maybe pushing over sftp i guess) | 04:44 |
| spiv | mwhudson: depends on what the underlying error that is being masked by the bug in BzrBranch.push is | 04:46 |
| spiv | mwhudson: I can give you a patch to allow the original exception to propagate | 04:46 |
| mwhudson | spiv: i am driving several hundred km away in about 20 mins :) | 04:47 |
| spiv | mwhudson: http://rafb.net/p/4pgIvJ66.html | 04:47 |
| spiv | mwhudson: but if you go enjoy your road trip instead I'll understand :) | 04:48 |
| spiv | mwhudson: https://bugs.edge.launchpad.net/bzr/+bug/230902 | 04:55 |
| ubottu | Launchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed] | 04:55 |
| lifeless | spiv: ping; remind me - subclasses of classes with slots; need the total list of attributes? | 05:28 |
| spiv | lifeless: IIRC, they just need the list of attributes added by the subclass. | 05:28 |
| spiv | Hmm, apparently my memory is faulty. | 05:29 |
| lifeless | spiv: :P | 05:31 |
| spiv | Ah, no, just my quick 10-second attempt to verify it in the python interpreter was wrong :) | 05:32 |
| spiv | My memory turns out to be fine :) | 05:32 |
| spiv | (And the docs in fact say the meaning of defining the same slot twice, i.e. in a class and in a subclass, is "undefined") | 05:35 |
| * mwhudson off | 05:43 | |
| lifeless | spiv: interesting; see, I want to delete a slot the base class has :P | 05:52 |
| spiv | lifeless: ah, well... tough :P | 05:56 |
| lifeless | :-> | 05:58 |
| lifeless | when did I last mention hating doctest? | 06:05 |
| lifeless | abentley: are you up? | 06:07 |
| abentley | Yeah | 06:07 |
| lifeless | serializers are puzzling me | 06:08 |
| lifeless | I'm hacking on a demand-loading inventory | 06:08 |
| lifeless | serializer foo currently assumes you *can* serialize an inventory to a single string | 06:08 |
| lifeless | e.g. bzrlib/tests/per_repository/test_repository.py | 06:08 |
| lifeless | line 671, | 06:08 |
| lifeless | test_add_revision_inventory_sha1 | 06:08 |
| lifeless | which checks that the serializer is used and its sha output recorded | 06:09 |
| lifeless | I *think* I need to make the interface tests not be defined in terms of the serializer object, but I was wondering if you had any thoughts? | 06:10 |
| abentley | lifeless: by demand-loading, what do you mean? Segmented so that only some items are loaded at a time? | 06:10 |
| lifeless | abentley: yes | 06:10 |
| lifeless | abentley: fragemented into lots of little pieces | 06:10 |
| abentley | So I would say the serializer abstraction doesn't make sense for these. | 06:11 |
| lifeless | I figure I can have a serializer object that represents the particular style of splitting | 06:11 |
| lifeless | and we still have revisions as single objects | 06:11 |
| abentley | Okay, our *current* serializer abstraction doesn't make sense. | 06:12 |
| lifeless | :> | 06:12 |
| lifeless | thanks, I think I have what I need | 06:12 |
| lifeless | I've posted about this work btw, and its pushed | 06:12 |
| lifeless | the most recent stuff isn't passing tests yet and I'm closing the gap there hoping to push more to play with tonight | 06:13 |
| abentley | You'll probably want moral equivalents of most of the single-string serializer tests. | 06:13 |
| abentley | And I'd imagine the existing tests should be used for existing serializers. | 06:13 |
| abentley | lifeless: Yeah, I sort of read it. | 06:14 |
| poolie | lifeless: i don't have a strong opinion that you should do a cache in a CHKInventory now | 06:14 |
| poolie | it is not very clear from your mail why you'd want to | 06:14 |
| abentley | I'm not really clear on what CHK stands for, so I can't comment intelligently. | 06:16 |
| lifeless | abentley: its an abbreviation for content hash key; e.g. "md5:1234123421342" or "sha1:1234135143514645acdef" | 06:16 |
| lifeless | (this predates git's terminology and is more general, I think its a more useful way to talk about using hashes as keys) | 06:18 |
| abentley | lifeless: So CHK is a superset of content-addressible filesystem. | 06:18 |
| lifeless | poolie: there may be code that does lots of repeated lookups of the same fileid | 06:19 |
| lifeless | poolie: a cache would ameliorate those codepaths (remove repeated-parsing overhead) | 06:19 |
| poolie | right | 06:19 |
| poolie | i thought that's what you meant | 06:20 |
| lifeless | abentley: roughly yeah; not really a file system as packs are transactional etc etc | 06:20 |
| abentley | lifeless: I mean the CHK terminology, not your work specifically. | 06:20 |
| lifeless | abentley: the yes, though I think perhaps 'intersecting with' rather than 'superset', but perhaps I'm being overly pedantic | 06:21 |
| poolie | abentley, i agree, i think HashKeyedInventory or something would be clearer | 06:22 |
| poolie | or even just HashedInventory | 06:22 |
| lifeless | SmokingInventory | 06:22 |
| poolie | mm | 06:22 |
| poolie | at least it's not scatalogical | 06:23 |
| abentley | Yeah, HashedInventory is more evocative. | 06:23 |
| lifeless | its building on CHKMap not on hashing itself; its quite generic code; uhm, I'm sure thenaming can be improved, but perhaps its making the layers clearer that is needed | 06:24 |
| abentley | This is also a split inventory concept. Is it splitting on directories or a radix tree? | 06:25 |
| lifeless | abentley: either | 06:25 |
| lifeless | abentley: I intend to put together CHKMap subclasses to let use experiment with both both those concepts and the other variations | 06:25 |
| lifeless | abentley: (which are the parameters I mentioned in my mail from tuesday) | 06:26 |
| lifeless | s/use/us/ | 06:26 |
| poolie | presumably both of them should be renamed if we think 'CHK' is cryptic | 06:28 |
| abentley | lifeless: I didn't see that mentioned in the email. | 06:29 |
| lifeless | poolie: presumably; one more note on naming though - it should be quite specific; 'Hashed' is IMO hopelessly generic, I mean, current Inventory objects are Hashed internally. (self._byid). | 06:29 |
| spiv | I didn't find "CHK" too cryptic, but perhaps I'm just odd :) | 06:30 |
| lifeless | abentley: this list: | 06:31 |
| lifeless | The undecided aspects, which experimentation/modeling is needed on: | 06:31 |
| lifeless | ... | 06:31 |
| lifeless | includes the item for how we break up nodes in the tree | 06:31 |
| abentley | lifeless: It doesn't actually say that, though. I had to re-read it 3 times to guess that "should we canonicalise nodes by size rules, or (only applies to a name map that doesn't hash keys) by directory membership" was addressingthat. | 06:34 |
| lifeless | abentley: sorry :) | 06:35 |
| lifeless | abentley: I'm quite deeply embedded in this now, after some months of lead up; I'll try to be more clear in future | 06:35 |
| lifeless | abentley: though there is a tradeoff in repeating content from the design work (which is in doc/developers/inventory.txt in bzr.dev) | 06:36 |
| abentley | lifeless: Yes, there is a balance to be struck. | 06:42 |
| lifeless | abentley: I just an image of a set of scales being hit repeatedly | 06:44 |
| lifeless | abentley: :) | 06:44 |
| === cody-somerville_ is now known as cody-somerville | ||
| markh | poolie: uploaded | 06:53 |
| poolie | thanks! | 06:56 |
| poolie | markh, could you send me a brief roadmap of what you'd like to do next on tortoise? | 06:57 |
| markh | sure | 06:57 |
| vila | hi all | 07:03 |
| vila | spiv: any reason you didn't re-vote on 'regression on OSX in TestReadMergeableFromUrl.test_smart_server_connection_reset' ? | 07:17 |
| lifeless | spiv: ping | 07:25 |
| lifeless | spiv: I have a wtf moment in check | 07:25 |
| lifeless | spiv: in repository.py, line 3259 for me is: | 07:25 |
| lifeless | knit_parents = parent_map[key] | 07:26 |
| lifeless | this is in a try:except RevisionNotPresent: guard | 07:26 |
| lifeless | but parent_map is a plain dict ? | 07:26 |
| * spiv opens it up | 07:26 | |
| spiv | lifeless: sure looks like a wtf | 07:27 |
| lifeless | spiv: clearly, I'm doing heart surgery here, so I'm seeking option numero duo | 07:27 |
| lifeless | spiv: ok, so its broken code, and the question is 'why do normal repos not hit it' | 07:27 |
| lifeless | spiv: thanks | 07:27 |
| spiv | lifeless: I assume there's a gap in the test coverage :( | 07:27 |
| lifeless | spiv: possibly not | 07:28 |
| spiv | lifeless: hmm, actually | 07:28 |
| lifeless | spiv: possibly its a redundant check that cannot trigger unless something else is broken | 07:28 |
| lifeless | (as in some other code is broken) | 07:28 |
| spiv | lifeless: yeah, that's what I'm suspecting | 07:28 |
| spiv | lifeless: anyway, no need for us both to do the same digging at the same time :) | 07:28 |
| lifeless | spiv: I'm not digging at that :) | 07:29 |
| lifeless | spiv: with consensus on the wtf, I'm ignoring it | 07:29 |
| spiv | Ah. Well, I still intend not to get side-tracked then :P | 07:29 |
| lifeless | spiv: good choice :) | 07:29 |
| spiv | vila: oh, I didn't re-read the new patch carefully, I thought it was just updating == to is. I see now it also moved it to the right layer. | 07:30 |
| poolie | lifeless: did you call? | 07:30 |
| lifeless | poolie: no | 07:30 |
| spiv | vila: it'd be nice to have a test that reliably fails (on all platforms) without this fix. | 07:31 |
| spiv | vila: I *think* that's probably feasible using the _DisconnectingTCPServer in test_bundle (i.e. the same way that is triggering test failures for you atm) | 07:33 |
| vila | spiv: I'll look into that, do you also want it to apply to all SmartMedium classes ? | 07:33 |
| vila | well, may be not all, the pipe one may not be relevant | 07:34 |
| spiv | vila: e.g., start a _DisconnectingTCPServer, create a SmartTCPClientMedium pointing at it, and then try client_medium.read_bytes(1) | 07:34 |
| spiv | Well, it'd be good to have equivalent tests for all SmartMedium classes, but it can't be the exact same test. | 07:35 |
| spiv | Pipes don't talk to sockets and get socket.errors, after all :) | 07:35 |
| jdrake | bzr is *sweet* | 07:36 |
| vila | sure, and socket.error may not be relevant either for http | 07:36 |
| spiv | Right. | 07:36 |
| spiv | I certainly wouldn't object to doing that :) | 07:37 |
| vila | spiv: Ok, I read that as BB:resubmit then :) Thanks | 07:38 |
| spiv | But I wouldn't hold up landing the fix to this medium while working on unique tests for all medium implementations. | 07:38 |
| spiv | So, bb:tweak :) | 07:38 |
| jdrake | I can actually remember how to use some of the commands, unlike cvs | 07:38 |
| spiv | jdrake: that's because we don't use "update" to do three different operations ;) | 07:38 |
| jdrake | haha | 07:39 |
| jdrake | I might actually be able to use bzr to do more than just code with school coming up. | 07:39 |
| spiv | vila: bb:tweak formally given | 07:40 |
| vila | spiv: ok, thanks | 07:42 |
| lifeless | abentley: if you're around, do you remember the precise in-memory difference between a rich-root inv and a non-rich-root ? | 07:43 |
| lifeless | abentley: actually, nvm, asking that question clued me in to the answer | 07:43 |
| robsta | hi lifeless | 07:43 |
| robsta | lifeless: jelmer hinted you might know a workaround for phantom references messing up "diff" | 07:44 |
| robsta | (bug#275861) | 07:44 |
| robsta | oh "ghost revisions" it's called | 07:45 |
| lifeless | robsta: hi; uhm, I don't think I do | 07:46 |
| lifeless | robsta: did he hint with any more detail ? | 07:46 |
| lifeless | jelmer: ^ EWHYME? | 07:46 |
| robsta | lifeless: no; is this specific to svn server-side? | 07:46 |
| lifeless | robsta: yes, bzr-svn exercises the ghost capabilities most strongly of anything bar 'baz-import' which I think has actually been deleted from bzrtools now | 07:47 |
| lifeless | robsta: last I heard jelmer was working on changing a bunch of stuff to fit what bzr's core looks for more; I don't know if he has | 07:48 |
| lifeless | robsta: BTW, orthogonal thing, you might like to try the 'development2' format in bzr.dev; it uses the btree stuff I was doing back @ guadec; the new compressor isn't finalised yet, but the index stuff helps quite a bit | 07:49 |
| robsta | lifeless: define "quite a bit" | 07:49 |
| robsta | lifeless: i tried going back to bzr-playground.gnome.org, but when i merge my svn into the bzr branch there's an error about rich-root | 07:50 |
| lifeless | robsta: depending on specific workload, up to 10 times faster, or more. | 07:50 |
| lifeless | robsta: pastebin the rich root error please | 07:50 |
| robsta | speed is not the problem, the problem is that diff bails on me | 07:51 |
| lifeless | robsta: right, did I mention orthogonal? | 07:51 |
| robsta | lifeless: http://pastebin.com/m36aec880 | 07:54 |
| * robsta prefers to stay one-dimensional | 07:55 | |
| lifeless | that would be the whiskey dimension? | 07:55 |
| lifeless | run bzr info -v locally please | 07:55 |
| lifeless | specifically on gtk-css-engine-bzr | 07:55 |
| robsta | http://pastebin.com/m6f95d2bf | 07:56 |
| lifeless | no idea *how* you got that setup; but its not a bzr-svn compatible local repository | 07:57 |
| lifeless | back it up, then bzr upgrade --rich-root-pack | 07:57 |
| lifeless | then try again | 07:57 |
| robsta | lifeless: yay | 07:58 |
| robsta | lifeless: so does this still have ghost references, or can i push --overwrite this to the upstream svn? | 07:58 |
| lifeless | robsta: give it a shot; I disclaim all knowledge of code internals | 07:59 |
| lifeless | svn is atomic yeah? whats the worst could happen :P | 07:59 |
| poolie | vila, yeah, let's talk here | 08:00 |
| vila | Discussing with John, it appears that log.py miss an API with revids (that's the main blocking part for missing) | 08:00 |
| vila | <vila> either that or some variation where you give the list of revisions you want to show | 08:01 |
| vila | <vila> roughly speaking, log is designed around revnos with shortcuts to avoid O(history) when only mainline revisions are needed | 08:01 |
| lifeless | vila: ^ oh yeah, re ghosts, bzr-svn, major user. | 08:01 |
| vila | lifeless: thanks, sorry, I still need to send that mail :-/ | 08:01 |
| vila | lifeless: but it's not forgotten ! | 08:01 |
| robsta | lifeless: "No new revisions to push." can i force this somehow? | 08:03 |
| robsta | lifeless: for some reason svn is like 30 revs ahead | 08:04 |
| vila | I (well jam too :) think log.py should evolve in a direction where we can calculate revnos on-demand | 08:04 |
| poolie | vila, i think that idea of jam's that we should show why some revisions are included is interestning | 08:04 |
| poolie | > the true solution is to be able to get revnos without being O(history) | 08:04 |
| poolie | right, that would be highly useful | 08:05 |
| vila | sure, the two are related, but getting revnos without being O(history) is the root | 08:05 |
| poolie | so as i understand there are two threads towards that - either caching them, or looking for algorithms that let us skip larger parts of the graph | 08:05 |
| vila | another one being changing the revno definition, but for compatibility I don't want to *start* with that | 08:06 |
| vila | an intermediate solution is also to use gdfo | 08:06 |
| vila | gdfo == Greatest Distance From Origin | 08:07 |
| vila | which could also help spiv case in Batch get_parent_map HPSS calls made from InterRepo._walk_to_common_revisions | 08:07 |
| vila | I know that but I'm not able to explain it clearly just yet :-/ | 08:08 |
| vila | roughly, we indirectly batches requests when bisecting today, using gdfo can help batching requests in a more controlled way | 08:08 |
| lifeless | robsta: svn has new content? | 08:09 |
| lifeless | robsta: or just a higher 'revno' ? | 08:09 |
| robsta | lifeless: just revno, just pulled everything into the bzr tree | 08:09 |
| lifeless | robsta: revno is per-branch, so it sounds like no-problem to me, or am I missing something? | 08:10 |
| poolie | vila, so as far as scheduling it, i'd be looking at: is it likely you'll make progress on it, does it matter to guilhem and other users, and should we be concentrating on something else instead | 08:10 |
| poolie | i would say the startup overhead for log does matter to people | 08:10 |
| lifeless | robsta: I have to go now; sorry | 08:11 |
| lifeless | robsta: uhm, I'd hope jelmer is up soon | 08:11 |
| vila | I'm surely making progress on it but I need some more time to show results | 08:11 |
| lifeless | bye poolie | 08:11 |
| lifeless | and vila etc | 08:11 |
| robsta | lifeless: will use it, should work, thanks! | 08:11 |
| vila | the scale being days | 08:11 |
| poolie | night lifeless | 08:11 |
| vila | lifeless: cu | 08:11 |
| vila | the scale being days, several days, but not more than two weeks I'd say | 08:11 |
| fullermd | Well, on the downside, getting log running IS awfully slow sometimes... | 08:11 |
| fullermd | But on the sorta-upside, any time I feel like log is too slow, I can just run log -v to jolt myself. | 08:12 |
| vila | another aspect, thanks fullermd, is to make log really streamed | 08:12 |
| fullermd | We're storing the revno of HEAD in the branch. I can't help but feel we're not USING it, though... | 08:13 |
| vila | another option being to *not* show revnos for people who want really fast log :) | 08:13 |
| * spiv goes to the shops | 08:13 | |
| vila | fullermd: we use it ! | 08:13 |
| vila | all shortcuts are based on that | 08:13 |
| poolie | vila, or we could default to log --line, and make sure that it does not compute non-mainline revisions | 08:13 |
| poolie | i think that may be the easiest in some ways? | 08:13 |
| vila | poolie: I think we do already | 08:13 |
| poolie | do you know what's the main thing in the profile of --line? | 08:14 |
| poolie | hm | 08:15 |
| fullermd | That's even sadder, then. | 08:15 |
| poolie | well, perhaps that's beside the point | 08:15 |
| poolie | fullermd: what is? | 08:15 |
| fullermd | log --forward --short -r-10.. of bzr.dev (with bzr dev), with all the caches heated up and all, takes like 3 seconds. | 08:16 |
| vila | I concentrate on higher level stuff so far but plan to measure progress on how things go | 08:16 |
| fullermd | I assumed at least some of that was eaten up walking back to origin to figure out the revnos. | 08:16 |
| poolie | hm, it's about 800ms for me... | 08:16 |
| fullermd | 2.608u 0.223s 0:02.84 99.2% | 08:17 |
| vila | fullermd: come on, --forward is just asking for slowness :) | 08:17 |
| vila | at least for now | 08:17 |
| fullermd | Doesn't make any distinguishable difference :p | 08:18 |
| poolie | hm | 08:18 |
| vila | roughly, actually, log is based on the idea that we built the history we need (the long part) then we issue the formatted text we want for each revision | 08:18 |
| fullermd | Now, granted, my system isn't the speediest on the planet. But still, it's fast enough that Firefox is almost usable a good half of the time. | 08:18 |
| poolie | anyhow | 08:18 |
| vila | What I'd want to do is make it more streamed: walk the needed graph, filter revisions, display formatted text | 08:19 |
| luks | jelmer: are you around? | 09:09 |
| poolie | hi luks | 09:21 |
| luks | hi | 09:22 |
| luks | ok, now I'm really confused | 09:41 |
| luks | I thought `bzr dpush` from bzr-svn was supposed to rebase my branch | 09:41 |
| luks | but it kept my bzr revision untouched, so I deleted the bzr-svn cache, tried to branch again and I still get the original revision | 09:42 |
| bob2 | hm, so long since I modified a chatscript | 10:00 |
| bob2 | oops | 10:00 |
| No` | hi bazaarians | 10:07 |
| jelmer | luks, somewhat | 10:15 |
| jelmer | luks, it will rebase your *local* branch | 10:15 |
| jelmer | if necessary | 10:15 |
| luks | jelmer: yeah, the thing is that it did not | 10:16 |
| luks | jelmer: at least from what I can see | 10:16 |
| luks | jelmer: and I don't understand where is the info (revid, etc.) stored, because it's not in SVN | 10:16 |
| jelmer | luks, it will also not rebase if it didn't have to push anything | 10:16 |
| luks | jelmer: it pushed one revision, I'll try to branch on a completely clean machine | 10:17 |
| lifeless | jelmer: robsta has some issues | 10:17 |
| robsta | lifeless: should i attach the repo tarball to the bug (1.7M bz2) = | 10:20 |
| lifeless | robsta: sure | 10:20 |
| lifeless | jelmer: I am not here right now, but all I had robsta do was upgrade to rich root (they weren't, for some ??? reason - don't know how anything had worked before then) | 10:21 |
| lifeless | jelmer: but now it has a missing text error, I'm suspecting some bzr-svn interaction bug; perhaps you can chat in detail with robsta to figure out exactly what's happened | 10:21 |
| robsta | #277043, fyi | 10:23 |
| Se6ast | Hi guys. I do have a small project versioned with bzr (personal version control in the guide), myproj/subprojA. so in subprojA there is a .bzr repo with the full history. However, I am now adding other sub-projects: myproj/subprojB, myproj/subprojC and I would like to have a new bzr repo with everything in myproj. So I cd myproj; bzr init. How can I pull all the versioning history of subprojA into it ? with merge? in myproj if I do bzr merge subproj | 10:26 |
| jelmer | lifeless, robsta: I don't have time to look into it at the moment, but have a look when I do. Thanks for filing a bug. | 10:27 |
| robsta | n/p | 10:30 |
| jml | is there a revisionspec for branch parent? | 10:54 |
| visik7 | I want to checkout django-1.0 with bzr | 11:03 |
| visik7 | bzr get http://code.djangoproject.com/svn/django/trunk django-bzr | 11:03 |
| visik7 | works | 11:03 |
| visik7 | while | 11:03 |
| visik7 | bzr get http://code.djangoproject.com/svn/django/tags/releases/1.0 django | 11:04 |
| visik7 | doesn't | 11:04 |
| visik7 | the 2 path works with the svn command | 11:04 |
| lifeless | jml: :parent ? | 11:22 |
| jml | lifeless: nope. maybe my bzr is too old. | 11:22 |
| lifeless | oh thats a location alias | 11:23 |
| lifeless | meh | 11:23 |
| liw | if I convert my branch to rich-root-pack format, how likely will I make other people suffer? (the main person I collaborate with has that format and that makes it hard for me to currently accept his bundles) | 12:14 |
| === bac_afk is now known as bac | ||
| === kiko_ is now known as kiko | ||
| g0nzal0 | hi there! | 15:43 |
| g0nzal0 | I'm trying to use bzr-svn | 15:43 |
| g0nzal0 | I installed it using "sudo easy_install bzr-svn" | 15:43 |
| g0nzal0 | but it doesn't seem to be working :( | 15:43 |
| g0nzal0 | http://dpaste.com/81931/ | 15:46 |
| Verterok | g0nzal0: what is the name of the directory were easy_install "installed"? | 15:58 |
| g0nzal0 | /usr/lib/python2.5/site-packages/bzr_svn-0.4.13-py2.5-linux-i686.egg | 15:59 |
| Verterok | ohh eggs | 15:59 |
| Verterok | g0nzal0: I'm not sure that bzr plugins work as eggs at all | 16:00 |
| g0nzal0 | I see, I'll try something else, thanks for the info :) | 16:00 |
| Verterok | g0nzal0: try installing it using plain old setup.py and avoid egg | 16:00 |
| g0nzal0 | yes, I'm onto it | 16:00 |
| Verterok | g0nzal0: np | 16:01 |
| === alperkanat is now known as alperkanat|away | ||
| g0nzal0 | Verterok: :( | 16:05 |
| g0nzal0 | http://dpaste.com/81935/ | 16:05 |
| === alperkanat|away is now known as alperkanat | ||
| Verterok | let's see | 16:12 |
| Verterok | g0nzal0: run it with -Derror | 16:12 |
| Verterok | g0nzal0: i.e: bzr -Derror plugins | 16:13 |
| g0nzal0 | Verterok: I had bzr installed with easy_install too | 16:18 |
| g0nzal0 | Verterok: took that away | 16:19 |
| g0nzal0 | Verterok: and reinstalled it from ppa | 16:19 |
| g0nzal0 | Verterok: (I use Ubuntu) | 16:19 |
| g0nzal0 | $ bzr -Derror plugins | 16:19 |
| g0nzal0 | gtk 0.94.0 | 16:19 |
| g0nzal0 | Graphical support for Bazaar using GTK. | 16:19 |
| g0nzal0 | launchpad | 16:19 |
| g0nzal0 | Launchpad.net integration plugin for Bazaar. | 16:19 |
| g0nzal0 | svn 0.4.13 | 16:19 |
| g0nzal0 | Support for Subversion branches | 16:19 |
| g0nzal0 | :-D | 16:19 |
| Verterok | g0nzal0: goooood, ppa is goood :) | 16:19 |
| g0nzal0 | didn't know about it, it rocks! :) | 16:20 |
| === alperkanat is now known as alperkanat|away | ||
| vila | la la la, Russian roulette, pqm blocked | 16:23 |
| g0nzal0 | I'm branching django-survey with bzr-branch!!! | 16:23 |
| === BasicPRO is now known as BasicOSX | ||
| jam | vila: *why* does it always happen from *your* submissions? | 16:27 |
| jam | I'm really quite surprised | 16:28 |
| jam | I wonder if it is merging from lp: that is causing problems | 16:28 |
| vila | I had one submission passing without problem from lp earlier | 16:28 |
| jam | maybe it doesn't like "osx" in names | 16:29 |
| vila | what surprised me the most is that the submissions are successful while someone is *killing* a process (knowing what process may help though) | 16:29 |
| jam | vila: I just pinged mthaddon, and he said he got it going again | 16:30 |
| vila | thanks to him and you, again... | 16:30 |
| vila | Most probably, bugs are a big family and some vendetta is going on each time I fix a nasty one :) | 16:31 |
| === alperkanat|away is now known as alperkanat | ||
| === alperkanat is now known as alperkanat|away | ||
| === alperkanat|away is now known as alperkanat | ||
| === kiko is now known as kiko-fud | ||
| _MMA_ | Command to upload *all* unknown files in a existing branch? | 18:05 |
| _MMA_ | bzr add ? | 18:05 |
| beuno | yeap | 18:06 |
| beuno | well | 18:06 |
| beuno | depends on your definition of *all* | 18:06 |
| beuno | add won't add ignored files | 18:06 |
| _MMA_ | Anything shown as "unknown". | 18:06 |
| beuno | yeap | 18:07 |
| beuno | bzr add | 18:07 |
| _MMA_ | Oh. I thought it had to have something after "add". Like "bzr add all" or something. :) | 18:08 |
| _MMA_ | cool | 18:08 |
| beuno | nope nope, it's the default | 18:11 |
| beuno | you have to add something if you *just* want to add one file | 18:11 |
| _MMA_ | I see. | 18:12 |
| === rockstar` is now known as rockstar | ||
| === kiko-fud is now known as kiko | ||
| idx_foo | Installing bzr for eclipse, I have bzr, jdk, eclipse and xml plugin of correct versions. | 18:49 |
| idx_foo | In Window -> Preferences, turning on icon decorators causes "An error has occured. See error log for details" | 18:50 |
| Verterok | idx_foo: did you configured the bzr executable in Preferences --> Team --> Bazaar? | 18:50 |
| idx_foo | When trying to share a project, I choose a bzr path, click next, it flashes up a progress dialog very quickly, then does nothing. | 18:51 |
| idx_foo | Verterok: yes, to /usr/bin/bzr | 18:51 |
| idx_foo | bzr works fine, and the --xml option does too. | 18:51 |
| Verterok | idx_foo: which version of bzr-eclipse and xmloutput? | 18:51 |
| Verterok | also, what is the name of xmloutput plugin folder in .bazaar/plugins ? | 18:52 |
| idx_foo | bzr_xmloutput_0_8_0 | 18:52 |
| Verterok | (it should be xmloutput) | 18:52 |
| idx_foo | bzr eclipse 1.1.0 | 18:52 |
| idx_foo | oh | 18:52 |
| idx_foo | I'll try that | 18:52 |
| Verterok | idx_foo: rename bzr_xmloutput_0_8_0 to xmloutput :) | 18:53 |
| idx_foo | nope | 18:54 |
| idx_foo | Now the error doesn't happen in the pref window | 18:54 |
| idx_foo | But still can't share the project | 18:55 |
| idx_foo | I'll be back later | 18:55 |
| === idx_foo is now known as idx_foo_away | ||
| Verterok | idx_foo_away: when you come back, please check the log at <workspace>/.metadata/.log | 18:56 |
| === jfroy|work is now known as jfroy | ||
| Stavros | hello | 19:01 |
| Stavros | my repo is in knit4 format and i need to upgrade, which is a good format to use? | 19:01 |
| beuno | Stavros, packs 0.92 if you're not into any weird stuff | 19:01 |
| Stavros | beuno: does sodomy count? | 19:01 |
| beuno | well, weird is a very dodgy concept | 19:02 |
| beuno | I'd say, go with packs, and if something doesn't work, you can always change again :) | 19:02 |
| Stavros | that doesn't work | 19:02 |
| Stavros | bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>. Does not support rich root data. | 19:02 |
| beuno | ah | 19:02 |
| beuno | rich root | 19:02 |
| Stavros | and it broke my repo | 19:02 |
| Stavros | good thing it made a backup | 19:02 |
| Stavros | what's rich root? | 19:03 |
| beuno | bzr makes backups when upgrading | 19:03 |
| beuno | bzr.backup/ | 19:03 |
| Stavros | i moved it back and it works | 19:03 |
| Stavros | but no upgrade | 19:03 |
| Stavros | why do i have this rich root? | 19:03 |
| beuno | Stavros, I think you have to do bzr upgrade --rich-root-pack | 19:03 |
| === mw___ is now known as mw|food | ||
| Stavros | ôçáô óååìó Ă´ĂŻ çáùå òïñêåä, ôçáĂĂŞĂł | 19:04 |
| Stavros | ñåñ | 19:04 |
| Stavros | damn | 19:04 |
| Stavros | that seems to have worked, thanks | 19:04 |
| nihilocrat | hello | 19:07 |
| === Verterok is now known as Verterok|out | ||
| nihilocrat | I'm having an issue with several of my projects... there are some files that constantly have conflicts (they are binary and necessarily changed every commit) | 19:09 |
| nihilocrat | I solve them by just copying *.OTHER over the original file and resolving it | 19:09 |
| nihilocrat | but in some cases I am getting conflicts where it says some file called <filename>.OTHER.OTHER.OTHER<etc> is conflicted | 19:09 |
| nihilocrat | I have no idea how that happens and how to get it to go back to just being <filename>.OTHER | 19:10 |
| beuno | nihilocrat, are you running "bzr resolve FILENAME" after you copy the file over the existing one? | 19:10 |
| nihilocrat | yes | 19:11 |
| nihilocrat | here's what I usually do: | 19:11 |
| nihilocrat | mv file.OTHER file | 19:11 |
| nihilocrat | resolve file | 19:11 |
| nihilocrat | *bzr resolve | 19:11 |
| beuno | and then you commit? | 19:11 |
| nihilocrat | the mv is just normal old mv | 19:11 |
| nihilocrat | no, I don't commit, usually it's the case where this is a working copy that I'm pushing to | 19:12 |
| nihilocrat | (web app code) | 19:12 |
| beuno | I see, the remote branch is the one with .OTHER.OTHER...? | 19:13 |
| nihilocrat | yeah | 19:13 |
| nihilocrat | usually I push, and then update | 19:14 |
| nihilocrat | and then the conflicts appear | 19:14 |
| beuno | yes, that's happened to me | 19:14 |
| beuno | I'm not exactly sure why that happens (I should probably look into it) | 19:14 |
| beuno | but, what I have to do, is resolve them remotely, and commit | 19:14 |
| nihilocrat | due to annoying firewall configuration that can't be changed, I can't just bind to the master branch and update | 19:14 |
| nihilocrat | I have to push | 19:14 |
| nihilocrat | ok | 19:14 |
| beuno | it only happens sometimes | 19:14 |
| nihilocrat | hmm | 19:15 |
| beuno | so, I haven't needed to look into it too much | 19:15 |
| === idx_foo_away is now known as idx_foo | ||
| nihilocrat | I might try resolving, committing, then pulling | 19:15 |
| beuno | I'd also recommend running "bzr reconcile" on the remote branch | 19:15 |
| nihilocrat | see if it at least gets rid of OTHER.OTHER.OTHER | 19:15 |
| nihilocrat | oh | 19:15 |
| nihilocrat | never heard of that command | 19:15 |
| nihilocrat | I'll look into it | 19:15 |
| beuno | nihilocrat, make sure the remote repo is clean and resolved, commit, resolve | 19:15 |
| beuno | and pull | 19:16 |
| beuno | should work well from then on | 19:16 |
| nihilocrat | ok | 19:16 |
| idx_foo | Ok, so I'm installing bzr eclipse, but when I go to Team > Share Project, at the Select Directory screen, "Finish" pops up a progress bar that dissapeares quickly, and doe not xlose the wizard. The project cannot be shared as a result. | 19:16 |
| === Verterok|out is now known as Verterok | ||
| Verterok | idx_foo: go to preferences -> team -> bazaar | 19:17 |
| idx_foo | yes | 19:17 |
| idx_foo | done | 19:18 |
| Verterok | idx_foo: there is textfield to speficy the port of the xmltpc service, and just above it a label that indicate what kind of client was detected | 19:18 |
| idx_foo | XmlRpcClient | 19:18 |
| Verterok | so far so good :) | 19:18 |
| idx_foo | Recheck changes nothing | 19:18 |
| Verterok | that means that the xmloutput is correctly installed | 19:19 |
| idx_foo | Btw, before hand to check bzr from the terminal I did "bzr init" and then "bzr add somefolder" | 19:19 |
| Verterok | idx_foo: np, thanks ok | 19:19 |
| idx_foo | Successfully, but I don't know how that will change Eclipse's behaviour | 19:19 |
| Verterok | idx_foo: please check the log file at <workspace>/.metadata/.log | 19:19 |
| Verterok | idx_foo: that should not affect eclipse | 19:20 |
| Verterok | idx_foo: of open the error log view if you have de SDK | 19:20 |
| idx_foo | what SDK is this | 19:20 |
| idx_foo | I have .log open in gedit now, rather huge though | 19:20 |
| idx_foo | I'm getting "java.lang.NoClassDefFoundError: org/eclipse/jface/viewers/BaseLabelProvider" | 19:21 |
| Verterok | yeap, it grow and grow, until you zap it | 19:21 |
| Verterok | idx_foo: what version of eclipse? | 19:21 |
| idx_foo | 3.2.2 | 19:21 |
| idx_foo | On Ubuntu 8.10 | 19:21 |
| idx_foo | 8.04 even | 19:21 |
| Verterok | bzr-eclipse only works with >= 3.3 | 19:21 |
| idx_foo | Heh | 19:21 |
| idx_foo | Lets hope there's a deb of 3.3 somewhere | 19:22 |
| idx_foo | So in other words Ubuntu's repository is rubbish | 19:22 |
| idx_foo | Sorry about that, must have skimmed over the Eclipse req. | 19:22 |
| Verterok | idx_foo: I don't think so :(, but installing eclipse is just unzip/untar the archive | 19:22 |
| Verterok | idx_foo: I think all debian based distros lacks an updated eclipse | 19:23 |
| Verterok | idx_foo: np :) | 19:23 |
| Verterok | idx_foo: there is Bug #123064 | 19:24 |
| ubottu | Launchpad bug 123064 in eclipse "Upgrade to Eclipse 3.4.1" [Wishlist,Confirmed] https://launchpad.net/bugs/123064 | 19:24 |
| idx_foo | Any other good IDEs with bazaar integrated? | 19:25 |
| idx_foo | For Linux that is | 19:25 |
| Verterok | idx_foo: just download the lastest version from eclipse.org, unzip and run :) | 19:28 |
| Verterok | idx_foo: I think gedit is integrated with bzr | 19:28 |
| beuno | idx_foo, https://edge.launchpad.net/bzr-gedit | 19:28 |
| beuno | hi Verterok | 19:28 |
| Verterok | idx_foo: also, PIDA for a list of all: http://bazaar-vcs.org/IDEIntegration | 19:29 |
| Verterok | beuno: hey there! | 19:29 |
| === jelmer is now known as Guest30327 | ||
| idx_foo | Working fine now. Thanks for the help Verterok | 19:30 |
| Verterok | np :) | 19:30 |
| idx_foo | I just hope this is sufficiently different/better than svn to warrant the switch | 19:30 |
| * Verterok invites idx_foo to file bugs as he encounter them :) | 19:31 | |
| idx_foo | But is failing miserably when installed on the wrong version of Eclipse a bug, or a deterent? :) | 19:31 |
| Verterok | idx_foo: bzr-eclipse is under active development, but the basic workflows are covered | 19:31 |
| Verterok | he left :p | 19:33 |
| === Verterok is now known as Verterok|out | ||
| rockstar | jam, want to do TWiB in an hour? | 19:39 |
| === Guest30327 is now known as jelmer | ||
| jelmer | rockstar: hi | 20:19 |
| persia | Hi. I've started to use bzr a lot lately, and wanted to ask about the chances of a much more stupid algorithm for pulling/pushing/merging to help speed up my use case. | 20:20 |
| jelmer | hi persia | 20:20 |
| jelmer | persia: what's your use case? | 20:20 |
| persia | Hi jelmer. | 20:20 |
| persia | I've *lots* of bandwidth (gigabit fibre ethernet to the international routers), but also lots of latency (about 150-200ms to launchpad). | 20:21 |
| persia | For protocols like FTP and HTTP, I get to take advantage of increasing TCP windows, and get lots of packets in flight. | 20:21 |
| persia | This means I get to use 2-3Mbps of bandwidth at that latency. | 20:22 |
| persia | For bzr, it seems there are *lots* of little transactions, trying to save me bandwidth, but each one starts with a small TCP window, and with my latency, it makes it *very* slow. | 20:22 |
| persia | So, what I'd like is some switch I can pass to tell bzr to be stupid, and just grab the entire repo on the other end as one big upload/download, and then process it afterwards. | 20:23 |
| jelmer | persia: there's a lot of incremental work going on trying to reduce the number of round trips | 20:23 |
| persia | OK. That helps some. Is that related to work to make it push more per trip? | 20:24 |
| beuno | persia, one thing to make sure is that you're using packs format (you probably are if the repos are new enough) | 20:24 |
| persia | Unless I'm downloading a few megabytes, I haven't a chance of reaching reasonable transit speeds. | 20:24 |
| jelmer | persia: for the smart server, yes | 20:24 |
| jelmer | persia: for FTP and HTTP a flag like the one you describe could indeed help | 20:25 |
| jelmer | (I'm in the same situation btw, although my latency isn't as bad as yours) | 20:26 |
| persia | Well, generally, those are just one big file. websites that have *lots* of little files to try to make it feel faster for people with low bandwidth or low latency are slow for me though. | 20:26 |
| beuno | persia, the core devs are almost all in australia. That puts their focus on latency quite a lot :) | 20:27 |
| persia | Yeah. My combination of bandwidth and latency seems to be a corner case, and as I've spent 3 hours waiting for bzr to do stuff today, I figured I'd come by and see if I could publicise my use case to make it faster. | 20:27 |
| beuno | the flag for bigger chunks in http/ftp does sounds interesting | 20:28 |
| persia | Well yes, but the situation in Australia is different: nobody has much more than maybe 10Mbps there, and the undersea trunks are usually congeste. | 20:28 |
| persia | s/.$/d./ | 20:28 |
| beuno | true | 20:28 |
| beuno | persia, feel compelled enough to start a thread in the mailing list? | 20:29 |
| persia | So they focus on latency, but can't take advantage of TCP windows like here or in Korea. | 20:29 |
| persia | beuno: I could, if it's likely. I don't know how many bzr LP users are in Japan or Korea, and I don't think this environment is common anywhere else. | 20:29 |
| persia | Also, what's the mailing list? | 20:30 |
| jelmer | bazaar@lists.canonical.com | 20:30 |
| persia | OK. Is there likely to be space in the development queue that optimising for such a situation is likely, or is it more interesting to focus on other use cases for now, and I should test again with 1.7 or 1.8 and start a thread then? | 20:32 |
| persia | (feel free to remove any duplicate words when parsing) | 20:32 |
| === alperkanat is now known as alperkanat|away | ||
| beuno | persia, speed is the main focus ATM I believe | 20:36 |
| beuno | so this sounds entirely appropriate | 20:36 |
| persia | OK, then adding my use case is probably worthwhile. I'll send an email during my next pause. Thanks :) | 20:37 |
| beuno | :) | 20:37 |
| === alperkanat|away is now known as alperkanat | ||
| === mark2 is now known as markh | ||
| pygi | hi hi | 20:46 |
| AmanicA | I made a super cool linux startup script for loggerhead today. Do markh/beuno think I should make a branch/patch adding it to the mainline? | 20:49 |
| beuno | AmanicA, merge proposal! | 20:53 |
| beuno | yes :) | 20:53 |
| AmanicA | beuno, like in branch or like in bundle? | 20:53 |
| beuno | AmanicA, branch | 20:54 |
| beuno | and file a merge proposal in Launchpad | 20:55 |
| AmanicA | beuno, atm I call the script loggerheadd (the double dd is not a typo) and I added it to the root. is that ok? | 20:55 |
| AmanicA | beuno: cool will do. hope I dont overhelm you guys, but I was itching a lot this week :) | 20:55 |
| beuno | AmanicA, I'd try and name it something less confusing :) | 20:56 |
| beuno | and, the rest you can get from the review | 20:56 |
| beuno | AmanicA, we *love* contributions | 20:56 |
| AmanicA | beuno: any ideas? | 20:56 |
| === alperkanat is now known as alperkanat|away | ||
| AmanicA | cool:) | 20:56 |
| beuno | we sometimes suck on responding in a proper time frame, but we really love 'em | 20:56 |
| beuno | AmanicA, what does the script do exactly? | 20:56 |
| AmanicA | its a /etc/init.d script | 20:57 |
| AmanicA | (and lots of them end in d for daemon) | 20:57 |
| beuno | I see | 20:57 |
| beuno | hm, tough call | 20:57 |
| beuno | I'd say, file it as "noname", and we can go through it during the review | 20:57 |
| AmanicA | ah, then I can tust leave it like is, and if the reviewer have a bettername, we can update it :P | 20:58 |
| AmanicA | s/tust/just/ | 20:59 |
| beuno | sure | 20:59 |
| AmanicA | any idea when launchpad will support stacking properly? as its a bit of overhead to upload branches for single file changes.. | 21:00 |
| beuno | AmanicA, well, it sort-of does now | 21:00 |
| beuno | if we upgrade the loggerhead branch to 1.6 format | 21:01 |
| beuno | you should be able to stack | 21:01 |
| AmanicA | oh, so not ATM :( | 21:01 |
| beuno | let's wait for mwhudson to come by, and ask him if he's cool with that | 21:01 |
| AmanicA | no rush, I just wondered | 21:01 |
| beuno | well, I've stacked things | 21:01 |
| AmanicA | loggerhead is luckily small | 21:01 |
| beuno | it has some gotchas | 21:01 |
| beuno | but it works | 21:01 |
| beuno | and I'd love to have more people test it | 21:02 |
| AmanicA | I'm thinking uploading bzr branches could get hecktick | 21:02 |
| AmanicA | bzr i.e. bzr.dev.my_fix etc. | 21:03 |
| beuno | yeap yeap | 21:03 |
| === mw|food is now known as mw_______ | ||
| beuno | it's going to be very usable very soon | 21:03 |
| AmanicA | can hardly wait:) | 21:04 |
| === mw_______ is now known as mw_________ | ||
| blueyed | jelmer: about bzr-shell-hooks: do you think it makes sense to chdir() to the branch root, before executing the command? | 21:05 |
| === mw_________ is now known as mw|out | ||
| jelmer | blueyed: sure | 21:08 |
| === mw|out is now known as mw | ||
| blueyed | jelmer: how do I get the directory from branch? (or the other way around: can you just add it? :)) | 21:09 |
| === alperkanat|away is now known as alperkanat | ||
| jelmer | blueyed: branch.base IIRC | 21:16 |
| uws | wow, bzr is quite fast! | 21:17 |
| uws | committing 2000 new files takes only a few seconds | 21:17 |
| uws | i now use it for "scratch" version control. putting temp data in bzr, and removing .bzr once in a while if i made sure I didn't screw up :) | 21:18 |
| blueyed | jelmer: yes. and then, I should probably not use urlutils._posix_local_path_from_url directly?! | 21:20 |
| rockstar | jelmer, hi back (sorry, went out to eat some lunch) | 21:21 |
| jelmer | blueyed: branch.transport.local_abspath(".") should work I think | 21:22 |
| jelmer | rockstar: I've finished exporting the bindings of bzr-svn - https://edge.launchpad.net/subvertpy | 21:23 |
| rockstar | jelmer, you used the name! Yippee! | 21:23 |
| * rockstar feels like he contributed. | 21:23 | |
| blueyed | jelmer: great, it works. I'll add that only for the "local" part, i.e. if branch gets set to "local", not when it gets set to "master".. I suppose the latter is for remote operations?! | 21:25 |
| jelmer | blueyed: no, it's for checkouts | 21:25 |
| blueyed | jelmer: ok, so I'll add it for both cases.. however, only when branch.transport is given. Since, on "uncommit" it isn't given.. | 21:29 |
| blueyed | the backtrace then: http://pastebin.com/m6dd9b59e | 21:29 |
| jelmer | blueyed: try branch.bzrdir.root_transport instead | 21:31 |
| AmanicA | sheweet, I made the loggerhead top five contributers list! (without even trying) | 21:33 |
| rocky | jelmer: now you just need to convert trac to use it ;) | 21:37 |
| AmanicA | rocky: :) yup (you know Ive made a gforge plugin which uses) | 21:39 |
| AmanicA | it | 21:39 |
| rocky | AmanicA: hmmm? | 21:39 |
| AmanicA | neveermind | 21:39 |
| blueyed | jelmer: works better. now I'm wondering why 'pre_commit = sh -c "echo \$4 > blogs/inc/_revision.inc.php"' results in 'bzr: ERROR: [Errno 2] No such file or directory'.. something simple like "echo" works.. | 21:41 |
| jelmer | rocky: it can already do that through trac-bzr and bzr-svn ;-) | 21:47 |
| rocky | boo =P | 21:47 |
| jelmer | blueyed: not sure if that escaping will work ok | 21:48 |
| blueyed | jelmer: ok, that's a problem with subprocess.call, which uses the whole command as-is (and it does not exist), would have to pass ["sh", "-c", "..."] + args | 21:48 |
| blueyed | ..but cannot put that in the config (as list) | 21:49 |
| blueyed | jelmer: it would work with shell=True for subprocess.call | 21:57 |
| === ndim_ is now known as nidm | ||
| === nidm is now known as ndim | ||
| jam | persia: still around? | 22:14 |
| jam | There may be a somewhat trivial hack you can do to rebalance one of our algorithms | 22:14 |
| persia | jam: That's exactly the sort of thing I hoped was true :) | 22:14 |
| jam | persia: bzrlib/transport/http/__init__.py | 22:14 |
| jam | around line 344 | 22:15 |
| jam | is "recommended_page_size()" | 22:15 |
| jam | we currently set it to 64kB | 22:15 |
| lifeless | persia: we should be keeping one tcp connection open | 22:16 |
| lifeless | persia: what protocol are you using? | 22:16 |
| persia | lifeless: No idea. I do bzr branch lp:... and bzr push lp:... | 22:16 |
| persia | jam: SO I could just bump that to a couple megabytes, and I'd be happy? | 22:17 |
| lifeless | persia: if you've authenticated, and you probably have both will be over bzr+ssh | 22:17 |
| lifeless | persia: so per bzr command the windows should be expanding as normal; modulo ssh window bugs (have been before, bet there will be again) | 22:17 |
| lifeless | persia: if you're running lots of commands, try setting up a master control connection which may help the windows expand | 22:18 |
| persia | lifeless: OK. Then my guess at the cause is probably wrong. Still takes *way* longer than it ought, and I thought my situation might be odd enough that a hack would help, when it wouldn't help others. | 22:18 |
| lifeless | persia: it may be right; gather some stats:P | 22:19 |
| persia | No, I don't run lots of commands. I branch. I push. I forget about it. A few days later, I delete the cruft. | 22:19 |
| lifeless | persia: I'm simply noting that we won't, per-command, be connecting many many times; 2 perhaps - directory lookup + ssh for data | 22:19 |
| persia | lifeless: That's all? Which version of bzr? (I use 1.3) | 22:21 |
| lifeless | persia: should be any for this use case | 22:22 |
| persia | lifeless: OK. Thanks. I'll try jam's hack anyway, and see if it helps me. Maybe I'm just confused. | 22:23 |
| jam | persia: well depends how you are connecting. my change won't effect bzr+ssh (as it only effects http) | 22:24 |
| persia | Oh, and I'm probably usually using bzr+ssh. Oh well. | 22:24 |
| jam | You might set the one in "bzrlib/transport/remote.py" though | 22:25 |
| lifeless | or you could try out a btree repo :P | 22:26 |
| jam | lifeless: I think btree would actually exacerbate his specific problem, as it doesn't have the concept of minimum request size | 22:26 |
| jam | we haven't hooked in recommended_page_size() handling | 22:26 |
| jam | though I think we could do so at logical-block partitions in the Btree index code | 22:26 |
| jelmer | is there some way to peek at the smart server commands? | 22:26 |
| jam | which avoids some of the inefficiencies in our current system | 22:26 |
| lifeless | jam: I don't think he's identified the problem, just assumed that his network configuration implied a specific issue | 22:27 |
| jelmer | wireshark doesn't work so well at ssh connections? | 22:27 |
| jam | jelmer: -Dhpss ? | 22:27 |
| jam | gives a log of every request | 22:27 |
| jelmer | jam: ah, thanks | 22:27 |
| lifeless | jam: and as such, any test that expands our knowledge is helpful | 22:27 |
| jelmer | yeah, the number of roundtrips with hpss is really bad :-( | 22:28 |
| lifeless | jam: specifically, btree does less roundtrips often just cause of the better fan-out | 22:29 |
| persia | If someone wants to prepare a test script that does stuff, I'm happy to run it against either hardy or intrepid, and return the results. On the other hand, I don't understand most of the recent conversation, so wouldn't know how to produce useful test results. | 22:29 |
| jelmer | it's the limiting factor for me, git seems CPU-bound | 22:29 |
| jelmer | at least this explains why bzr-svn is faster than bzr+ssh for me | 22:33 |
| jelmer | bbl | 22:33 |
| lifeless | persia: don't worry about it; we are testing on high latency stuff at the moment | 22:36 |
| uws | sftp:// feels faster than bzr+ssh:// for me even | 22:37 |
| uws | (no numbers to confirm/deny this) | 22:37 |
| uws | perhaps it's the overhead of starting a python process on my rather slow server | 22:38 |
| persia | lifeless: OK. I just fear you're not going to notice throttling with the congestion in the cables down there :) | 22:38 |
| lifeless | uws: could well be | 22:42 |
| jam | uws: I know spiv just introduced a patch which patches a hole in the bzr+ssh case for push and pull | 22:51 |
| jam | basically, while we are inspecting,sftp/http will download some searching for things that aren't there and cache it | 22:51 |
| jam | bzr+ssh just returns an empty response | 22:51 |
| uws | jam: care to elaborate on what "patches a hole" means? | 22:51 |
| jam | uws: "fixes an edge case" ? | 22:52 |
| uws | oh, I thought "avoid the bzr startup overhead" :) | 22:52 |
| jam | so for push/pull we have to find out what each side doesn't have | 22:52 |
| jam | I guess for bzr+ssh if you have 50 new revisions it may actually send 50 requests and not get anything before it starts finding info | 22:53 |
| jam | while for http and sftp it will be filling in info about the indexes during that time | 22:53 |
| jam | which makes future correspondence faster | 22:53 |
| uws | mkay. | 22:54 |
| jam | basically, you can get 50 round trips with bzr+ssh that don't actually transmit any info | 22:54 |
| jam | which is a bit naughty | 22:54 |
| uws | ah, ok. | 22:54 |
| jam | well, they transmit1 bit of info | 22:55 |
| jam | "not there" | 22:55 |
| jam | rather than 64kB of "not there yet, but here is some other info" | 22:55 |
| jam | I take it back, I reviewed it, but it hasn't landed yet | 22:56 |
| jam | lifeless: I'll note that Index *bandwidth* is the number one issue right now for me doing "bzr up" in my bzr.dev branch. | 22:59 |
| jam | (this is specific to my case) | 22:59 |
| jam | I haven't nailed down all the reasons yet | 22:59 |
| jam | but I have the feeling we have non-clustered revsion-ids | 22:59 |
| jam | like "john@" and "pqm@" | 22:59 |
| jam | so it has to bisect a lot of the index, and it interacts in poor ways with the page expanding algorithm | 23:00 |
| lifeless | jam: right | 23:00 |
| jam | right now, if you make a request for 100-200, it expands to 100-64100 | 23:00 |
| jam | but then if you request 50-100, it expands to 50-64050 | 23:00 |
| jam | I'm thinking to not worry about it for GI, and just work on it a bit with the btree code | 23:01 |
| lifeless | jam: for sure | 23:01 |
| jam | But it means the expansion needs to occur at the index layer, rather than the Transport layer | 23:01 |
| lifeless | jam: having figured out that GI couldn't be really fixed without disk changes, I'm not going to touch it again; it will just throw something else out to do so | 23:01 |
| blueyed | I want to have the revision/revno in a textfile inside the branch and tried the pre_commit hook for this, but the changed file gets not committed. Is this possible after all? (or would I need to do this during deployment and keep it out of the branch) | 23:02 |
| jam | blueyed: there is a "start_commit" hook which you could use, but you won't have the revision_id | 23:03 |
| jam | (I think) | 23:03 |
| jam | I don't know that there is a way to commit a file with the text of the revision_id to come | 23:04 |
| jam | it is possible in bzr's structure, but I don't think we expose a hook at the right time for it. | 23:04 |
| lifeless | and we shouldn't | 23:04 |
| blueyed | jam: start_commit isn't defined with the shell_hooks plugin | 23:04 |
| lifeless | its incompatible with the minimal contract for foreign branch commit support | 23:05 |
| jam | lifeless: I agree that not all foreign formats could support it. I don't think that should absolutely prevent us from doing it | 23:05 |
| lifeless | jam: it should at a minimum make us question very hard | 23:06 |
| lifeless | jam: I don't think its a good idea regardless of foreign formats | 23:06 |
| jam | it is similar in concept to $Keyword$ expansion, and has similar benefits and drawbacks | 23:07 |
| blueyed | lifeless: it would be really handy to provide a $app_revision variable (that's what I was trying to do), or add a suffix like "rXX" to a version number. | 23:07 |
| jam | I think some people would rather get extra conflicts at certain times | 23:07 |
| jam | than not have the ability at all | 23:07 |
| jam | blueyed: you can always run "bzr version-info > my_file.txt" as part of a "build" process | 23:07 |
| jam | which is certainly the recommended way to do it | 23:08 |
| === fta_ is now known as fta | ||
| blueyed | jam: yes, I know.. that's what I've meant with "deploying".. it's a php app after all and there's no "build" process (and also no "deploying" currently). | 23:08 |
| * spiv hops on a train | 23:09 | |
| lifeless | blueyed: doing that on tree building - checkout/pull - is much more reliable | 23:09 |
| blueyed | yes, I see. Thanks. | 23:09 |
| jam | blueyed: have you looked into what "bzr upload" supports? I haven't poked into that code, but it may be a good place to hook in that sort of work | 23:09 |
| blueyed | jam: well, I can see no hooks, but it creates a file .bzr-upload.revid, which could be used probably | 23:23 |
| jam | I'll also mention it is probably easier to get code into a plugin | 23:23 |
| jam | As it has a smaller system-wide effect | 23:23 |
| blueyed | sure. It was only a nice-to-have idea, no problem.. :) | 23:24 |
| beuno | blueyed, it does have a tip-change hook to auto-upload | 23:24 |
| beuno | provided by james_w in a patch ;) | 23:24 |
| jam | blueyed: And on that note, you could use the "post-branch-tip-changed" hook to generate the file after commit | 23:28 |
| jam | but then the file isn't versioned. | 23:28 |
| blueyed | beuno: well, looked in the released version (Intrepid) only.. but found it now.. that's different however (and it's hooking, not being hooked AFAICS).. but I get the idea, that a post-upload hook might get added to the plugin. However, the hidden file would be enough in my case | 23:28 |
| beuno | blueyed, it's in intrepid??? :) | 23:29 |
| blueyed | yes.. as with pre_commit.. that would be the whole idea however (and is why the upload plugin does not fit really).. I'm fine with it after all.. | 23:29 |
| blueyed | beuno: yes, 0.1.0~bzr44-1 | 23:29 |
| beuno | oh, very cool! | 23:29 |
| beuno | I didn't know | 23:30 |
| jam | lifeless: it seems when you landed the btree format repository into bzr.dev, we lost the "convert indexes in place" code. | 23:40 |
| jam | which is a bit of a shame, as it makes it more difficult to set up a test repository | 23:40 |
| jam | does the code in the plugin still work? | 23:41 |
| === Ng_ is now known as Ng | ||
| lifeless | jam: the plugin code needs some adjustments, to use bzr's index logic etc | 23:56 |
| lifeless | jam: the reason I didn't port that code across is that for gc its not helpful; and I don't plan on suggesting that dev2 become a production format ever | 23:57 |
| jam | lifeless: sure, it just makes my life easier when trying to test stuff out :) | 23:57 |
| jam | I'm hacking around it now with a script | 23:57 |
| lifeless | back shortly, fooding | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!