[00:00] <Verterok> heya!
[00:00]  * Verterok waves greetings
[00:00] <Verterok> jfroy: it looks like a bug un setuptools :(
[00:01] <Verterok> jfroy: or an old version
[00:02] <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:03] <Peng_> That's what I get for not reading hte traceback first.
[00:03] <jfroy> Verterok: Ah, I see
[00:04] <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:05] <jfroy> Verterok: seems to work great
[00:06] <Verterok> nice
[00:07] <jam> poolie: can you call back?
[00:07] <poolie> sure
[00:09] <lifeless> hi poolie
[00:09] <jfroy> Verterok: yup, works :)
[00:09] <Verterok> jfroy: yay!
[00:11] <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:12] <jfroy> Need to get that out of experimental now :p
[00:13] <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:14] <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:18] <jfroy> Verterok: that's incredibly crappy :/
[00:19] <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:20] <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:21] <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:22] <Verterok> indeed :p
[00:23] <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:25] <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:26] <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 :)
[03:08] <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:09] <markh> poolie: sure - I'll try and do that this afternoon
[03:09] <poolie> thanks
[03:11] <markh> I've been working on porting pywin32 to py3k recently - that is an interestng experience :)
[03:12] <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
[04:00] <jml> spiv: is there a config option I can use so that -dHPSS is always on?
[04:16] <spiv> jml: "alias bzr='bzr -Dhpss'" in your bashrc ;)
[04:21] <jml> incidentally, MemoryTransport.rename's behaviour varies based on dict ordering.
[04:26] <spiv> jml: that doesn't sound good.
[04:26] <jml> spiv: it doesn't feel good eiter.
[04:27] <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:28] <spiv> mwhudson: pastebin the traceback?
[04:28] <mwhudson> spiv: there is no traceback
[04:29] <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:30] <mwhudson> at least it's fixed now
[04:30] <spiv> mwhudson: I'd still like to see the traceback :)
[04:31] <mwhudson> spiv: https://pastebin.canonical.com/9805/
[04:32] <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:33] <jml> spiv: bug 276972 if you are interested.
[04:39] <spiv> jml: ta
[04:44] <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:46] <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:47] <mwhudson> spiv: i am driving several hundred km away in about 20 mins :)
[04:47] <spiv> mwhudson: http://rafb.net/p/4pgIvJ66.html
[04:48] <spiv> mwhudson: but if you go enjoy your road trip instead I'll understand :)
[04:55] <spiv> mwhudson: https://bugs.edge.launchpad.net/bzr/+bug/230902
[05:28] <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:29] <spiv> Hmm, apparently my memory is faulty.
[05:31] <lifeless> spiv: :P
[05:32] <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:35] <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:43]  * mwhudson off
[05:52] <lifeless> spiv: interesting; see, I want to delete a slot the base class has :P
[05:56] <spiv> lifeless: ah, well... tough :P
[05:58] <lifeless> :->
[06:05] <lifeless> when did I last mention hating doctest?
[06:07] <lifeless> abentley: are you up?
[06:07] <abentley> Yeah
[06:08] <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:09] <lifeless> which checks that the serializer is used and its sha output recorded
[06:10] <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:11] <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:12] <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:13] <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:14] <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:16] <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:18] <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:19] <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:20] <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:21] <lifeless> abentley: the yes, though I think perhaps 'intersecting with' rather than 'superset', but perhaps I'm being overly pedantic
[06:22] <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:23] <poolie> at least it's not scatalogical
[06:23] <abentley> Yeah, HashedInventory is more evocative.
[06:24] <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:25] <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:26] <lifeless> abentley: (which are the parameters I mentioned in my mail from tuesday)
[06:26] <lifeless> s/use/us/
[06:28] <poolie> presumably both of them should be renamed if we think 'CHK' is cryptic
[06:29] <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:30] <spiv> I didn't find "CHK" too cryptic, but perhaps I'm just odd :)
[06:31] <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:34] <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:35] <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:36] <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:42] <abentley> lifeless: Yes, there is a balance to be struck.
[06:44] <lifeless> abentley: I just an image of a set of scales being hit repeatedly
[06:44] <lifeless> abentley: :)
[06:53] <markh> poolie: uploaded
[06:56] <poolie> thanks!
[06:57] <poolie> markh, could you send me a brief roadmap of what you'd like to do next on tortoise?
[06:57] <markh> sure
[07:03] <vila> hi all
[07:17] <vila> spiv: any reason you didn't re-vote on 'regression on OSX in TestReadMergeableFromUrl.test_smart_server_connection_reset' ?
[07:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <spiv> vila: it'd be nice to have a test that reliably fails (on all platforms) without this fix.
[07:33] <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:34] <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:35] <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:36] <jdrake> bzr is *sweet*
[07:36] <vila> sure, and socket.error may not be relevant either for http
[07:36] <spiv> Right.
[07:37] <spiv> I certainly wouldn't object to doing that :)
[07:38] <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:39] <jdrake> haha
[07:39] <jdrake> I might actually be able to use bzr to do more than just code with school coming up.
[07:40] <spiv> vila: bb:tweak formally given
[07:42] <vila> spiv: ok, thanks
[07:43] <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:44] <robsta> lifeless: jelmer hinted you might know a workaround for phantom references messing up "diff"
[07:44] <robsta> (bug#275861)
[07:45] <robsta> oh "ghost revisions" it's called
[07:46] <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:47] <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:48] <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:49] <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:50] <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:51] <robsta> speed is not the problem, the problem is that diff bails on me
[07:51] <lifeless> robsta: right, did I mention orthogonal?
[07:54] <robsta> lifeless: http://pastebin.com/m36aec880
[07:55]  * 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:56] <robsta> http://pastebin.com/m6f95d2bf
[07:57] <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:58] <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:59] <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
[08:00] <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)
 either that or some variation where you give the list of revisions you want to show
 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:03] <robsta> lifeless: "No new revisions to push." can i force this somehow?
