| lockheartmac | hello | 00:04 |
|---|---|---|
| lockheartmac | im new to bzr, but can it be used for Flash or Photoshop files? | 00:04 |
| rjek | Sure, but the diffs won't be very readable. :) | 00:05 |
| rjek | I don't know how efficent it is at storing binary files, but it certainly can. | 00:05 |
| lockheartmac | cool | 00:06 |
| lockheartmac | do you know of something else that might be better for tose types of files? | 00:06 |
| lifeless | bzr should be fine | 00:07 |
| lifeless | I have heard of people versioning iso's in bzr | 00:07 |
| lockheartmac | nice! im gonna give it a try, thanks! | 00:07 |
| rjek | lifeless: Why are they versioning ISOs rather than the files and the scripts to create the ISO from them? | 00:10 |
| lifeless | rjek: congenital insanity ? | 00:11 |
| rjek | I see. :) | 00:11 |
| Kinnison | night all | 00:21 |
| lifeless | spiv: ping | 00:36 |
| spiv | lifeless: pong | 00:38 |
| lifeless | can I slip that patch in with the single large test ? | 00:42 |
| spiv | lifeless: yes | 00:43 |
| spiv | lifeless: sorry, I should have said so explicitly | 00:44 |
| spiv | lifeless: I'd love to find a nice way to deal with that situation, because I have tests that would be improved too :) | 00:44 |
| edencane | Hi. Ive updated a library file in the tree; did a bzr remove <oldfile>; bzr add <newfile>; then bzr commit; | 00:48 |
| edencane | then bzr push; | 00:48 |
| edencane | THe files are not in the tree though? Why would that be? | 00:48 |
| edencane | anyone able to help? | 00:52 |
| bob2 | what method are you using to push? | 00:53 |
| bob2 | not all of them update the remote working tree | 00:53 |
| edencane | just bzr push | 00:53 |
| bob2 | e.g. bzr+ssh, sftp, ... | 00:54 |
| edencane | sftp | 00:54 |
| bob2 | I don't think sftp updates the tree (which seems reasonable, since it's not executing bzr on the other end) | 00:54 |
| bob2 | does "bzr up" in the remote tree make the files appear? | 00:54 |
| edencane | how would I do that? bzr up sftp:<foo>? | 00:56 |
| bob2 | "ssh remotehost '(cd /to/remote/dir ; bzr up)" | 00:56 |
| AfC | edencane: I think he meant ssh'ing to the machine in question and running `bzr update` in the branch | 00:56 |
| edencane | hmmm | 00:57 |
| AfC | (because I know that's what I do in the one external branch that I keep an up to date tree in) | 00:57 |
| edencane | maybe... bzr push seems to push the changes Ive made to local files | 00:58 |
| lifeless | edencane: if you want the files to be visible there you need to run bzr at the far end; but other bzr users can pull from it already | 00:58 |
| lifeless | edencane: .bzr is a database | 00:58 |
| edencane | this is a replacement of a library... | 00:59 |
| AfC | eg the difference between http://research.operationaldynamics.com/bzr/java-gnome/mainline/ and say http://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/missing/ | 00:59 |
| edencane | normally if I do a bzr add <file> or bzr remove <file> do I need to do bzr commit on <file> as well? | 01:01 |
| AfC | lifeless: sometimes I wonder if push shouldn't have updated when run locally. Of course, that's the confusing badness that most other systems force their users to deal with, but we sure do run into people not understanding the "remote push usually can't update remote working tree" thing. | 01:01 |
| bob2 | edencane: yes, or just a commit of the whole tree | 01:02 |
| AfC | ... but maybe it would have taught people the difference between push and update (and the fact that push locally _does_ an update). Perhaps we should make that more explicit locally? | 01:02 |
| edencane | bob2: ohkay, I didnt do the bzr commit on both the old file (removed) and new file (added) | 01:03 |
| spiv | edencane: until you "bzr commit", no changes you've made will be recorded in the branch. "bzr add <file>" is a change, just like editing a versioned file. | 01:03 |
| edencane | Ahhhh | 01:03 |
| edencane | Okay... | 01:03 |
| edencane | Thanks ever so much... | 01:03 |
| bob2 | edencane: if it's a new version of some file, you could just copy it over and commit the modification of the file rather than its' replacement | 01:04 |
| AfC | edencane: [you threw us off when you said you'd committed] | 01:04 |
| AfC | edencane: [as commit without args commits all pending changes] | 01:04 |
| AfC | bob2: indeed. Far better to do that | 01:05 |
| edencane | hmmmm I see your point, but in many cases I have a lot of crud files kicking around that I dont want to commit... | 01:07 |
| TFKyle | edencane: if they're new files that you don't want to add just don't add them, for modifications to existing files possibly have a look at bzr shelve (part of bzrtools) | 01:08 |
| edencane | bob2: it wasnt a new version, it was a replacement library like: somelib1.3.3 replaced with someLib2.0.7 | 01:08 |
| TFKyle | (well, shelve/unshelve) | 01:08 |
| lifeless | AfC: thats a good idea; just a printline would help | 01:09 |
| edencane | AfC: yea, I always commit specific files, sorry | 01:10 |
| AfC | lifeless: you want a bug for that, or is that a "just do it" | 01:13 |
| AfC | edencane: which would have been find had you committed all the files relevant to the change you were trying to capture | 01:13 |
| poolie | hm something odd is happening trying to get the .sig file... | 01:21 |
| lifeless | AfC: mail to the list | 01:21 |
| poolie | hm. the incorrect mime types make firefox pretty unhappy.... | 01:24 |
| igc | ping spiv | 01:37 |
| igc | spiv: on a typical project, what sort of performance gain do you expect using the smart server vs plain http? | 01:38 |
| lifeless | igc: you'll need to benchmark it ;) | 01:38 |
| lifeless | igc: its probably marginally faster than sftp for packs today | 01:39 |
| igc | my benchmarks overnight are showing plain http is now quite quick with packs | 01:39 |
| igc | whereas bzr+ssh is a fair bit slower | 01:39 |
| lifeless | good | 01:39 |
| lifeless | ;) | 01:39 |
| igc | lifeless: downloading 33 projects on a LAN over plain http is 708 seconds | 01:40 |
| AfC | bzr:// use the same packs (and realizes the same efficiencies) as http://, right? | 01:40 |
| igc | lifeless: using bzr+ssh, it's taking 1908 secs | 01:41 |
| igc | so I'm wondering whether I'm doing something wrong :-) | 01:41 |
| TFKyle | igc: what version of openssh are you using? | 01:41 |
| lifeless | AfC: not quite; but due to bugs not design | 01:41 |
| lifeless | TFKyle: its not that | 01:42 |
| TFKyle | (probably not that, but you never know) | 01:42 |
| igc | whatever version comes with gutsy :-) | 01:42 |
| lifeless | igc: you are using bzr.dev on this end and 1.0 on the other | 01:42 |
| lifeless | igc: or something similar | 01:42 |
| igc | yep | 01:42 |
| AfC | lifeless: oh. That's discouraging | 01:42 |
| lifeless | igc: so you are not getting a streaming pull, you are falling back to VFS, and the bzr VFS does not do readv expansion so the index reads will be bisecting in 200 byte ranges, rather than 64K ones | 01:43 |
| igc | the remote machine is running bzr 1.0 on Leopard | 01:43 |
| lifeless | AfC: they are being fixed right now | 01:43 |
| igc | the local machine is bzr.dev on gutsy | 01:43 |
| lifeless | igc: yes, this fits my prediction | 01:44 |
| lifeless | igc: for benchmarks always have the server be a >= bzr than the client | 01:44 |
| AfC | lifeless: sweet [We invested considerable effort circa 0.91 to get the server running and to get everyone converted to bzr:// URLs, so I was hoping that all that hadn't been deprecated] | 01:44 |
| lifeless | AfC: heck no | 01:44 |
| lifeless | AfC: just teething problems between VFS changes and smart server changes not lining up quite right | 01:44 |
| igc | lifeless: fwiw, we whip hg now on plain http serving: 708 secs vs 2200 secs | 01:45 |
| lifeless | what latency are you benching with? | 01:45 |
| lifeless | ratchet it up to 150ms or so | 01:45 |
| AfC | lifeless: (I came across this question more as an offshoot when I was researching what would be involved in switching people to packs) | 01:45 |
| igc | it's a 100Mb LAN | 01:45 |
| AfC | igc: that's excellent news. | 01:46 |
| igc | lifeless: I'm looking at netem today | 01:46 |
| AfC | igc: (we should publish that somewhere) | 01:46 |
| lifeless | AfC: if you have a server version that is >= your bzr client version you'll get a streaming pull which should be faster than packs; or at least close to | 01:47 |
| lifeless | we're working on making it faster | 01:47 |
| igc | AfC: it's nice to know. The smart server comparison is more meaningful though I suspect | 01:47 |
| AfC | igc: yeah | 01:47 |
| AfC | igc: they did after all go there from the very beginning. | 01:47 |
| AfC | lifeless: [both are 1.0 atm] | 01:48 |
| igc | and configuring Hg is more painful than I expected so my main focus is our benchmarks, not theirs | 01:48 |
| AfC | sure | 01:49 |
| AfC | "configuring Hg is more painful" ... that's the sort of critique that while subjective nevertheless resonates widely. I would encourage you to put that into a blog post with some details. | 01:50 |
| AfC | (which people like me could link to) | 01:50 |
| igc | AfC: coming from someone that works at Canonical, people expect me to say that | 01:50 |
| igc | AfC: better if you blog that I think :-) | 01:51 |
| AfC | igc: I didn't do the tests, I didn't have the experience. You did. You're the one that found hg cumbersome to use. I'd be interesting in hearing why (and why you think bzr takes a better approach to $whatever). You are more than eminently qualified to report on such things | 01:52 |
| igc | AfC: in the end, I gave up trying to find out how to push over sftp with Hg, particularly initial push | 01:52 |
| AfC | And more to the point, if you guys don't blow your own horn, no one else will. | 01:52 |
| igc | so I went with scp to just get the files pushed across | 01:53 |
| * AfC laments that he has several tens of draft blog posts of this sort of critique/experience across many projects that he hasn't quite gotten around to tying together into a cohesive point yet | 01:53 | |
| igc | it really is sweet how Bazaar doesn't require anything on the server bar ssh access | 01:54 |
| AfC | Café | 01:56 |
| lifeless | igc: hg wants a smart server always unless you do speciall stuff | 01:57 |
| igc | lifeless: yeah - it's really annoying | 02:03 |
| lifeless | poolie: jam: ping? | 02:34 |
| poolie | ready when you are | 02:35 |
| jam | hi lifeless, poolie are we doing a conference call? | 02:36 |
| lifeless | conf centre? | 02:38 |
| jam | sure, dialing now | 02:38 |
| jam | waiting for the "leader" | 02:39 |
| lifeless | standing by | 02:40 |
| jam | poolie: you coming? | 02:41 |
| poolie | sure | 02:41 |
| * igc lunch | 03:07 | |
| fullermd | lifeless: How much of that streaming SS capability is making 1.1? | 03:43 |
| lifeless | fullermd: none | 04:24 |
| fullermd | Oh. Well, that makes it easy to quantify :) | 04:24 |
| abentley | jelmer: ping | 04:28 |
| abentley | Or anyone-who-groks-pygtk: ping | 04:29 |
| spiv | jamesh: I hear you know a little about pygtk ;) | 04:29 |
| jamesh | I've heard that rumour too | 04:30 |
| abentley | jamesh: I'm using a VBox to add a toolbar to a diff window, and I'm getting some strange sizing issues. | 04:30 |
| abentley | It seems like pack_start isn't honoring the expand parameter. | 04:31 |
| abentley | I do self.vbox.pack_start(scrollwin, expand=True, fill=True) | 04:32 |
| abentley | self.vbox.pack_start(merge_button, expand=False, fill=False) | 04:32 |
| abentley | And the button and the scrollwin take equal amounts of space. | 04:32 |
| jamesh | that should make scrollwin take any space above the requested minimum | 04:33 |
| jamesh | what's the vbox packed inside of? | 04:33 |
| abentley | That's what I thought, but it's not what I'm seeing. | 04:33 |
| jamesh | (i.e. what is its sizing policy?) | 04:33 |
| abentley | The vbox is in a subclass of Window. That subclass has set_default_size invoked to set it to 66% of screen width, 66% of screen height. | 04:35 |
| jamesh | is the code available somewhere? | 04:35 |
| abentley | I'll put it up. | 04:36 |
| abentley | Also strange is that the fill parameter has an effect even when expand=False. | 04:37 |
| jamesh | well, fill would generally affect only the horizontal space used by the child in a vbox | 04:37 |
| abentley | Okay, it's up at http://code.aaronbentley.com/bzr/bzrrepo/bzr-gtk-meld | 04:37 |
| abentley | Right, but the docs say it has no effect when expand=False. | 04:38 |
| jamesh | that doesn't sound correct | 04:38 |
| abentley | Or do I have it backwards? | 04:38 |
| poolie | spiv, i guess i'm not coming up today... | 04:38 |
| abentley | "The fill argument to the pack methods control whether the extra space is allocated to the objects themselves (True), or as extra padding in the box around these objects (False). It only has an effect if the expand argument is also True." | 04:39 |
| abentley | The branch I put up is bzr-gtk. | 04:41 |
| lifeless | whee that was a call | 04:41 |
| jamesh | abentley: http://developer.gnome.org/doc/GGAD/sec-containers.html <- it's a bit old, but it is a good description of box packing | 04:41 |
| jamesh | abentley: if expand=False for a child of a vbox, it won't be allocated any more height than it requested | 04:42 |
| jamesh | abentley: but the width of the vbox may be wider than what the child requested -- the fill setting comes into play here | 04:43 |
| abentley | jamesh: That's what I would expect. | 04:43 |
| abentley | jamesh: What I am seeing is that the button is always full-width. | 04:44 |
| jamesh | found it: | 04:44 |
| jamesh | self.vbox = gtk.VBox(True) | 04:44 |
| spiv | poolie: not a problem | 04:44 |
| jamesh | you've created a homogeneous vbox, where each child is allocated equal size | 04:45 |
| jamesh | change that to self.vbox = gtk.VBox() and you should be set | 04:45 |
| abentley | Thanks. | 04:45 |
| abentley | I must have copied-and-pasted without realizing I was breaking myself. | 04:45 |
| abentley | I confirm that fixes it. | 04:45 |
| lifeless | this carpet install is driving me bats | 04:53 |
| abentley | My mind is sufficiently warped that I wondered whether that was a derogatory term for apt-get dist-upgrade. | 04:56 |
| abentley | Installation as carpet-bombing | 04:56 |
| lifeless | lol | 05:00 |
| lifeless | no the apartment above is being renovated | 05:00 |
| lifeless | bastards | 05:00 |
| lifeless | next week would have been fine | 05:01 |
| bob2 | for you! | 05:03 |
| spiv | lifeless: any ideas on how to test the socket connection error handling? | 05:05 |
| spiv | lifeless: the obvious thing is to just try connecting to "bzr://unknown.local/" or something. | 05:05 |
| spiv | lifeless: But I fear sufficiently badly configured systems will manage to resolve it, leading to spurious test failures... | 05:06 |
| spiv | lifeless: I suppose I coudl write Feature that checks that some impossible host name really does fail to resolve... | 05:06 |
| fullermd | It's not spurious. It points to a real problem ;) | 05:07 |
| spiv | fullermd: it's a real problem, but not the one the test is trying to catch :P | 05:07 |
| spiv | fullermd: I think probably the user in that case would be better served by a "missing feature" message telling them not to have crazy wildcard resolvers | 05:08 |
| fullermd | Well, it's not like you're often going to get random people running selftest and watching their system nail itself to the wall for 45 minutes... selftest is mostly a dev tool. | 05:08 |
| fullermd | I'd use "nonexistent.invalid" or something like that, since .invalid is spec'd to not exist. | 05:09 |
| spiv | Hmm, I think a Feature is probably right for it. | 05:10 |
| dysinger | Hey | 05:11 |
| spiv | Given that it's a property of the environment running the tests that is needed to run a particular test. | 05:11 |
| dysinger | Congrats on the 1.1 | 05:11 |
| spiv | But it's also something that doesn't make bzr itself behave incorrectly. | 05:11 |
| fullermd | Reasonable enough, I s'pose. | 05:12 |
| fullermd | Just my Long-Suffering Sysadmin hat makes me want to inflict immediate pain on people with b0rked setups :p | 05:12 |
| spiv | fullermd: thanks for the "nonexistent.invalid" suggestion. | 05:12 |
| jamesh | spiv: you could try something under example.com | 05:14 |
| spiv | jamesh: is that likely to be any better than something under .invalid? | 05:15 |
| fullermd | Well, ICANN _could_ make hosts under example.com. The .invalid TLD is specifically for nonexistence. | 05:15 |
| jamesh | fullermd: ... and so is available for local host names | 05:16 |
| spiv | http://www.rfc-editor.org/rfc/rfc2606.txt seems to suggest that .invalid is a better fit than .example or example.com | 05:16 |
| jamesh | the machines on my local network have .henstridge.invalid hostnames | 05:16 |
| lifeless | lol, rather than .local ? | 05:17 |
| jamesh | lifeless: the ones with zeroconf setup also have .local names asserted via mDNS | 05:17 |
| lifeless | I think fullermd is right | 05:19 |
| lifeless | a feature that depends on an unresolvable hostname | 05:19 |
| fullermd | Surely you can't be implying that there are people in the world who don't own their own vanity domain already? ;) | 05:19 |
| jamesh | spiv: you could also try picking a syntactically invalid domain name, I guess | 05:20 |
| jamesh | e.g. one with underscores | 05:20 |
| spiv | jamesh: I could even do both! | 05:21 |
| fullermd | An implementation could conceptually throw a different error for that... | 05:21 |
| dysinger | so does anyone have bzr-svn working on the mac ? | 05:22 |
| jamesh | spiv: http://www.rfc-editor.org/rfc/rfc2606.txt <- that's the relevant RFC | 05:22 |
| dysinger | I couldn't get it to work on leopard | 05:22 |
| spiv | jamesh: I know, I gave that link 6 minutes ago ;) | 05:22 |
| jamesh | garr | 05:23 |
| spiv | lifeless: thanks | 05:23 |
| * spiv writes the test + feature | 05:23 | |
| jamesh | hah. Microsoft has a knowledge base article stating "Make sure if you choose not to register a name that you choose a name that is unique. You can review existing names at http://www.networksolutions.com (http://www.networksolutions.com)." | 05:27 |
| jamesh | maybe you could do the same for your test, and pick a .com that is not currently registered | 05:27 |
| fullermd | Well, if we're going that way, we could just set up invalid.bazaar-vcs.org. | 05:28 |
| fullermd | (well, or not set up, depending on your semantics ;) | 05:28 |
| jamesh | then we could monitor who is running the Bazaar test suite by tracking nameserver logs | 05:29 |
| fullermd | Going to .invalid should finish in just a query to the roots, though. Elsewhere might take several steps, wasting a bit of time and a bit more load on various servers along the way. | 05:29 |
| fullermd | Oh, well, you want monitoring, then you want ${bzrlib_vesion}.invalid.b-v.o. | 05:30 |
| jamesh | or ${username}.${bzrlib_version}.invalid.b-v.o | 05:30 |
| fullermd | % bzr selftest | 05:31 |
| fullermd | Please enter your credit card number: _ | 05:31 |
| spiv | lifeless: http://rafb.net/p/svj9Hw22.html | 05:37 |
| dysinger | So this no-way-to-import-svn and no-way-to-work-on-top of svn is keeping me on Git. I sure wish there was a way to get it working on OS X Leopard. It probably works fine with Tiger (becasue SVN & svn-python doesn't come pre-installed) | 05:37 |
| spiv | lifeless: does that test + feature look ok? | 05:37 |
| spiv | lifeless: should I move the feature to bzrlib/tests/__init__.py? | 05:37 |
| spiv | fullermd: it could be "Please enter your licence key: _" ;) | 05:38 |
| keir | i want to have a make (ok, scons) rule which bakes the bzr version into a header file, so that gets baked into every binary. is there a 'best practice' way to do this with bzr? | 05:39 |
| spiv | keir: how about "bzr revision-info"? | 05:41 |
| lifeless | I think the feature is fine in place | 05:42 |
| keir | spiv, great, thanks. | 05:42 |
| bob2 | should that command be hidden? | 05:42 |
| keir | spiv, hmm; i want to also reflect if there are local changes. something like revision-info with '+local mods' | 05:43 |
| lifeless | spiv: +1 | 05:44 |
| dysinger | ok thanks for the help. Talk to you later. | 05:44 |
| spiv | lifeless: thanks! | 05:44 |
| lifeless | keir: also, consider bzr version-info | 05:44 |
| lifeless | keir: which is more comprehensive, can output C etc etc | 05:44 |
| keir | ah, cool; almost perfect | 05:45 |
| keir | --clean requires no unknown files? | 05:45 |
| === spiv changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.1 is out! woo! | http://bazaar-vcs.org/releases/src/bzr-1.1.tar.gz | ||
| keir | wow, 1.1! congrats | 05:51 |
| * spiv figures if the website announces it, the IRC topic might as well announce it too :) | 05:52 | |
| * fullermd blinks. | 05:53 | |
| fullermd | Did I miss an announcement? | 05:53 |
| spiv | fullermd: I haven't seen an email yet, but the website has been linking to it for a couple of hours now | 05:54 |
| AfC | Gentoo rev bump filed. | 06:00 |
| ubotu | New bug: #183079 in bzr "added fails when not run in tree root" [Undecided,New] https://launchpad.net/bugs/183079 | 06:01 |
| fullermd | FreeBSD port update, ditto. | 06:08 |
| poolie | thanks | 06:44 |
| poolie | i did send an announcement mail | 06:44 |
| poolie | might be held? | 06:44 |
| === jamesh_ is now known as jamesh | ||
| * igc dinner | 08:38 | |
| matkor | Hi ! How to perform such task. How to uncommit changes to one given file back to given revision ? | 09:04 |
| matkor | I during commit I commited mostly valid changes except one file, later a did a lot of commits, now I would like to revert changes introduced by that old commit but only intoruduced to one specific file ? | 09:06 |
| matkor | I short, hot to say in bzr: bzr want-now-that-file-as-it-was-than <filename> -r <revno> ? | 09:07 |
| fullermd | bzr revert -rwhatever $FILE | 09:07 |
| lifeless | spiv: ping | 09:08 |
| lifeless | a = [('call_expecting_body', | 09:08 |
| lifeless | 'Repository.get_parent_map', | 09:08 |
| lifeless | ('///quack/', '\xe0\xb6\xab'))] | 09:08 |
| lifeless | b = [('call_expecting_body', | 09:08 |
| lifeless | 'Repository.get_parent_map', | 09:09 |
| lifeless | ('quack/', '\xe0\xb6\xab'))] | 09:09 |
| lifeless | after your most recent commit to bzr.dev. | 09:09 |
| lifeless | (you reviewed myy patch with this test in it; is it sane to replace /// with '' in my test and thats all ? | 09:09 |
| matkor | fullermd: Yah. So simple ... Thank you very much. As far bzr has highest question to answer size ratio for me ;) | 09:15 |
| === brilliantnu1 is now known as brilliantnu | ||
| === brilliantnu is now known as brilliantnut | ||
| Peng | Omgyay! The bzr+http path issue really was fixed! | 09:35 |
| * Peng hugs spiv. | 09:35 | |
| Peng | Hm, now that the pack format exists, I guess it's not so useful.. | 09:45 |
| Peng | I do still have one project in dirstate though. | 09:45 |
| AfC | bzr 1.1 now in Gentoo | 09:47 |
| Peng | Hmmm. | 09:53 |
| Peng | What the heck? .bzr/smart for one branch gives a 404. | 09:55 |
| Peng | It works fine for every other one. | 09:55 |
| Peng | .htaccess issue. Apparently "RewriteEngine on" in a child .htaccess negates rewrites in parents? | 09:56 |
| Peng | Or any mod_rewrite stuff at all, I guess. | 09:57 |
| Peng | RewriteOptions inherit. Okies. | 10:03 |
| Peng | I know, it was never on-topic, but I'm afraid of #apache and wanted somewhere to think out loud. :P | 10:03 |
| spiv | lifeless: right | 10:09 |
| Peng | spiv: You rock! | 10:10 |
| spiv | Peng: it's not totally fixed yet | 10:10 |
| Peng | What's still wrong? | 10:10 |
| spiv | Peng: but the client part of it was a pretty big part. | 10:10 |
| Peng | It's fixed enough that it works for me. | 10:10 |
| spiv | Peng: http://bundlebuggy.aaronbentley.com/request/%3C20071214015112.GC14963@steerpike.home.puzzling.org%3E | 10:11 |
| spiv | Peng: yeah | 10:11 |
| spiv | Peng: that's the main thing :) | 10:11 |
| * Peng watches hundreds of POSTs scroll by during a "bzr branch". | 10:11 | |
| Peng | All the recent ones are for 680-690 bytes. | 10:13 |
| Peng | Oh, good, two 60 KB ones were thrown in. | 10:15 |
| fullermd | I can just see the paper... "bzr smart requests as a PMTU discovery tool" | 10:15 |
| spiv | Peng: yeah, the readv stuff with the smart protocol isn't particular, um, smart for some reason. | 10:16 |
| Peng | So I've noticed. | 10:16 |
| Peng | Oh, good, it finished in 8m36.343s. | 10:17 |
| Peng | Dumb http only took 1m14.493s. | 10:17 |
| spiv | Yeah, that's mainly the readv borkage I belive. | 10:17 |
| spiv | Especially now that lifeless has starting improving the remote graph stuff. | 10:18 |
| Peng | The remote graph stuff is making it better or worse? | 10:18 |
| spiv | Better. | 10:18 |
| Peng | Oh, good. | 10:19 |
| Peng | That's a client-side thing? | 10:19 |
| spiv | Both. | 10:19 |
| spiv | New smart verbs to more efficiently fetch graph info to find graph differences. | 10:20 |
| Peng | Ok. | 10:21 |
| spiv | If you have the latest bzr.dev on both ends you shouldn't get much readv borkage, I think. | 10:22 |
| spiv | (because it'll get the info it needs using other methods, rather than because readv has been fixed in bzr.dev) | 10:22 |
| Peng | I do have the latest bzr.dev on both ends. | 10:22 |
| spiv | Oh. Hmm. | 10:23 |
| Peng | And it took 450 mostly-sub-KB requests to make a branch of a smallish project of 150 revisions. | 10:23 |
| spiv | Ah well, more to do then :) | 10:23 |
| Peng | (pytz). | 10:23 |
| spiv | Peng: those requests were readv, I presume? | 10:23 |
| * spiv is just double-checking | 10:23 | |
| Peng | Using FastCGI definitely speeds it up. | 10:23 |
| Peng | spiv: I dunno. They read a few hundred bytes. | 10:24 |
| Peng | I ran locally with lots of -D options so I can probably figure it out. | 10:24 |
| spiv | -Dhpss should give you plenty of info | 10:24 |
| Peng | I used -Dhpss -Dhttp. | 10:24 |
| Peng | It appears to have recorded the full request and response headers of every request. | 10:25 |
| Peng | You want to sort through it? :D | 10:25 |
| spiv | Heh. | 10:25 |
| spiv | Just -Dhpss is probably a better bet in this case :) | 10:25 |
| Peng | Yeah. I did both because I was testing both http and bzr+http and wanted to use the same args for both of them. | 10:26 |
| * spiv nods | 10:26 | |
| === doko_ is now known as doko | ||
| * Peng wonders how much the debug data contributed to those times. | 10:31 | |
| spiv | Peng: probably a bit :) | 10:35 |
| Peng | http on a dirstate branch took 392 requests. bzr+http took 422. | 10:37 |
| spiv | Peng: what took up the bulk of the bzr+http requests? Was this a push or pull? | 10:38 |
| Peng | spiv: "bzr branch". | 10:38 |
| Peng | http://bzr.mattnordhoff.com/bzr/pytz/pytz-current/ , FWIW. | 10:38 |
| spiv | Ta | 10:38 |
| fullermd | Every time I look at the bzr+http setup, I get skeered :| | 10:39 |
| spiv | Peng: you don't seem to have the most recent bzr.dev on the server | 10:40 |
| Peng | Eeerrrr. | 10:40 |
| spiv | Peng: if you did, you'd see the number of requests drop dramatically | 10:40 |
| Peng | You know what? | 10:40 |
| Peng | bzr.dev isn't in my PYTHONPATH. | 10:40 |
| Peng | That's 1.1. | 10:40 |
| spiv | Right :) | 10:40 |
| Peng | I knew that would bite me eventually. | 10:40 |
| spiv | Peng: The " result: 0.666s 'error', "Generic bzr smart protocol error: bad request 'Repository.stream_revisions_chunked'" | 10:40 |
| spiv | " | 10:40 |
| spiv | gave it away | 10:40 |
| Peng | Humm. | 10:40 |
| spiv | That verb is in bzr.dev, but not 1.1 | 10:41 |
| Peng | How do you think I should solve this? | 10:41 |
| spiv | Apache? | 10:41 |
| Peng | Add the path to bzr.dev to sys.path? "setup.py install" bzr.dev and remember to rerun it every time I update? | 10:41 |
| spiv | Peng: you're using FastCGI, IIRC? | 10:42 |
| Peng | spiv: Yessir. | 10:42 |
| spiv | Peng: you could put some sys.path hackery in the little glue script. | 10:42 |
| Peng | That's what I was thinking. | 10:42 |
| Peng | Will do. | 10:42 |
| spiv | Or build nightly debs of bzr.dev for us ;) | 10:42 |
| === asak__ is now known as asak | ||
| fullermd | I s'pose someday I should apply some of my CFT to seeing if it's setupable... | 10:43 |
| spiv | fullermd: wait till bug 129089 is fully fixed first | 10:44 |
| ubotu | Launchpad bug 129089 in gnome-system-tools "Modified user not listed" [Low,Invalid] https://launchpad.net/bugs/129089 | 10:44 |
| spiv | Er | 10:44 |
| spiv | 124089 | 10:44 |
| spiv | Ahem, bug 124089 | 10:44 |
| ubotu | Launchpad bug 124089 in bzr "wsgi smart server chrooting does not manage additional paths" [High,In progress] https://launchpad.net/bugs/124089 | 10:44 |
| spiv | Thanks ubotu | 10:44 |
| * spiv wishes IRC bots were telepathic | 10:45 | |
| dato | just live long enough ;) | 10:45 |
| Peng | Ok, fixed. | 10:45 |
| fullermd | Well, it just seems like it would be painful to do well enough. Glancing over the doc, it's full of hardcoded paths. | 10:45 |
| Peng | spiv: How do I check if it's using bzr.dev? | 10:45 |
| fullermd | I don't think that bug would change that... | 10:46 |
| spiv | Peng: judging by my -Dhpss output, it is :) | 10:47 |
| spiv | Peng: also, | 10:47 |
| spiv | andrew@steerpike:/tmp$ time bzr -Dhpss branch bzr+http://bzr.mattnordhoff.com/bzr/pytz/pytz-current/ | 10:47 |
| spiv | Branched 151 revision(s). | 10:47 |
| spiv | real 0m39.611s | 10:47 |
| Peng | Lucky low-latency/high-speed Internet connection bastard. | 10:47 |
| spiv | I'm in .au | 10:47 |
| Peng | Wait, it took 27 seconds for me. | 10:47 |
| spiv | I don't think the latency is low :) | 10:47 |
| Peng | 27 seconds is awesome. | 10:48 |
| spiv | I think it's the new smart verbs doing what they're supposed to do :) | 10:48 |
| fullermd | Branched 151 revision(s). | 10:48 |
| fullermd | 2.262u 0.571s 0:21.20 13.3% 113+146k 0+0io 0pf+0w | 10:48 |
| fullermd | Looks like ~93ms latency from here. | 10:49 |
| Peng | Blahg, 2 or 3 of us did things at once. Now I can't mentally parse my access.log. | 10:50 |
| spiv | Heh. | 10:50 |
| dato | bzr: ERROR: Not a branch: "bzr+http://bzr.mattnordhoff.com/bzr/pytz/pytz-current/". | 10:50 |
| spiv | Peng: FWIW, I'm done hitting your branch | 10:50 |
| spiv | dato: Are you using bzr.dev? | 10:50 |
| fullermd | Of course, .bzr/ has less than a meg and a half in it. I should be able to move that much data in about 3 seconds :p | 10:50 |
| spiv | dato: I think you probably need a fix that landed earlier today. | 10:51 |
| dato | spiv: ah, I didn't pull today | 10:51 |
| spiv | fullermd: yeah, there's still a heap of unnecessary roundtrips in there | 10:51 |
| dato | spiv: btw, do you plan to make http (as opposed to bzr+http) look if there's a smart server available? | 10:51 |
| dato | or is that done already? | 10:52 |
| spiv | dato: I think that would probably be nice | 10:52 |
| spiv | dato: Although I'm a bit scared to do that until bzr+http is a little more mature. | 10:52 |
| dato | spiv: yeah, "at some point in the future" | 10:52 |
| spiv | Right. | 10:52 |
| dato | ok | 10:53 |
| fullermd | Would it be a fair bet that we couldn't really dump some of those absolute paths in the config until we could turn off VFS methods altogether in the SS? | 10:53 |
| Peng | What about making bzr+http fall back to http? | 10:53 |
| fullermd | Or maybe there's some way to get Apache to pass down paths for the chrooting? Seems like it would dig deep into FCGI messes real quick, though :| | 10:56 |
| Peng | FWIW, I put up a copy of that branch in packs at http://bzr.mattnordhoff.com/bzr/pytz/pytz-current.packs/ | 11:01 |
| Peng | Took 13.7 seconds to branch. | 11:02 |
| Peng | That is, over http. | 11:02 |
| Peng | 22 over bzr+http. | 11:02 |
| Peng | Fewer requests over http too. | 11:03 |
| spiv | Peng: yeah, there's still plenty of dumb things to fix in the smart server. | 11:04 |
| Peng | Those times count building the working tree too. | 11:06 |
| * spiv nods | 11:06 | |
| Peng | So bzr+http is a huge win for dirstate with bzr.dev, but not so much for packs. | 11:07 |
| * Peng notices that the developer of the project is using dirstate while I am using dirstate-tags. | 11:10 | |
| === mvo_ is now known as mvo | ||
| Peng | Um, did any of you poke my site from t-ipconnect.de, or do I have a bot on my hands? | 11:13 |
| fullermd | I'm a long way from anything .de... | 11:14 |
| * dato too | 11:15 | |
| spiv | Not me. | 11:15 |
| Peng | Also, the user-agent was "CFNetwork/220", some library or something. | 11:16 |
| Peng | Huh. | 11:16 |
| Peng | How can I switch a branch from dirstate-tags to dirstate? | 11:17 |
| dato | Peng: b init --dirstate foo; cd foo; b pull /path/to/dirstate-tags | 11:18 |
| spiv | Peng: http://rafb.net/p/LS6bB821.html may make bzr+http with packs faster | 11:19 |
| Peng | Hm, what would Launchpad think if I did that? | 11:19 |
| spiv | Peng: launchpad will cope just fine | 11:19 |
| Peng | Will it change the format of the mirrored branch | 11:20 |
| Peng | ? | 11:20 |
| spiv | Yep. | 11:20 |
| Peng | Ok. | 11:20 |
| fullermd | Are you sure you need to, though? | 11:21 |
| Peng | Of course I don't need to. | 11:21 |
| fullermd | I mean, they won't be able to get your tags, but the repo format is still the same and all, so... | 11:21 |
| Peng | I don't use any tags. | 11:21 |
| Peng | Upstream uses dirstate and I want to use the same format. | 11:21 |
| fullermd | And going down to branch5 means your locations.conf gets all polluted again. | 11:21 |
| Peng | It's just the remote branch. Locally I use packs. | 11:22 |
| spiv | Peng: FWIW, with that patch, time to branch pytz-current.packs with bzr+http drops to 29.7s from 38.3s. | 11:27 |
| spiv | Peng: (vs 15.2s for plain http) | 11:27 |
| * fullermd is very glad to see all the SS work lately. | 11:28 | |
| spiv | Me too! | 11:29 |
| spiv | :) | 11:29 |
| Peng | spiv: Send the patch in, then? :) | 11:30 |
| fullermd | Yeah, we'll alibi you ;) | 11:32 |
| fullermd | "No sir, he couldn't have sent anything to PQM. He was sitting with us waiting for the smart server to finish branching a pack repo, see..." | 11:32 |
| spiv | Peng: I am :) | 11:32 |
| Peng | Cool. | 11:32 |
| Peng | Well, this has been a fun and bandwidth-wasting night. :) | 11:37 |
| spiv | Peng: thanks for the feedback! | 11:37 |
| dato | Peng: oh, I thought you were in Europe? | 11:38 |
| Peng | dato: No, I'm just a bat. | 11:38 |
| fullermd | If you can hear this, you're a bat: | 11:39 |
| === jamesh_ is now known as jamesh | ||
| poolie | night... | 11:50 |
| === asac_ is now known as asac | ||
| lifeless | spiv: is the client path change compatible with older servers? | 12:02 |
| ubotu | New bug: #183156 in bzr "bzr branch uses too much RAM when not using a shared repository" [Undecided,New] https://launchpad.net/bugs/183156 | 12:25 |
| fullermd | Well, I've pushed over bzr+ssh to a 1.0 server once or twice since I pulled down the change... | 12:36 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| === mvo__ is now known as mvo | ||
| beuno | anyone know where I can get a bzr 1.0 .deb for feisty? | 14:48 |
| beuno | http://rafb.net/p/yPNFTT74.html | 14:57 |
| beuno | hmmmm, I'm having a recurring problem with a packs repository, anyone know why this might be happening: http://rafb.net/p/yPNFTT74.html | 14:57 |
| luks | https://launchpad.net/~bzr/+archive | 14:59 |
| beuno | luks, thanks! (that should be added on the /Downloads page, shouldn't it? | 15:00 |
| luks | I don't know, for some reason everybody keeps talking how unofficial PPA is, but it's the only place with actually updated packages | 15:01 |
| beuno | alright, let's take this to the mailing list then | 15:02 |
| mdz_ | I need to create some diagrams to explain how a set of branches are arranged. Can anyone offer advice regarding suitable tools? | 15:04 |
| Kinnison | inkscape? | 15:05 |
| beuno | mdz_, related branches? bzr-gtk has a neat tool, "visualize" | 15:05 |
| Kinnison | inkscape can do 'attachment' lines | 15:05 |
| Kinnison | otherwise I'd suggest something like visio | 15:05 |
| Kinnison | I think OO's draw thingy can do flowchart type stuff too | 15:06 |
| mdz_ | these happen to be branches I haven't created yet, so I was thinking diagramming tools, but I suppose I could create them and try "visualize" | 15:06 |
| mdz_ | what does the output look like? | 15:06 |
| Kinnison | of visualise? | 15:07 |
| mdz_ | yes | 15:07 |
| === mdz_ is now known as mdz | ||
| luks | I think bzrtools has something to produce a graphviz sources? | 15:07 |
| Kinnison | http://users.pepperfish.net/dsilvers/vis-example.png | 15:08 |
| mdz | thanks | 15:08 |
| mdz | I think bzr visualize would do what I want | 15:08 |
| mdz | I can just set up some dummy branches and do it that way | 15:08 |
| mdz | thanks | 15:09 |
| Kinnison | no problem | 15:09 |
| beuno | mdz, the branches have to be related, make sure you explicitly branch from each other and merge back into the parent so you get that kind of output | 15:09 |
| beuno | (eg. don't "cp" the repositories) | 15:09 |
| * Kinnison ponders screenshotting the bit of aranha's history where unrelated branches are merged together :-) | 15:09 | |
| mdz | beuno: will do, thanks | 15:10 |
| jdahlin | How can I set the default branch bzr push will use if I don't provide a branch argument? | 15:10 |
| Kinnison | jdahlin: pardon? | 15:10 |
| mtaylor | hey guys... in cmd_commit(), there's a bit near the end where it calls tree.commit() | 15:10 |
| beuno | jdahlin, you can do an empty push with --remember | 15:10 |
| mtaylor | but I can't seem to find the definition of the commit method that takes a callback object as a param | 15:10 |
| jdahlin | beuno, excellent, thanks! | 15:11 |
| beuno | :D | 15:11 |
| mdz | will bzr visualize show tags? | 15:11 |
| jelmer | mdz: it will show them once you've selected a revision | 15:12 |
| jelmer | mdz: it doesn't put them in the tree view yet | 15:12 |
| mdz | oh | 15:12 |
| jelmer | and there' | 15:13 |
| jelmer | s a menu item for going to a specific tag | 15:13 |
| rjek | Today's questions: 1) Can you export a SVG or similar from bzr vis? 2) Can bzr use HTTP PUT to push to http:// URLs? 3) Is there a C interface to bzr such that you can drive it from C or another language that can bind to C? | 15:13 |
| mdz | jelmer: would be great to see them in the tree view, but I can fake it for my purposes | 15:13 |
| beuno | rjek, you *can* use http to push AFAIK, but I know it's not recommended (not ideal way to transport that amount of data) | 15:15 |
| rjek | Why is it not ideal? | 15:16 |
| rjek | I'm beginning to get bored with having asymetrical respository access URLs. | 15:16 |
| beuno | rjek, I'm not that familiar with it, but I think it's just not what it's built for | 15:17 |
| Kinnison | it'd be fine if bzr smart server over http worked sanely | 15:17 |
| beuno | rjek, why not use sftp/ssh instead? | 15:17 |
| rjek | beuno: Because they don't allow for public access to a subset of my branches. | 15:17 |
| beuno | rjek, and how does http solve that? | 15:18 |
| * rjek idly wonders for a moment if HTTP PUT supports byte ranges. | 15:18 | |
| rjek | beuno: Err, it trivially provides unauthenticated access to a subset of my branches for reading. | 15:18 |
| rjek | Where sftp and ssh cannot possibly | 15:18 |
| mtaylor | rjek: yeah - but you can push using ssh to a location that people can HTTP get from to branch | 15:19 |
| rjek | mtaylor: That's what I'm doing at the moment. | 15:19 |
| rjek | (well, read via HTTP, write via sftp) | 15:19 |
| beuno | rjek, well, anonymous read-only sftp could work, couldn't it? | 15:19 |
| rjek | beuno: Not that I know of, given sftp is based on top of ssh. | 15:20 |
| fullermd | Well, of course it _could_. But it's not trivial. | 15:20 |
| beuno | and plain old ftp? | 15:20 |
| beuno | you can give read/write access to different users trivially | 15:21 |
| rjek | That'd involve me wanting to use ftp. :) | 15:21 |
| * fullermd takes FTP out back behind the woodshed. | 15:21 | |
| mtaylor | fullermd: do you happen to know what the status is of adding a commit hook to inject or modify commit messages? | 15:21 |
| rjek | I suppose the issue will be solved when the smart server works. | 15:21 |
| mtaylor | fullermd: I see a TODO in the source... | 15:21 |
| fullermd | Not really, though I don't recall anybody mentioning working on or thinking heavily about it. | 15:21 |
| mtaylor | ok... so if I did some hacking on it, I wouldn't be stepping on anyone's toes that you know of? | 15:22 |
| fullermd | Wouldn't expect so. | 15:23 |
| === mw is now known as mw|brb | ||
| jdahlin | Is there support for something like svn:externals in bzr? | 15:34 |
| Peng | Not yet. | 15:34 |
| jdahlin | When is it planned to be included? | 15:35 |
| Peng | In the fyooture. | 15:35 |
| Peng | I dunno. | 15:36 |
| === mw|brb is now known as mw | ||
| mw | when was 1.1 released? i don't see the announcement on the mialing list | 15:53 |
| jdahlin | today, it seems | 15:53 |
| mw | yeah | 15:53 |
| mw | maybe mail's just taking a while to come through | 15:54 |
| mw | it wouldn't be the first time :) | 15:54 |
| Peng | Yeah, I've seen it on the list. | 16:05 |
| Peng | The announce list, at least. | 16:05 |
| === mez is now known as Mez | ||
| ubotu | New bug: #183244 in bzr "push aftp crash, socket.error: (10054," [Undecided,New] https://launchpad.net/bugs/183244 | 17:10 |
| vagrantc | is there a way to add the --append-revisions-only flag to a branch after it's been created ? | 17:35 |
| vagrantc | and is there a way to set it globally ? | 17:35 |
| vagrantc | i tried adding "append_revisions_only = True" to ~/.bazaar/bazaar.conf, but that didn't seem to work | 17:36 |
| dato | for the former, add it to foo/.bzr/branch/branch.cof | 17:36 |
| dato | branch.conf | 17:36 |
| vagrantc | dato: is there a way to add it to a remote branch using bzr itself? or do i need shell access to do so? | 17:38 |
| fullermd | There's no way to do it via bzr, no. | 17:46 |
| vagrantc | gah. | 17:46 |
| fullermd | You don't necessarily need shell access; you can just copy down the file, edit it, and copy back up, using sftp or however you're pushing. | 17:46 |
| vagrantc | pusshing using bzr+ssh | 17:46 |
| fullermd | Well, so you probably have sftp and scp available. | 17:47 |
| * vagrantc is trying to work with branches on launchpad | 17:48 | |
| fullermd | Launchpad supports sftp. | 17:49 |
| Peng | In Soviet Launchpad, branches work with you. | 17:49 |
| Peng | I'm sorry. | 17:49 |
| vagrantc | supports it, but do i have any idea where any of the branches paths are? | 17:49 |
| fullermd | Well, if you're pushing to them, I should hope so :) | 17:50 |
| vagrantc | well, it wasn't clear to me that the http/bzr+ssh/sftp URLs were basically the same paths | 17:50 |
| fullermd | AFAIK, the sftp and bzr+ssh paths are exactly the same, just with the different protocol specifier. | 17:51 |
| === abentle1 is now known as abentley | ||
| vagrantc | thanks for help regarding append_revisions_only | 18:34 |
| vagrantc | so there's no global way to make this the default for a given user? | 18:34 |
| hendrixski | :-( I'm having some trouble pulling from an svn repository... I have bzr-svn installed... and I've tried a few things in the ~/.bazaar/subversion.conf file... though I'm not sure it's the right thing | 18:43 |
| hendrixski | It keeps saying that it's not a valid subversion branching scheme... I'm totally lost | 18:44 |
| hendrixski | oh... heh, I just deleted the damn file and it seems to have worked | 18:54 |
| === brilliantnu1 is now known as brilliantnut | ||
| abentley | vagrantc: Sounds like a bug to me. I certainly intended it to work in bazaar.conf and locations.conf | 19:05 |
| vagrantc | abentley: i'll test it a little more just to make sure, then. i'm using 1.0-1~bpo40+1 from backports.org on debian etch | 19:06 |
| abentley | Make sure you're using a branch format that supports it. | 19:07 |
| vagrantc | ah. | 19:07 |
| abentley | dirstate-tags and later support it. | 19:07 |
| abentley | dirstate and knit do not. | 19:07 |
| vagrantc | cat .bzr/branch-format | 19:08 |
| vagrantc | Bazaar-NG meta directory, format 1 | 19:08 |
| vagrantc | ? | 19:08 |
| vagrantc | bzr info seems to think it's dirstate-tags | 19:08 |
| dato | cat .bzr/branch/format fwiw | 19:09 |
| vagrantc | cat .bzr/branch/format | 19:10 |
| vagrantc | Bazaar Branch Format 6 (bzr 0.15) | 19:10 |
| dato | right, dirstate-tags | 19:11 |
| vagrantc | it's a little hard to keep up with all the branch formats | 19:12 |
| Odd_Bloke | Wow, I'm just updating bzr.dev with packs and knits, and the difference is astounding. | 21:26 |
| Odd_Bloke | Until now I'd never really seen them side-by-side. | 21:26 |
| hendrixski_ | GGGGRRRRRRRRRRRrr | 22:14 |
| hendrixski_ | ok, this really sucks. I've been trying to get a branch from an svn repo | 22:14 |
| hendrixski_ | I've pulled off of there before | 22:15 |
| hendrixski_ | svn.asdf.org/svn/branches/release-##/directory and the error message is "not a branch: trunk/asdf" EVEN THOUGH NOWHERE in there am I trying to get anything from trunk, I'm trying to pull from tags | 22:17 |
| hendrixski_ | what the hell is going on? Where is it getting the "trunk" b.s. from???? | 22:17 |
| lifeless | hendrixski_: have you changed bzr versions on the way? | 22:18 |
| lifeless | hendrixski_: was the branch copied from trunk? | 22:18 |
| lifeless | Odd_Bloke: we do try to improve things :) | 22:19 |
| hendrixski_ | lifeless, nope... it's still version .90 | 22:20 |
| hendrixski_ | and I cleaned out ~/.bazaar/subversion.conf, so it shouldn't be looking for trunk anywhere in there | 22:21 |
| hendrixski_ | this is infuriating | 22:21 |
| Odd_Bloke | hendrixski_: Nothing funky rewrite-wise happening on the server? | 22:22 |
| radix | hendrixski_: This is just speculation, but maybe it needs to read trunk if the branch has ancestry there. Not that I know anything about bzr-svn. | 22:22 |
| hendrixski_ | Sooo. the tags on svn used to at one point have been called trunk/ and that's screwing up bzr-svn from reading it???? | 22:22 |
| Odd_Bloke | jelmer might save us. | 22:23 |
| Odd_Bloke | (SUBTLE PING) | 22:23 |
| poolie | spiv, did you fix, or have a fix in progress, for bug 82634? | 22:23 |
| ubotu | Launchpad bug 82634 in bzr "smart server gives traceback on connection errors" [High,Confirmed] https://launchpad.net/bugs/82634 | 22:23 |
| poolie | otherwise i might tackle it today | 22:23 |
| jelmer | Odd_Bloke: hi | 22:26 |
| jelmer | hendrixski_: tags was at one point named trunk? | 22:26 |
| fullermd | Man, what a great technique. You sacrifice a goat on the proper altar, and jelmer appears. | 22:26 |
| jelmer | fullermd: I know sir, I should spend less time on IRC... :-P | 22:27 |
| hendrixski_ | jelmer, I have no idea. I'm asking if I understood the problem correctly. That before it became tags, it was at one point trunk. Is that where this "trunk" thing is coming from? | 22:27 |
| jelmer | hendrixski_: Yes, I think so. | 22:28 |
| jelmer | hendrixski_: is this repository public? | 22:28 |
| hendrixski_ | jelmer, yeah.... lemme copy and paste that link | 22:29 |
| hendrixski_ | http://svn.mythtv.org/svn/branches/release-0-20-fixes/mythtv/ | 22:29 |
| hendrixski_ | somebody else did something cool with that a while back, so I want to find the release that happened closest to the date they pulled from svn, then copy over their changes, then update to the latest... and then make a .deb package... but I can't even get started for some reason | 22:31 |
| jelmer | hendrixski_: At least I can confirm it doesn't work | 22:35 |
| * hendrixski_ slams head on keyboard | 22:35 | |
| hendrixski_ | jelmer, thanks :-) | 22:35 |
| jelmer | hendrixski_: any chance you can file a bug about this? | 22:35 |
| hendrixski_ | now at least I know to try a different strategy | 22:36 |
| jelmer | I don't have time to fix this bug at the moment, but I may have time later this week | 22:36 |
| hendrixski_ | jelmer, I have the time to file one, yes | 22:36 |
| jelmer | thanks, that would be much appreciated | 22:36 |
| hendrixski_ | !bugs | 22:36 |
| ubotu | If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.launchpad.net/ubuntu - Bugs in/wishes for the bots can be filed at http://launchpad.net/ubuntu-bots | 22:36 |
| jelmer | https://bugs.launchpad.net/bzr-svn/+filebug is the link you want | 22:37 |
| hendrixski_ | lol, I was about to say, this doesn't look like an ubuntu bug :-p | 22:37 |
| hendrixski_ | jelmer, is it like this one that you're already assigned on? https://bugs.launchpad.net/bzr-svn/+bug/67010 | 22:40 |
| ubotu | Launchpad bug 67010 in bzr-svn "Branch copies from non-branches don't work" [Medium,Fix released] | 22:40 |
| hendrixski_ | or would it be best to file a new one, and submit a log message or two? | 22:41 |
| jelmer | hendrixski_: no, bug 67010 is a different issue | 22:41 |
| jelmer | hendrixski_: please file a new one, and mention the URL | 22:42 |
| hendrixski_ | will do :-) | 22:42 |
| hendrixski_ | jelmer, https://bugs.launchpad.net/bzr-svn/+bug/183361 :-) is there any other info that would help? | 22:49 |
| ubotu | Launchpad bug 183361 in bzr-svn "bzr-svn on a branches not working" [Undecided,New] | 22:49 |
| jelmer | thanks! | 22:50 |
| jelmer | looks complete | 22:50 |
| hendrixski_ | cool | 22:50 |
| hendrixski_ | well, now I have to reformat my strategy of how I'm going to do this... well, vendor drop essentially | 22:50 |
| hendrixski_ | jelmer, good luck | 22:51 |
| jelmer | thanks | 22:51 |
| igc | morning | 22:57 |
| foom | hendrixski_: perhaps branching from http://svn.mythtv.org/svn/branches/release-0-20-fixes/ instead would work? | 22:57 |
| spiv | poolie: no, I don't think I have started on 82634 | 22:57 |
| poolie | thx | 22:58 |
| spiv | poolie: I thought I remembered abentley had a patch for it that got rejected, but I can't find it now. It might have been a good starting point. | 22:59 |
| foom | hey um, i'm looking at the bazaar-vcs.org site and I can't find any links to what changed in 1.1 | 23:01 |
| poolie | http://doc.bazaar-vcs.org/bzr.1.1/en/release-notes/NEWS.html#bzr-1-1-2008-01-15 | 23:04 |
| hendrixski_ | foom, lemme try that | 23:04 |
| hendrixski_ | foom, that's ridiculous... that seems to be branching | 23:05 |
| hendrixski_ | and that's a TON of extra files | 23:06 |
| hendrixski_ | way, more of the project than I need | 23:06 |
| foom | hendrixski_: in that case, you can probably do bzr svn-branching-scheme --set http://svn.mythtv.org/svn and then in the editor, put two lines: "trunk/*" and "branches/*/*" | 23:08 |
| foom | then use your original command | 23:08 |
| * hendrixski_ tilts head | 23:08 | |
| poolie | spiv, re that patch | 23:09 |
| poolie | is it necessary to use bzr+http at all? | 23:09 |
| spiv | poolie: I don't quite understand the question. You mean instead of http? | 23:10 |
| Peng | bzr+http is great for a dirstate branch. | 23:10 |
| Peng | s/dirstate/knit/ | 23:10 |
| Peng | Not so great for a pack branch. | 23:11 |
| Peng | s/branch/repo/g | 23:11 |
| spiv | poolie: Hmm, | 23:12 |
| spiv | poolie: there are a few significant speed improvements to the smart server in bzr.dev that aren't in 1.1 | 23:13 |
| poolie | i'm asking: in what way is 1.1 broken without this fix? | 23:13 |
| hendrixski_ | foom, son of a gun. That seems to have done it | 23:14 |
| spiv | bzr+http:// URLs don't work (except in very unlikely circumstances, where the URL paths correspond directly to filesystem paths IIRC). | 23:15 |
| hendrixski_ | I'm gonna go read about this branching scheme stuff... see what I missed, but something about having to set up all that stuff doesn't seem right. | 23:15 |
| poolie | foom, i added a link to the changelog from the download page | 23:15 |
| poolie | do you think it should be anywhere else? | 23:15 |
| foom | poolie: I'd like to see a (much shorter) list of what changed on the main page with the release announcement. | 23:16 |
| spiv | poolie: so one thought that just occurred to me is that without the speed improvements in bzr.dev, perhaps there's not much practical benefit to bzr+http over http (assuming the webserver supports Range requests). | 23:16 |
| spiv | poolie: e.g. Peng last night reported that with a bzr.dev client and 1.1 on a bzr+http server that branching a knit branch was a bit slower (~10% IIRC) than plain http. | 23:17 |
| spiv | poolie: (with bzr.dev both ends, bzr+http was much faster) | 23:18 |
| spiv | poolie: (and for packs, plain http always won, but bzr.dev on the server was still a large improvement over 1.1) | 23:19 |
| jam | igc: ping, do you want to give me a call so we can make sure ssh is working? | 23:20 |
| igc | shall do in a few minutes if that's ok - family on phone currently | 23:20 |
| poolie | spiv, ok, so iiuc, this patch enables a feature that is not itself very useful yet? | 23:23 |
| poolie | therefor making a new release with this patch would not be a priority? | 23:23 |
| igc | poolie: I think x.y.1 releases ought to be kept for critical bug fixes | 23:25 |
| spiv | poolie: yeah, I think so | 23:25 |
| igc | if the feature wasn't working previously, I don't think a 1.1.1 should be released to enable it | 23:25 |
| igc | with a 4 week cycle, 1.2rc isn't far away | 23:26 |
| igc | if someone needs the fix before then, they can run on bzr.dev right | 23:26 |
| igc | ? | 23:26 |
| spiv | Right. | 23:27 |
| jam | igc: I sent you the details in an email. Try them out first, and then call me if you need to | 23:28 |
| jam | I'm going to be AFK | 23:28 |
| igc | jam:ok | 23:28 |
| lifeless | spiv: packs FTW huh ? :) | 23:31 |
| spiv | lifeless: yep! | 23:35 |
| poolie | igc, i agree, i was just trying to determine if this was | 23:37 |
| lifeless | spiv: just wait till I get time to do the next index design | 23:52 |
| spiv | lifeless: hmm, I seem to be getting worse performance with get_parent_map on an initial branch of bzr.dev, compared to using bzr.dev + recommended_page_size fix for RemoteTransport. | 23:57 |
| lifeless | spiv: bet you the remote end is 1.0 or so and the chunked stream is falling back to manual get_data_stream | 23:58 |
| spiv | lifeless: -Dtimes -Dhpss says 187s to get up to Repository.stream_revisions_chunked, vs. 72s. | 23:59 |
| spiv | lifeless: no, remote is bzr.dev | 23:59 |
| lifeless | ok | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