[08:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:14] <poolie> do you know what's the main thing in the profile of --line?
[08:15] <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:16] <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:17] <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:18] <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:19] <vila> What I'd want to do is make it more streamed: walk the needed graph, filter revisions, display formatted text
[09:09] <luks> jelmer: are you around?
[09:21] <poolie> hi luks
[09:22] <luks> hi
[09:41] <luks> ok, now I'm really confused
[09:41] <luks> I thought `bzr dpush` from bzr-svn was supposed to rebase my branch
[09:42] <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
[10:00] <bob2> hm, so long since I modified a chatscript
[10:00] <bob2> oops
[10:07] <No`> hi bazaarians
[10:15] <jelmer> luks, somewhat
[10:15] <jelmer> luks, it will rebase your *local* branch
[10:15] <jelmer> if necessary
[10:16] <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:17] <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:20] <robsta> lifeless: should i attach the repo tarball to the bug (1.7M bz2) =
[10:20] <lifeless> robsta: sure
[10:21] <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:23] <robsta> #277043, fyi
[10:26] <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:27] <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:30] <robsta> n/p
[10:54] <jml> is there a revisionspec for branch parent?
[11:03] <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:04] <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:22] <lifeless> jml: :parent ?
[11:22] <jml> lifeless: nope. maybe my bzr is too old.
[11:23] <lifeless> oh thats a location alias
[11:23] <lifeless> meh
[12:14] <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)
[15:43] <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:46] <g0nzal0> http://dpaste.com/81931/
[15:58] <Verterok> g0nzal0: what is the name of the directory were easy_install "installed"?
[15:59] <g0nzal0> /usr/lib/python2.5/site-packages/bzr_svn-0.4.13-py2.5-linux-i686.egg
[15:59] <Verterok> ohh eggs
[16:00] <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:01] <Verterok> g0nzal0: np
[16:05] <g0nzal0> Verterok: :(
[16:05] <g0nzal0> http://dpaste.com/81935/
[16:12] <Verterok> let's see
[16:12] <Verterok> g0nzal0: run it with -Derror
[16:13] <Verterok> g0nzal0: i.e: bzr -Derror plugins
[16:18] <g0nzal0> Verterok: I had bzr installed with easy_install too
[16:19] <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:20] <g0nzal0> didn't know about it, it rocks! :)
[16:23] <vila> la la la, Russian roulette, pqm blocked
[16:23] <g0nzal0> I'm branching django-survey with bzr-branch!!!
[16:27] <jam> vila: *why* does it always happen from *your* submissions?
[16:28] <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:29] <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:30] <jam> vila: I just pinged mthaddon, and he said he got it going again
[16:30] <vila> thanks to him and you, again...
[16:31] <vila> Most probably, bugs are a big family and some vendetta is going on each time I fix a nasty one :)
[18:05] <_MMA_> Command to upload *all* unknown files in a existing branch?
[18:05] <_MMA_> bzr add ?
[18:06] <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:07] <beuno> yeap
[18:07] <beuno> bzr add
[18:08] <_MMA_> Oh. I thought it had to have something after "add". Like "bzr add all" or something. :)
[18:08] <_MMA_> cool
[18:11] <beuno> nope nope, it's the default
[18:11] <beuno> you have to add something if you *just* want to add one file
[18:12] <_MMA_> I see.
[18:49] <idx_foo> Installing bzr for eclipse, I have bzr, jdk, eclipse and xml plugin of correct versions.
[18:50] <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:51] <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:52] <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:53] <Verterok> idx_foo: rename bzr_xmloutput_0_8_0 to xmloutput :)
[18:54] <idx_foo> nope
[18:54] <idx_foo> Now the error doesn't happen in the pref window
[18:55] <idx_foo> But still can't share the project
[18:55] <idx_foo> I'll be back later
[18:56] <Verterok> idx_foo_away: when you come back, please check the log at <workspace>/.metadata/.log
[19:01] <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:02] <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:03] <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:04] <Stavros> ôçáô óååìó ôï çáùå òïñêåä, ôçáíêó
[19:04] <Stavros> ñåñ
[19:04] <Stavros> damn
[19:04] <Stavros> that seems to have worked, thanks
[19:07] <nihilocrat> hello
[19:09] <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:10] <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:11] <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:12] <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:13] <beuno> I see, the remote branch is the one with .OTHER.OTHER...?
[19:13] <nihilocrat> yeah
[19:14] <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:15] <nihilocrat> hmm
[19:15] <beuno> so, I haven't needed to look into it too much
[19:15] <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:16] <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:17] <Verterok> idx_foo: go to preferences -> team -> bazaar
[19:17] <idx_foo> yes
[19:18] <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:19] <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:20] <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:21] <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:22] <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:23] <Verterok> idx_foo: I think all debian based distros lacks an updated eclipse
[19:23] <Verterok> idx_foo: np :)
[19:24] <Verterok> idx_foo: there is Bug #123064
[19:25] <idx_foo> Any other good IDEs with bazaar integrated?
[19:25] <idx_foo> For Linux that is
[19:28] <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:29] <Verterok> idx_foo: also, PIDA for a list of all: http://bazaar-vcs.org/IDEIntegration
[19:29] <Verterok> beuno: hey there!
[19:30] <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:31]  * 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:33] <Verterok> he left :p
[19:39] <rockstar> jam, want to do TWiB in an hour?
[20:19] <jelmer> rockstar: hi
[20:20] <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:21] <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:22] <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:23] <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:24] <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:25] <jelmer> persia: for FTP and HTTP a flag like the one you describe could indeed help
[20:26] <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:27] <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:28] <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:29] <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:30] <persia> Also, what's the mailing list?
[20:30] <jelmer> bazaar@lists.canonical.com
[20:32] <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:36] <beuno> persia, speed is the main focus ATM I believe
[20:36] <beuno> so this sounds entirely appropriate
[20:37] <persia> OK, then adding my use case is probably worthwhile.  I'll send an email during my next pause.  Thanks :)
[20:37] <beuno> :)
[20:46] <pygi> hi hi
[20:49] <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:53] <beuno> AmanicA, merge proposal!
[20:53] <beuno> yes  :)
[20:53] <AmanicA> beuno, like in branch or like in bundle?
[20:54] <beuno> AmanicA, branch
[20:55] <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:56] <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] <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:57] <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:58] <AmanicA> ah, then I can tust leave it like is, and if the reviewer have a bettername, we can update it :P
[20:59] <AmanicA> s/tust/just/
[20:59] <beuno> sure
[21:00] <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:01] <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:02] <beuno> and I'd love to have more people test it
[21:02] <AmanicA> I'm thinking uploading bzr branches could get hecktick
[21:03] <AmanicA> bzr i.e. bzr.dev.my_fix etc.
[21:03] <beuno> yeap yeap
[21:03] <beuno> it's going to be very usable very soon
[21:04] <AmanicA> can hardly wait:)
[21:05] <blueyed> jelmer: about bzr-shell-hooks: do you think it makes sense to chdir() to the branch root, before executing the command?
[21:08] <jelmer> blueyed: sure
[21:09] <blueyed> jelmer: how do I get the directory from branch? (or the other way around: can you just add it? :))
[21:16] <jelmer> blueyed: branch.base IIRC
[21:17] <uws> wow, bzr is quite fast!
[21:17] <uws> committing 2000 new files takes only a few seconds
[21:18] <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:20] <blueyed> jelmer: yes. and then, I should probably not use urlutils._posix_local_path_from_url directly?!
[21:21] <rockstar> jelmer, hi back (sorry, went out to eat some lunch)
[21:22] <jelmer> blueyed: branch.transport.local_abspath(".") should work I think
[21:23] <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:25] <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:29] <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:31] <jelmer> blueyed: try branch.bzrdir.root_transport instead
[21:33] <AmanicA> sheweet, I made the loggerhead top five contributers list!   (without even trying)
[21:37] <rocky> jelmer: now you just need to convert trac to use it ;)
[21:39] <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:41] <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:47] <jelmer> rocky: it can already do that through trac-bzr and bzr-svn ;-)
[21:47] <rocky> boo =P
[21:48] <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:49] <blueyed> ..but cannot put that in the config (as list)
[21:57] <blueyed> jelmer: it would work with shell=True for subprocess.call
[22:14] <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:15] <jam> around line 344
[22:15] <jam> is "recommended_page_size()"
[22:15] <jam> we currently set it to 64kB
[22:16] <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:17] <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:18] <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:19] <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:21] <persia> lifeless: That's all?  Which version of bzr?  (I use 1.3)
[22:22] <lifeless> persia: should be any for this use case
[22:23] <persia> lifeless: OK.  Thanks.  I'll try jam's hack anyway, and see if it helps me.  Maybe I'm just confused.
[22:24] <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:25] <jam> You might set the one in "bzrlib/transport/remote.py" though
[22:26] <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:27] <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:28] <jelmer> yeah, the number of roundtrips with hpss is really bad :-(
[22:29] <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:33] <jelmer> at least this explains why bzr-svn is faster than bzr+ssh for me
[22:33] <jelmer> bbl
[22:36] <lifeless> persia: don't worry about it; we are testing on high latency stuff at the moment
[22:37] <uws> sftp:// feels faster than bzr+ssh:// for me even
[22:37] <uws> (no numbers to confirm/deny this)
[22:38] <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:42] <lifeless> uws: could well be
[22:51] <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:52] <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:53] <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:54] <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:55] <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:56] <jam> I take it back, I reviewed it, but it hasn't landed yet
[22:59] <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@"
[23:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:08] <jam> which is certainly the recommended way to do it
[23:08] <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:09]  * 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:23] <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:24] <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:28] <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:29] <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:30] <beuno> I didn't know
[23:40] <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:41] <jam> does the code in the plugin still work?
[23:56] <lifeless> jam: the plugin code needs some adjustments, to use bzr's index logic etc
[23:57] <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:59] <lifeless> back shortly, fooding