jelmer | lifeless: thanks, much appreciated! | 00:00 |
---|---|---|
poolie | lifeless: could you repaste to me or point me to the numbers for gc performance on bzr.dev please? | 00:03 |
lifeless | http://paste.ubuntu.com/116333/ <- these? | 00:04 |
lifeless | poolie: or the usertest ones ian did? | 00:05 |
poolie | that looks right | 00:07 |
poolie | that's the first 1000 commits of bzr? | 00:08 |
Odd_Bloke | So I'm using looms for something at the moment. I have two looms currently, and I have a change to make which belongs between them. Can I do that in any sensible manner? | 00:08 |
lifeless | poolie: thats more | 00:08 |
lifeless | poolie: I have the first 1000 stats , one sec | 00:08 |
poolie | if this is more that's fine | 00:08 |
poolie | so it's something more than 1000 commits of bzr? all of them? | 00:09 |
lifeless | 7410 | 00:09 |
lifeless | not sure of the revno | 00:09 |
lifeless | http://paste.ubuntu.com/117486/ | 00:11 |
poolie | thanks | 00:12 |
lifeless | spiv: woo | 00:15 |
lifeless | spiv: no new failures, just that one test I discussed with John to tweak, and a 1200 line patch to eyeball :P | 00:15 |
spiv | Heh. | 00:17 |
spiv | Hmm, overdue for breakfast. | 00:17 |
lifeless | spiv: | 00:29 |
lifeless | # branch.sprout(bzrdir) is defined as using the branch format selected | 00:29 |
lifeless | # by bzrdir; format preservation is achieved by parameterising the | 00:30 |
lifeless | # bzrdir during bzrdir.sprout, which is where stacking compatibility | 00:30 |
lifeless | # checks are done. So this test tests that each implementation of | 00:30 |
lifeless | # Branch.sprout delegates appropriately to the bzrdir which the | 00:30 |
lifeless | # branch is being created in, rather than testing that the result is | 00:30 |
lifeless | # in the format that we are testing (which is what would happen if | 00:30 |
lifeless | # the branch did not delegate appropriately). | 00:30 |
spiv | lifeless: +1 | 00:31 |
mwhudson | which reminds me of something | 00:31 |
mwhudson | what's the difference between clone and sprout? | 00:31 |
lifeless | mwhudson: push and branch | 00:31 |
lifeless | mwhudson: identical copy vs new line of development | 00:31 |
lifeless | spiv: so with that explanation, it seems reasonable to me, to say, if (remote), parameterise bzrdir with [arbitrary non-source branch format] | 00:32 |
mwhudson | ok | 00:32 |
lifeless | spiv: and otherwise leave well enough alone | 00:32 |
igc | lifeless, spiv: pull is giving me grief in brisbane-core saying ... | 00:33 |
igc | "must end write group before releasing wrote lock" | 00:33 |
lifeless | igc: that means that its breaking in a @write_locked decorator | 00:34 |
igc | I've spent 30 minutes trying to find the problem but no luck so far :-( | 00:34 |
lifeless | and the code path isn't aborting the write group [generally a bug] | 00:34 |
lifeless | igc: disable that assertion, you'll see another one pop up; I thought we logged the real one or something, but perhaps not yet | 00:35 |
igc | I've looked at the changes to fetch.py, repository.py and pack_repo.py but nothing stands out to my untrained eye | 00:35 |
lifeless | spiv: ^ does my plan scan for you ? | 00:35 |
igc | lifeless: ok, I'll try that | 00:35 |
lifeless | igc: or even (if its nt a blackbox test) a pdb call inside the point that that is raise, would let you look at sys.exc_info | 00:36 |
spiv | lifeless: yes, that sounds good | 00:37 |
spiv | igc: ah yeah, as lifeless says that's typically like TooManyConcurrentRequests — there's an underlying exception being lost by the failure to abort the write group. If you can change abort_write_group or something to log the current exception first, or just reraise, that might help. | 00:39 |
lifeless | spiv: ok thats done and passing | 00:42 |
lifeless | spiv: suggstion: in those acceptance tests we have | 00:45 |
lifeless | spiv: put a ratchet now on the hpss call count | 00:45 |
* spiv nods | 00:46 | |
lifeless | spiv: bombs away, putting up a bundle - you can pull that to get the final code | 00:52 |
spiv | Ok. | 00:54 |
lifeless | spiv: I think you didn't pair with me on enough of this that you can review it with clear conscience:) | 00:55 |
lifeless | in the meantime, I'm going to eat, then look at record_stream().next().get_network_bytes conceptually for a bit | 00:57 |
lifeless | possibly by walking, I think this is a thinking time | 00:57 |
jelmer | hmm, activity reporting works on svn transports but I'm not sure it should be kept in, it makes svn look slow :-P | 01:05 |
lifeless | jelmer: why? | 01:06 |
jelmer | lifeless: average speed is < 100kb/s | 01:07 |
jelmer | I'm getting much more than that for "native" bzr | 01:08 |
jelmer | lifeless: I was kidding, it works well | 01:08 |
fullermd | Hey, maybe there'll be an entirely new and original statement made in this thread about explicitly-vs-not tracking renames... | 01:08 |
jelmer | I guess I should just do some more optimization | 01:08 |
mtaylor | hey all you wonderful people... | 01:10 |
mtaylor | anybody gonna update the bzrtools package in the PPA? | 01:10 |
mtaylor | I'd like to upgrade my bzr but I can't because it'll uninstall bzrtools, and I use those too much ... :( | 01:11 |
igc | lifeless, spiv: so disabling that exception didn't work, nor did looking at exc_info() via pdb ... | 01:11 |
igc | it does have an exception there about NotABundle but it's a red herring caused by .. | 01:11 |
igc | an attempt to read the location as a bundle early in cmd_pull | 01:12 |
igc | comment that bit out and exc_info is (None,None,None) | 01:12 |
jml | mtaylor: I don't know the answer to your question. | 01:13 |
mtaylor | jml: oh well. | 01:13 |
jml | mtaylor: but many people are in the same boat as you. perhaps the things that are in bzrtools that everyone uses should be pushed into bzr proper | 01:13 |
mtaylor | jml: yes. perhaps so. | 01:13 |
mtaylor | jml: or, a release policy that ensures bzrtools goes to the ppa at the same time as bzr - I'd be fine with either | 01:14 |
igc | lifeless, spiv: it might be something dumb on my end - let me keep looking | 01:14 |
jml | cdiff, cbranch & clean-tree are about all I use from it. | 01:14 |
jml | patch sometimes | 01:14 |
mtaylor | shelve | 01:15 |
jelmer | mtaylor: shelve is in bzr itself these days | 01:15 |
mtaylor | shelve is my savior in many case | 01:15 |
mtaylor | is it? | 01:15 |
mtaylor | cool | 01:15 |
jelmer | there was also agreement about having clean-tree in bzr itself, but nobody has stepped up yet and actually done it | 01:16 |
mtaylor | heh | 01:16 |
* jml adds a personal todo | 01:16 | |
jelmer | poolie: what are your plans for backports exactly? | 01:22 |
lifeless | igc: hi | 01:22 |
jelmer | poolie: addition to PPA or replacement? | 01:22 |
lifeless | igc: so unlock was being called and no exception had occured? | 01:23 |
lifeless | igc: what specifici test is doing this? | 01:23 |
poolie | jelmer: in addition to the PPA | 01:24 |
poolie | maybe not updated immediately when we release, and maybe not done for every release | 01:24 |
lifeless | igc: (I will run it and give it a shot) | 01:25 |
poolie | > jml: mtaylor: but many people are in the same boat as you. perhaps the things that are in bzrtools that everyone uses should be pushed into bzr proper | 01:25 |
poolie | i agree with jml | 01:25 |
poolie | if "everyone has it" as seems to be the case why keep it separate | 01:25 |
lifeless | so network delta reuse | 01:29 |
lifeless | I think a sensible approach is: | 01:29 |
lifeless | each record in a stream has a network representation | 01:30 |
lifeless | we assume that a stream recipient can use any part of a stream they have seen before, for text extraction | 01:31 |
lifeless | we assume a stream recipient *will* extract every text, to validate them | 01:31 |
lifeless | a delta which needs data not introduced as a diff by that delta just includs that in its network representation | 01:32 |
lifeless | and the stream knows what to include/not include | 01:33 |
lifeless | finally, we have graph data seperate, but offer a single api call to get the right bytes for serialisation | 01:33 |
lifeless | this lets compressors like knits and gc which don't embed graph data not have to grow graph data foo | 01:34 |
lifeless | but lets compressors like weaves which do embed graph data just use the embedded data | 01:34 |
lifeless | a minor tweak would be to say that record.get_bytes_as(record.storage_kind) if record.storage_kind not in ('chunked', 'fulltext') will return something with inline bytes for graph and raw data | 01:35 |
spiv | I'm not clear on what you mean by "a delta which needs data not introduced as a diff by that delta just includs that in its network representation" | 01:35 |
lifeless | spiv: a knit-delta-gz | 01:36 |
lifeless | spiv: with include_delta_closure == True | 01:36 |
lifeless | would just include its parents transitively up to a full text in the blob you get when you ask for the bytes | 01:37 |
spiv | Ok. | 01:37 |
lifeless | so a naive implementation which never recompresses might include the same external parent several times | 01:38 |
spiv | So the network representation for record can vary depending on the stream's include_delta_closure flag, and what has gone on the stream prior to that record. | 01:38 |
lifeless | (when we have include_delta_closure ==True) | 01:38 |
lifeless | spiv: yes | 01:38 |
spiv | Ok. | 01:38 |
lifeless | spiv: should I start a branch that aims to test this and get it working with knits and weaves? | 01:39 |
spiv | Yes please :) | 01:39 |
lifeless | ok | 01:39 |
spiv | Hmm, I need caffeine, but I'm out of beans. | 01:40 |
lifeless | I have one remaining 'this may be bad' bit - which is that we may need (given this structure) to stash the stream of inventories during a rich root upgrade | 01:40 |
lifeless | because of the 'can use anything seen before' constraint | 01:40 |
lifeless | but I think writing a temporary versioned files to disk isn't really so bad | 01:40 |
spiv | Ugh. | 01:40 |
lifeless | alternatively, we window it | 01:41 |
lifeless | we say 'anything in the last 256 items', and the generator knows that it has to track what parents are available in that window | 01:41 |
spiv | Let's just kill non-rich-root already ;) | 01:41 |
* spiv nods | 01:41 | |
lifeless | spiv: well it still applies with xml -> bbc | 01:41 |
spiv | I know :) | 01:41 |
lifeless | spiv: or even bbc-flavour-A to bbc-flavour-B | 01:41 |
spiv | And I'm sure we'll be varying the inventory format again one day, we're good at doing that ;) | 01:42 |
lifeless | because we may need random access to data from the source which is at the far end of the wire | 01:42 |
lifeless | so we need a contract where the sender can say 'you need these texts to read my shit', here they are | 01:42 |
lifeless | and the recipient can then access them all | 01:42 |
igc | lifeless: I'm about to grab some food so here's a brain dump .. | 01:43 |
igc | to trigger it ... | 01:43 |
igc | bzr-gcchk init --gc-plain-chk xx | 01:43 |
igc | cd xx | 01:43 |
lifeless | igc: there isn't a test case that dies? | 01:44 |
igc | bzr-gcchk pull ../some-pack-branch | 01:44 |
igc | bzr-gcchk is brisbane-core with the latest groupcompress plugin | 01:44 |
igc | usertest is dying | 01:44 |
igc | it gets pass 900 revisions being pulled so my theory is ... | 01:45 |
igc | it's something in groupcompress/repofmt.py, around auto-packing say | 01:45 |
lifeless | bzr.dev is the test branch ? | 01:46 |
igc | I added -Dpack and looked at bzr.log ... | 01:46 |
lifeless | igc: oh, packing is broken | 01:46 |
lifeless | igc: I was discussing this with jam | 01:46 |
igc | btw, groupcompress/repofmt.py needs to import trace and use trace.mutter for -Dpack to work :-) | 01:46 |
lifeless | probably need to disable autopack at the moment | 01:47 |
igc | bzr.log had a message about autopacking to 1000 revs but it wasn't the very last message fwiw | 01:47 |
igc | lifeless: so what's the easiest way to disable autopack? | 01:48 |
lifeless | bzrlib.repofmt.pack_repo - in there somewhere ;) | 01:48 |
igc | lifeless: np. I disable it in fastimport so I'll do the same thing I do there :-) | 01:48 |
jelmer | poolie: thanks | 01:48 |
doozer__112 | hi - apologies for what's probably a basic question... ;) But - I'm testing bazaar on XP and the tortoise? integration into the explorer shell works fine - but the only major task it doesn't seem to do is rolling back between versions of a file. I can do it from the command line if necessary, but was wondering if I'm just missing something?! | 01:48 |
* igc grabs some lunch | 01:49 | |
igc | lifeless: a quick update ... | 01:52 |
igc | I tried the same thing with bzr.dev+groupcompress using gc-plain | 01:53 |
lifeless | igc: it should break the same way, if you do multiple write groups to it; fetch from a compatible repo won't do that though | 01:53 |
igc | it falls over as well, but in a different place - insert_record_stream inside the group_compress plugin | 01:53 |
lifeless | doozer__112: I'm not sure, perhaps you could file a bug? (If its not obvious, thats a bug, if its not there, thats a bug too :P) | 01:53 |
lifeless | poolie: re: performance figures, the insertion time includes disk read IO | 02:04 |
lifeless | poolie: so its not a reliable figure yet. My observation is that its not wildly off, as each pass thrashes on the same content :P | 02:05 |
lifeless | igc: a backtrace, and the exception would be good | 02:05 |
=== RAOF_ is now known as RAOF | ||
doozer__112 | lifeless: heh, thanks, just playing with some of the other GTK based GUI's too.. | 02:16 |
lifeless | spiv: please paste your knit modem code :) | 02:17 |
victory747 | I'm having troubles with bzr-svn - I am pulling into an existing repostiory, and since upgrading to jaunty (bzr 1.11, bzr-svn 0.5.0), all my revision-ids used to have blahblah:Dir%2Ftrunk: and now they have blahblah:Dir/trunk: | 02:22 |
victory747 | So it sees the branches as having diverged | 02:22 |
lifeless | victory747: bzr-svn 0.5 is a fairly big upgrade, I suggest reading the release notes | 02:25 |
spiv | lifeless: you mean http://people.ubuntu.com/~andrew/bzr/streaming-push ? | 02:29 |
igc | lifeless: the backtrace from pulling into a gc-plain branch has just been emailed to you | 02:29 |
lifeless | spiv: just the bencode bits :) | 02:29 |
spiv | lifeless: http://rafb.net/p/rIAqn353.html | 02:30 |
victory747 | lifeless: Thanks - I think I understand now | 02:40 |
lifeless | igc: ugh, uhm | 02:42 |
lifeless | === modified file 'repofmt.py' | 02:43 |
lifeless | --- repofmt.py 2009-02-10 22:08:17 +0000 | 02:43 |
lifeless | +++ repofmt.py 2009-02-10 22:47:37 +0000 | 02:43 |
lifeless | @@ -300,6 +300,8 @@ | 02:43 |
lifeless | self._reconcile_does_inventory_gc = True | 02:43 |
lifeless | self._reconcile_fixes_text_parents = True | 02:43 |
lifeless | self._reconcile_backsup_inventory = False | 02:43 |
lifeless | + # Tell fetch what we require. | 02:43 |
lifeless | + self._fetch_order = 'topological' | 02:43 |
lifeless | 02:43 | |
lifeless | igc: ^ try that | 02:43 |
lifeless | igc: it shouldn't be needed, but if you have a broken source repo it may help | 02:43 |
lifeless | spiv: thanks | 02:45 |
kenichi | what's bzr for "up -r NN" where NN is a few revisions ago? | 02:47 |
lifeless | kenichi: currently the closest is 'bzr revert -r NN' | 02:47 |
kenichi | lifeless: that doesn't seem to work the way i'm thinking... i want revert the whole working copy to rNN. | 02:49 |
lifeless | kenichi: thats what it does | 02:50 |
lifeless | kenichi: after doing that, 'bzr diff' shows the change from NN to -1 | 02:50 |
kenichi | ugh.. sorry, i should stop working now... yes, thanks it works. | 02:51 |
poolie | igc, the display of merges in the commit template is a good idea but not a post-rc thing i think | 03:13 |
igc | poolie: ok | 03:14 |
igc | poolie: did you see markh's email re tortoise docs? | 03:14 |
igc | he'll like them in 1.12 | 03:15 |
igc | apparently, it was ready for 1.11 but hasn't been landed by anyone | 03:15 |
poolie | i landed something related to that... | 03:20 |
tro | is ther an external api reference? http://starship.python.net/crew/mwh/bzrlibapi-oe/ seems down | 03:21 |
lifeless | tro: you can run pydoctor locally | 03:22 |
lifeless | mwhudson: ^ | 03:23 |
poolie | ah i see it | 03:23 |
poolie | tro, lifeless, i'll see if we can run it on escudero | 03:23 |
tro | :) | 03:23 |
mrooney | Will upgrading my bzr in Intrepid fix this: "Selected-file commit of merges is not supported yet"? | 03:36 |
mrooney | or, is there a way to merge just one file | 03:36 |
fullermd | No, and not if you want merge tracking of it. | 03:36 |
mrooney | Crap. Okay, thanks | 03:37 |
lifeless | mrooney: you can merge just one file, but it becomes a cherrypick: 'bzr merge branch/FILENAME' | 03:37 |
fullermd | You can fling around single file changes or the like, but history-wise it's indistinguishable from doing the same thing manually. | 03:37 |
mrooney | lifeless: will merging again in the future (a full merge) work fine then? | 03:37 |
lifeless | mrooney: probably | 03:37 |
mrooney | okay that is what I need then, thanks I'll give it a try! | 03:38 |
mwhudson | tro: http://starship.python.net/crew/mwh/bzrlibapi/ ? | 03:39 |
poolie | tro: where is the -oe version linked? | 03:40 |
poolie | our main doc server is apparently too old to have a packaged version of pydoctor | 03:41 |
lifeless | spiv: ping | 03:41 |
spiv | lifeless: pong | 03:42 |
lifeless | spiv: how do you bdecode 'the first item from this long bytestream' | 03:42 |
spiv | You don't. | 03:42 |
lifeless | ah-ha! | 03:42 |
lifeless | no wonder it was seeming difficult | 03:42 |
spiv | At least, not with any bencode.py that anyone has written. | 03:42 |
poolie | you could write one fairly easily | 03:42 |
spiv | You could in principle do it. | 03:43 |
spiv | But honestly, I've written enough network stuff like that in recent times :) | 03:43 |
poolie | mwh: should i remove the link to the editable copy? | 03:43 |
mwhudson | poolie: yes, i think so | 03:44 |
lifeless | spiv: so heres my structure | 03:46 |
lifeless | I have a NetworkRecordStream calss | 03:46 |
lifeless | which takes a bytes_iterator | 03:46 |
lifeless | and has a read() method that returns a generator which reconstitutes the input stream | 03:47 |
lifeless | I want to dispatch to some code that isn't written yet | 03:48 |
lifeless | so I want the generating code to output enough data that I can dispatch on it | 03:50 |
lifeless | spiv: is _length_prefix in bzr.dev? | 04:46 |
spiv | lifeless: no, but it's trivial: | 04:49 |
spiv | def _length_prefix(bytes): return struct.pack('!L', len(bytes)) | 04:49 |
lifeless | spiv: its ok for now I'm just handwaving, we can tune Monday | 04:56 |
lifeless | poolie: spiv: I'm calling it, have a good weekend | 05:23 |
lifeless | spiv: I have good progress at pushing that down to the VF interface | 05:23 |
lifeless | spiv: we'll still have to do the ugly vis-a-vis delta closures and so on | 05:23 |
poolie | night ll | 05:25 |
spiv | lifeless: cool | 05:26 |
spiv | lifeless: the write group stuff is looking good too | 05:26 |
=== poolie changed the topic of #bzr to: Bazaar version control system | 1.12 released 13 Feb | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
spiv | poolie: woo | 05:26 |
poolie | spiv, can we have a really quick call? | 05:34 |
AfC | poolie: I thought you were aiming for the 1234567890 timestamp :) | 05:36 |
poolie | not precisely | 05:36 |
AfC | Anyway, | 05:40 |
AfC | Congratulations to the Bazaar hackers on your continued persistence. | 05:40 |
spiv | AfC: even in the face of lengthy mailing list threads? :) | 05:44 |
fullermd | If it goes on long enough, somebody will say something that hasn't been said the last 50 times the topic was discussed. | 05:47 |
fullermd | Surely. Statistics alone... | 05:47 |
fullermd | Hm. The tarball for the 1.12 release is called bzr-1.12rc1.tar.gz ? | 06:38 |
vila | hi all | 06:58 |
vila | mtaylor: Are you having a problem with bzr/bzrtools getting out of sync ? Where are you getting them from ? | 07:00 |
mtaylor | vila: from the ~bzr ppa | 07:00 |
vila | Both will be upgraded today to 1.12 if poolie finish the 1.12 release (which he should ;-) | 07:00 |
mtaylor | vila: deb http://ppa.launchpad.net/bzr/ppa/ubuntu intrepid main | 07:00 |
mtaylor | cool | 07:00 |
vila | In the mean time the bzr-beta-ppa contains both 1.12rc1 | 07:00 |
vila | mtaylor: which TZ are you in ? | 07:01 |
mtaylor | vila: Pacific US | 07:02 |
vila | mtaylor: then you should have then when you wake up tomorrow :) | 07:03 |
mtaylor | vila: yay! (although you are assuming I will go to sleep at a reasonable time...) | 07:03 |
mtaylor | vila: so I _might_ have it before I go to bed! | 07:04 |
vila | mtaylor: now *you're* assuming I can produce them before you go to sleep :) | 07:04 |
fullermd | Sleep? Didn't we do that LAST week? | 07:05 |
igc | hi vila. Thanks for the review. I'll take a look next week. | 07:14 |
vila | igc: sure, enjoy your week-end, and remember that I like the overall direction, I just disagree on details :) | 07:14 |
igc | vila. cool. today was lost fixing fast-import bugs and trying to get the groupcompress stuff working under usertest | 07:16 |
vila | igc: and don't forget that failing test in usertest :-) | 07:16 |
igc | vila: which one is that? can you email me the details please? | 07:17 |
vila | I think I did in the past, but I'll mail a fresh one anyway :) | 07:17 |
vila | log from bzrlib.plugins.usertest.tests.test_blackbox.BlackboxTests.test_usertest_strict | 07:18 |
vila | with a ~440 line output totally opaque to me :-/ | 07:18 |
vila | igc: still there in revno 137 | 07:19 |
=== kiko-afk is now known as kiko | ||
hno | Hmm.. 1.12 released but tarball not on launchpad? | 08:12 |
hno | seems 1.12rc1 got uploaded again instead.. | 08:13 |
Youssef | Hi al!!!! | 08:33 |
=== thumper_laptop is now known as thumper | ||
igc | night all - have a good weekend | 08:39 |
LarstiQ | lifeless: it seems so | 08:44 |
radix | is someone going to add bzrtools to the bzr PPA | 09:23 |
radix | so that my update-manager stops telling me I need to do a partial upgrade | 09:23 |
radix | (and so that I can upgrade bzr without removing bzrtools) | 09:24 |
=== mvo__ is now known as mvo | ||
vila | radix: as soon as poolie fix the source upload, I'd build the ppas for both bzr and bzrtools | 09:45 |
radix | vila: cool, thanks | 09:45 |
vila | I jsut can't upload it myself being currently blocked by a failing test (apparently due to some weirdness in my install as ./bzr selftest bzrlib.tests.tree_implementations.test_path_content_summary.TestPathContentSummary.test_unicode_symlink_content_summary fails for both bzr.dev and bzr-1.12 >-/ | 09:47 |
* fullermd gets a failure there too. | 09:50 | |
fullermd | FAILED (errors=1, known_failure_count=2) | 09:51 |
vila | let's kill a chicken, how can pqm left that pass ? | 09:51 |
fullermd | I don't even know what it means :p | 09:54 |
vila | fullermd: what python version are you using ? What os version ? 32/64 bits ? | 09:55 |
vila | it suceeds on hardy inside a 32 bits VM but failed on intrepid in 64 bits native | 09:55 |
fullermd | 2.5.2 FreeBSD/i386 | 09:56 |
vila | 32 bits ? | 09:56 |
fullermd | Yah. | 09:56 |
* fullermd can't imagine word size has much to do with it though... | 09:56 | |
vila | Of course... just when I thought word size couldn't have anything to do with it you confirm that 32bit works :-( | 09:56 |
fullermd | Hm? It _fails_ for me. | 09:57 |
vila | Oh ! Thanks | 09:57 |
vila | do you have a python-2.4 handy ? | 09:58 |
fullermd | It would take a lot of sit-around-and-compile. | 09:58 |
vila | fullermd: nevermind, thanks anyway | 09:59 |
vila | Urgh, python-2.5.2 disagree with itself about encondig strings between my two tests 8-( | 10:00 |
fullermd | FWIW, 1.12rc1 out of the tarball "passes" (via SKIP'ing that test) on 2.5.2 FreeBSD/amd64 | 10:01 |
vila | 2.5.2 on hardy/32bits says: '\u03b2-path', where 2.5.2 on intrepid/64bits says: '\xce\xb2-path' | 10:01 |
fullermd | Oh, wait, I've got LANG=C on that box... | 10:02 |
fullermd | Yah, it fails there too with the UTF-8 locale. | 10:02 |
=== Youssef is now known as UbuntuBoy | ||
UbuntuBoy | lol | 10:29 |
=== thekorn__ is now known as thekorn | ||
Lo-lan-do | jelmer: I don't know if you committed the fix you mentioned earlier, but a bzr update I did just now took one minute and a half instead of the previous five minutes. Thanks :-) | 10:54 |
vila | jelmer: ping | 10:59 |
UbuntuBoy | brb | 11:02 |
=== kiko is now known as kiko-afk | ||
nielsbom | (I'm a n00b), what's the correct way to stop having a simple local bzr repository? | 11:15 |
nielsbom | I just deleted the .bzr dir, that worked, but seemed wrong | 11:15 |
Kinnison | Depends what you mean | 11:15 |
nielsbom | Can you elaborate? | 11:16 |
Kinnison | Well, if all you wanted was to abandon your revision control then removing .bzr works | 11:19 |
nielsbom | Kinnison: Yeah, that answers my question :) | 11:19 |
Kinnison | If you wanted something with more complex semantics then it wasn't necessarily the right thing to have done | 11:19 |
nielsbom | Kinnison: is there a bzr command for that? | 11:19 |
nielsbom | Kinnison: or is just ok to rm .bzr? | 11:19 |
Kinnison | personally I'd use bzr export to create a non-controlled copy | 11:20 |
Kinnison | and then tar up and backup the version with the .bzr | 11:20 |
Kinnison | but that's because I don't abandon revision control, if I can help it | 11:20 |
fullermd | Me, I'd... well, not do it in the first place ;p | 11:20 |
nielsbom | Kinnison: ok clear, thanks | 11:21 |
Kinnison | sometimes I have to translate from one RCS to another, where importing the history isn't an option | 11:21 |
glade88 | what would be the equivalent of "svn update" in bzr? "bzr update" doesnt seem to do the same | 11:21 |
glade88 | ..neither "bzr upgrade" | 11:21 |
fullermd | bzr update does the same thing svn update does. That may not be quite what you want in a given case, though. | 11:21 |
Kinnison | glade88: In a checkout, bzr update ought to work | 11:21 |
fullermd | Perhaps you want 'bzr pull'. | 11:21 |
Kinnison | glade88: in a branch, you may want bzr pull | 11:21 |
Kinnison | snappish | 11:21 |
glade88 | it is a Launchpad branch. | 11:22 |
glade88 | bzr pull LP:ideatorrent ? | 11:22 |
Kinnison | simply 'bzr pull' will pull from the last location IIRC | 11:22 |
glade88 | damn this "ssh passphrase". can I make it not to ask each time? "ssh add URL" doesnt seem to work for some reason.. | 11:24 |
glade88 | URL=bzr+ssh://sayakb@bazaar.launchpad.net/~ideatorrent-developers/ideatorrent/devel/ | 11:24 |
glade88 | ^in my case | 11:24 |
* fullermd didn't know there WAS a 'ssh add'... | 11:24 | |
glade88 | fullermd: any other way to save the passphrase? | 11:24 |
Kinnison | do you mean your ssh password, or your ssh key passphrase? | 11:25 |
fullermd | bzr doesn't have anything to do with that, TTBOMK. That's all in your ssh client. | 11:25 |
fullermd | Well, it has to be passphrase where LP is concerned. | 11:25 |
fullermd | There's a ssh-agent or something like that. | 11:25 |
glade88 | its my ssh passohrase | 11:25 |
glade88 | and yes, bzr has nothing to do with that :) | 11:25 |
Kinnison | ssh-add ~/.ssh/id_rsa | 11:25 |
Kinnison | that kind of thing | 11:25 |
glade88 | since it is the same for svn | 11:25 |
glade88 | Kinnison: fullermd: thanks, bzr pull works. I'll pondermore on the passphrase thing. | 11:27 |
glade88 | cheerio | 11:27 |
* Kinnison 's suggested ssh-add commandline is what glade88 wants | 11:28 | |
fullermd | Well, only once you have the agent running. | 11:28 |
nielsbom | Just found this in the user guide (d'oh!): If you accidently put the wrong tree under version control, simply delete the .bzr directory. | 11:28 |
fullermd | And you need that ancestrally to all your terminal creations (or manual hackery in each) | 11:28 |
Kinnison | fullermd: typically, linux systems start ssh agents as part of the X session | 11:29 |
Kinnison | fullermd: As for other systems, dunno :-( | 11:29 |
* fullermd always has a hand-crafted .xinitrc, so nothing gets started he doesn't order :p | 11:30 | |
glade88 | Kinnison: w00t! yes, darn me I was using "ssh add" not "ssh-add". worksformenow (tm) . ty | 11:30 |
Kinnison | fullermd: How retro :-) | 11:30 |
fullermd | Oh, that's not retro. What's retro is how the last line starts the window manager, ctwm :p | 11:31 |
Kinnison | Oh dear | 11:32 |
* Kinnison pats fullermd gently on his clearly damaged head :-) | 11:32 | |
fullermd | But it's ctwm with a few of my own local hacks applied, of course. | 11:32 |
fullermd | Sorta like the web browsing is firefox with my local hacks, and the mail reading is mutt with my local hacks, and... | 11:32 |
* fullermd . o O ( If the world would just cater to me more, things would be so much easier... ) | 11:33 | |
fullermd | Oh dear. Somebody actually _likes_ $Log$? | 11:38 |
vila | fullermd: some even likes log --forward :-) | 11:38 |
fullermd | log --forward is almost as cool as missing --reverse! | 11:39 |
vila | Don't start *me* on --reverse :-) | 11:40 |
* fullermd reverses vila on --start. | 11:40 | |
vila | --start is good :-) | 11:40 |
fullermd | Hey, we should add stat --backward, to show the merge revs in the opposite order, too. | 11:40 |
fullermd | Then we'll cover the gamut better! | 11:41 |
Kinnison | urf | 11:43 |
UbuntuBoy | Hi guys! | 11:53 |
UbuntuBoy | I would like to know how I can launch bazaar as windows service when i execute "BZR SERVE" please | 11:54 |
=== bac_afk is now known as bac | ||
nielsbom | (noob question) is it possible to co-develop a website using 2 computers which can't be connected through SSH (or something like it) using bzr? (Something like sending a whole repositorie as a file and merging it locally, and vice versa?) | 12:21 |
Lo-lan-do | nielsbom: Yes, with merge requests sent by email. | 12:22 |
santagada | actually you can save a bundle to a file and transport it anyway you fell like it | 12:27 |
santagada | for example a pen drive | 12:28 |
Lo-lan-do | Yeah, or a floppy disk or a punched card. I sort of assumed the two computers still had access to *some* net :-) | 12:29 |
=== bac is now known as bac_afk | ||
UbuntuBoy | Lo-lan-do!? | 13:10 |
UbuntuBoy | I would like to know how I can launch bazaar as windows service when i execute "BZR SERVE" how can I do that please? | 13:11 |
santagada | Lo-lan-do: you are not paranoid enough :) | 13:11 |
Lo-lan-do | UbuntuBoy: I don't even know what a windows service is... | 13:12 |
UbuntuBoy | lol | 13:12 |
UbuntuBoy | a deamon i u want | 13:12 |
UbuntuBoy | if | 13:13 |
UbuntuBoy | sry | 13:13 |
UbuntuBoy | a deamon if u want | 13:13 |
santagada | UbuntuBoy: you know a service is not really a daemon right? | 13:13 |
UbuntuBoy | :p | 13:13 |
UbuntuBoy | yep | 13:13 |
santagada | UbuntuBoy: so I'm guessing that if there is no service plugin and windows services are not mentioned on bazaar manual it is not supported | 13:14 |
UbuntuBoy | mmmhhhhh... | 13:14 |
santagada | UbuntuBoy: but maybe there is a way to use unix tools or something from microsoft to use a daemon as a service | 13:15 |
santagada | UbuntuBoy: why not use IIS and fastcgi? | 13:16 |
UbuntuBoy | because I prefer use directly bzr:// | 13:16 |
UbuntuBoy | its more easy | 13:17 |
UbuntuBoy | it's sry | 13:18 |
santagada | UbuntuBoy: I don't really agree... but ok | 13:20 |
UbuntuBoy | :) | 13:20 |
santagada | UbuntuBoy: use the unix daemon tools or unix tools that came with your windows server to do it | 13:20 |
UbuntuBoy | unix daemon tools ? | 13:21 |
santagada | UbuntuBoy: with IIS you can easily integrate with AD also | 13:21 |
UbuntuBoy | I dunno | 13:21 |
UbuntuBoy | how | 13:21 |
santagada | UbuntuBoy: I think it is unix tools | 13:21 |
santagada | daemon tools is that thing to run .iso images | 13:21 |
santagada | UbuntuBoy: as an Ubuntu boy you probably know how to link LDAP and apache... with IIS is probably even easier to connect to AD for authentication | 13:22 |
santagada | authorization will be left as an exercise :D | 13:22 |
UbuntuBoy | hmmm | 13:22 |
UbuntuBoy | hmm... | 13:23 |
UbuntuBoy | i'm not really an ubuntyboy I took this nick becoz i didn't find anything else looooooooool | 13:23 |
UbuntuBoy | or my name | 13:24 |
=== UbuntuBoy is now known as Youssef | ||
Youssef | like this | 13:24 |
Youssef | hihi | 13:24 |
* Youssef put back his deguisment | 13:24 | |
=== Youssef is now known as UbuntuBoy | ||
santagada | Youssef was cooler | 13:25 |
UbuntuBoy | Really? | 13:25 |
UbuntuBoy | okay | 13:25 |
=== UbuntuBoy is now known as Youssef | ||
Youssef | hihi | 13:25 |
Youssef | ^^ | 13:26 |
Youssef | hmmm | 13:26 |
santagada | Youssef: windows services for unix is deprecated I think, and don't do what you want | 13:30 |
Youssef | about what? | 13:30 |
=== bac_afk is now known as bac | ||
Odd_Bloke | Youssef: I would suggest a post to the ML. | 13:32 |
Youssef | ML? | 13:33 |
Youssef | what is it? | 13:33 |
Youssef | sorry guys im a windows user I try my best to learn the linux world | 13:33 |
Youssef | it's a bit hard for me the please use full words | 13:33 |
Youssef | not only those characters lol | 13:34 |
Youssef | santagada! You said -> and don't do what you want <- what does it means? | 13:34 |
Odd_Bloke | Youssef: Mailing List. | 13:34 |
Youssef | loooooooooooooooool | 13:34 |
Youssef | okay okay | 13:34 |
Youssef | and why would you suggest me to post to the mailing list? | 13:35 |
santagada | Youssef: I don't see a way to run a daemon as a service | 13:35 |
Youssef | hhoo okay okay | 13:35 |
santagada | Youssef: because them more people can see your question | 13:35 |
santagada | Youssef: and can give you a more complete answer | 13:36 |
Youssef | ooohhh | 13:36 |
santagada | Youssef: or just because your question might become a feature request for a future version of bazaar :D | 13:36 |
Youssef | okay | 13:36 |
Youssef | mmhhhh... | 13:36 |
santagada | Good luc | 13:36 |
Youssef | interesting hehe | 13:36 |
santagada | luck | 13:36 |
Youssef | thankyou very much | 13:37 |
Youssef | guys | 13:37 |
Youssef | thanks a lot hehe | 13:37 |
Youssef | but one last question | 13:37 |
Youssef | where is the mailing list? | 13:37 |
Odd_Bloke | Youssef: https://lists.ubuntu.com/mailman/listinfo/bazaar | 13:40 |
nielsbom | Lo-lan-do: thanks! | 13:42 |
xtian_ | Can anyone tell me how to prevent bzr on windows from using plink for sftp (and get it to fall back to paramiko)? | 13:51 |
xtian_ | I can force it to fallback by renaming plink, but I need plink on my path to edit remote files in emacs. | 13:53 |
xtian_ | whoa, tumbleweeds, huh? | 13:56 |
Lo-lan-do | And crickets. | 13:57 |
Odd_Bloke | I don't know. | 13:57 |
Odd_Bloke | And I can't think who here uses bzr on Windows. | 13:57 |
xtian_ | Fair enough! I might try the mailing list. | 13:58 |
Odd_Bloke | Probably wise | 13:58 |
xtian_ | Cheers! | 13:59 |
Tak | eh, I use bzr on windows, but not with sftp | 14:03 |
xtian_ | do you just use it with launchpad? | 14:04 |
Tak | no, I use it with bzr-svn and smb | 14:08 |
verterok | xtian_: try with set BZR_SSH=paramiko | 14:20 |
xtian_ | aha! Thanks! | 14:20 |
xtian_ | Trying now. | 14:20 |
xtian_ | Is there any reference where I could find that kind of thing in future? | 14:21 |
xtian_ | That worked! Thanks heaps. | 14:22 |
verterok | xtian_: I found it the mail list archive, but I'm sure it's in the official docs | 14:22 |
verterok | xtian_: if you can't find it in the official docs, please file a bug about it | 14:23 |
xtian_ | Wilco | 14:23 |
xtian_ | Just looking now | 14:23 |
xtian_ | Gah - there it is - I was looking for the wrong keywords. I could find mention of restoring auto-detection of plink in some bug threads, but not that. | 14:24 |
xtian_ | Thanks again!. | 14:25 |
verterok | xtian_: np, glad to hlep | 14:26 |
hno | Youssef: There is a tool in the windows resource kit for creating services of arbitrarily programs not having builting service capabilities. | 14:29 |
Kinnison | What's the status of tracking cherrypicks in bzr? | 14:33 |
vila | verterok: that was short :-) | 14:43 |
verterok_ | vila: me netwokr is flaky, hopefully be back at home during the weekend :) | 14:43 |
verterok_ | /me/my | 14:44 |
=== verterok_ is now known as verterok | ||
vila | s!/me/my!s/me/my/! :-) | 14:44 |
verterok | :) | 14:45 |
Odd_Bloke | s,s!/me/my!s/me/my/! :-),s!/me/my!s/me/my/!, | 14:45 |
Odd_Bloke | :) | 14:45 |
* fullermd hopes you don't try that in csh... | 14:45 | |
yenzenz | hi | 14:51 |
Odd_Bloke | yenzenz: Hi. :) | 14:52 |
yenzenz | is this a known issue: download link to tgz of 1.12 release is broken at http://bazaar-vcs.org/Download | 14:52 |
Odd_Bloke | yenzenz: I wasn't aware of it. | 14:53 |
fullermd | Yes, it's known. | 14:53 |
yenzenz | fullermd: ok, thnaks. so just a matter of time :) | 14:54 |
nielsbom | {noob} I start a local repository on my pc (bzr init, bzr add, bzr commit), then I want to send the whole branch including all files to a colleague so he can start development on his own pc and then send patches my way. How do I export my whole dir, incl repository to him? Should I do that with bzr? Or just copy it? | 14:54 |
Lo-lan-do | You can copy the .bzr dir | 14:55 |
nielsbom | Lo-lan-do: yes, I understand that, and also copy all the files in the dir in which my files reside. | 14:56 |
Lo-lan-do | You don't *need* to copy those, since they can be regenerated from the .bzr dir. | 14:57 |
nielsbom | Even if he hasn't had the repo before? | 14:58 |
Lo-lan-do | The .bzr dir contains the full history. So he can just bzr reconfigure --tree and get the working files from that. | 14:59 |
Lo-lan-do | (Or just bzr checkout) | 14:59 |
fullermd | Well, if you send the .bzr from a dir with a checkout, you'd use revert... | 15:00 |
jelmer | vila: hi | 15:00 |
=== thunderstruck is now known as gnomefreak | ||
vila | jelmer: hi | 15:01 |
vila | jelmer: did you see my mail about 1.12 | 15:01 |
vila | jelmer: did you see my mail about 1.12 ? | 15:01 |
jelmer | vila: Yeah | 15:01 |
jelmer | vila: Strange it's failing for you :-/ Does it fail both with dirstate C extensions and without? | 15:01 |
vila | It fails *with* C extensions | 15:02 |
jelmer | does it work without? | 15:02 |
vila | let me check | 15:02 |
fullermd | It works for me without, and fails with. | 15:04 |
vila | works without | 15:04 |
vila | ... | 15:04 |
vila | gha... | 15:04 |
nielsbom | Lo-lan-do: ok, I'm starting to understand, I think (we're testing it now) | 15:05 |
Lo-lan-do | nielsbom: Maybe you could use the bzr-fast-export.py script from plugins/fastimport if you don't feel comfortable copying a .bzr dir. | 15:05 |
vila | jelmer: does it make sense to you ? | 15:06 |
jelmer | vila: Not entirely yet, but at least more | 15:06 |
nielsbom | Lo-lan-do: I'm ok with that for starters | 15:06 |
vila | jelmer: with my patch, that's the opposite, fail without extensions, works with | 15:08 |
nielsbom | Lo-lan-do: So I have a local repository, I committed to it, then I copy the .bzr directory to another directory, say example/. I then go to that dir and give the command bzr reconfigure --tree. I get the error "example is already a tree" | 15:11 |
nielsbom | Lo-lan-do: "example/ is already a tree | 15:12 |
jelmer | vila; Looks like there's an inconsistency in dirstate C extensions / Python | 15:12 |
Lo-lan-do | nielsbom: Try "bzr revert" instead. Apparently the .bzr contains info on what's supposed to be outside itself :-) | 15:12 |
vila | jelmer: yup, we need more tests parametrized on C extension availability or not | 15:15 |
jelmer | vila, i.e. one already provides unicode, the other provides ascii | 15:15 |
nielsbom | Lo-lan-do: cool, that worked thanks! | 15:17 |
vila | What are the consequences if we revert your patch ? Is bzr-svn impacted ? | 15:17 |
jelmer | vila: No, bzr-svn is not impacted, but some repositories will be impacted (as it'll break symlinks with unicode names) | 15:18 |
jelmer | vila, Do you really need to revert it though? Only newly added tests seem to fail | 15:19 |
vila | jelmer: well, I came across it just before a release... I don't think it should block it, but that's for the RM to decide... | 15:20 |
vila | jelmer: plus, it fails only under unclear circumstances... | 15:21 |
vila | jam: ping | 15:21 |
jelmer | vila: I mean, the alternative would be to just remove the tests added by my patch | 15:21 |
jam | hi vila | 15:21 |
vila | untested code is broken code :-) | 15:21 |
jelmer | vila, well, that seems to be what's breaking for you | 15:22 |
vila | jelmer: Only because I came across it via the test but I presume I can reproduce it from command line, so our users can too | 15:23 |
jelmer | vila: this was already broken from the command-line | 15:25 |
jelmer | my patch was meant to address it | 15:25 |
vila | jelmer: I understand that, don't get me wrong. | 15:25 |
vila | But it the fix seems incomplete then, even if you can't trigger it yourself (or so it seems) because, well, your setup is different | 15:26 |
vila | I can't reproduce it either under hardy/32bits inside a VM, | 15:26 |
vila | I reproduce it only under intrepid/64bits on a real host | 15:27 |
vila | Same python version: 2.5.2 | 15:27 |
vila | I fail to understand why the word size has an impact though.... | 15:27 |
jelmer | I'll see if I can reproduce on my 64bit machine | 15:28 |
jelmer | it seems strange indeed that the word size would affect the type of a field in dirstate.. | 15:28 |
fullermd | It happens for me on i386 and amd64 both. | 15:30 |
jam | fullermd: are you on BSD? | 15:32 |
* jam seems to remember that BSD has different ideas about fs_enc | 15:32 | |
fullermd | What's the thing that makes bzr spit its fs_enc out? | 15:33 |
jam | fullermd: um... python -c 'import bzrlib.osutils; print bzrlib.osutils._fs_enc" ? | 15:35 |
jelmer | the problem seems to be that the dirstate C extensions call _read_link() with a str argument | 15:36 |
jelmer | and the native Python code calls it with a unicode argument | 15:36 |
fullermd | UTF-8 | 15:36 |
jam | so the dirstate code should be using a UTF-8 string (always), which is probably incorrect on some situations | 15:36 |
fullermd | I note that (if it matters) it's the (PreviewTreePost) variant that fails. (DirStateRevisionTree) and the other options work. | 15:36 |
fullermd | Well. I assume pass == work. | 15:37 |
jelmer | jam: the dirstate code should always use unicode internally? | 15:37 |
jelmer | s/unicode/utf8 | 15:37 |
jam | jelmer: generally, yes | 15:39 |
jam | The paths stored *in* the dirstate file should all be utf-8 | 15:39 |
jam | And 90% of all processing is done via utf-8 strings | 15:39 |
jam | only when finally yielding them to upper layers do we decode it back to Unicode | 15:40 |
jelmer | and when reading from the OS encoding as _fs_enc? | 15:40 |
jam | jelmer: right | 15:41 |
LarstiQ | evening | 15:41 |
jam | hi LarstiQ | 15:41 |
jam | beuno: ping | 15:41 |
LarstiQ | hey jam | 15:41 |
jelmer | Hey LarstiQ | 15:44 |
jelmer | hi emmajane | 15:44 |
LarstiQ | hi jelmer, emmajane :) | 15:44 |
emmajane | jelmer, hello :) | 15:44 |
emmajane | LarstiQ, hello as well | 15:44 |
jelmer | emmajane, thanks for the report wrt the docs on samba.org, btw | 15:44 |
emmajane | jelmer, no problem. | 15:44 |
emmajane | jelmer, I wasn't sure if it was meant to work with local files, but not online. Or something. | 15:45 |
jelmer | emmajane, it's supposed to work, but seems to break from time to time as it's updated automatically | 15:46 |
emmajane | heh. Yeah. There's 'supposed to' and then there's 'output from scripts' :) | 15:46 |
jam | Does anyone else know if 'loggerhead' is fully plugin-ized now? | 15:47 |
LarstiQ | jam: yes, fsvo fullu | 15:48 |
jam | well, is "bundling it with the win32 installer" going to work | 15:48 |
LarstiQ | jam: I don't think it does the fancy decorating of 'bzr serve' yet | 15:48 |
jam | I guess is the question | 15:48 |
jelmer | emmajane, :-) | 15:48 |
LarstiQ | jam: ooh, goed question. | 15:48 |
jam | I think it will take a few steps | 15:48 |
jam | as it would also require extra dependencies | 15:48 |
jam | like we have to do with bzr-svn, etc. | 15:48 |
jam | I think I need to put together a spec | 15:48 |
jam | for handling setup issues with bundling plugins | 15:48 |
* LarstiQ cries as selftest slows his netbook to a crawl | 15:49 | |
jam | as I'm tired of having to edit bzr's setup.py for each plugin | 15:49 |
jelmer | vila, jam: So the problem seems to be that py_update_entry() calls _read_link() with a unicode string | 15:49 |
jelmer | vila, jam: Whereas the C extensions call it with a utf8 string | 15:49 |
jam | hmm... something odd here | 15:51 |
jam | as the C extension just passes through the "abspath" it was given | 15:51 |
jam | which is also what "py_update_entry" does | 15:51 |
jam | So I'm guessing it isn't the 'update_entry' code | 15:52 |
jam | but the _process_entry code | 15:52 |
jam | which is getting something wrong | 15:52 |
emmajane | And now for something completely different: an on-topic comment! :) | 15:57 |
emmajane | Next weekend I'm giving a bzr talk at SCaLE. I'm giving essentially the same talk as I gave before. | 15:57 |
beuno | jam, pong | 15:58 |
emmajane | The slides are at: http://www.slideshare.net/emmajane/version-control-for-mere-and-freelance-mortals-presentation if anyone has comments for add/modify/deletes. | 15:58 |
jam | beuno: on bug #328860, Martin mentions wanting to bundle loggerhead with the win32 installer | 15:58 |
ubottu | Launchpad bug 328860 in bzr "Win32 Loggerhead installer wanted" [Medium,Confirmed] https://launchpad.net/bugs/328860 | 15:58 |
jam | I was just curious if loggerhead has been fully turned into a "plugin" | 15:58 |
emmajane | The talk description is at: http://scale7x.socallinuxexpo.org/conference-info/speakers/emma-jane-hogbin (It's just an intro talk) | 15:58 |
jam | so that it would be bundled in the same fashion that bzr-svn, etc. would be | 15:59 |
beuno | jam, poolie actually did turn it into a plugin during our sprint | 16:00 |
beuno | let me find the merge proposal.. | 16:00 |
beuno | https://code.edge.launchpad.net/~loggerhead-team/loggerhead/loggerhead-plugin/+merge/3095 | 16:01 |
beuno | jam, ^ | 16:01 |
beuno | I'll merge that in today | 16:01 |
jam | beuno: well, I won't change anything for 1.12 | 16:02 |
jam | just thought I'd check where things were at | 16:02 |
jam | Does that also decorate "bzr serve" ? Or is it just "bzr loggerhead-commands"? | 16:02 |
beuno | it decorates serve | 16:02 |
beuno | which is what prompted jml's work on it | 16:02 |
=== Nicke_ is now known as Nicke | ||
jelmer | emmajane, do you have some other format than flash? gnash is not cooperating with me atm | 16:06 |
fullermd | Ooh look, a 1.12 tarball... | 16:06 |
emmajane | jelmer, is there an option to download the ODP from that page? | 16:07 |
emmajane | http://www.slideshare.net/emmajane/version-control-for-mere-and-freelance-mortals-presentation/download ? | 16:08 |
emmajane | it gives a PDF, I think. | 16:08 |
Lo-lan-do | beuno: Will you also merge the init script for daemon-like operation? | 16:08 |
jelmer | emmajane, that seems to require login :-/ | 16:09 |
Lo-lan-do | (You did ask me to pester you :-) | 16:09 |
* fullermd keeps waiting for the day flash joins java applets in the dustbin... | 16:09 | |
emmajane | jelmer, boo to slideshare. | 16:09 |
beuno | Lo-lan-do, I may put up a merge proposal for someone with a working brain to review :) | 16:09 |
jelmer | beuno, and will you remove start-loggerhead ? (-: | 16:09 |
beuno | jelmer, not until I get config working with serve-branches :/ | 16:10 |
emmajane | jelmer, http://bazaar-vcs.org/Talks?action=AttachFile&do=get&target=bzr-intro-template.odp | 16:11 |
jelmer | emmajane, thanks | 16:11 |
emmajane | jelmer, thanks for looking! :) | 16:11 |
fullermd | Things you notice when updating packages: | 16:13 |
fullermd | bzrtools 1.12.0 is 1 'larger' than bzrtools 1.11.0. Thus, it's fitting that the tarball is also 1 byte larger. | 16:13 |
jam | a single byte, that is quite intriguing | 16:13 |
Lo-lan-do | "Well, it's one louder, innit?" | 16:14 |
fullermd | But why not make each byte bigger? | 16:14 |
* fullermd nods at jam. | 16:14 | |
fullermd | I thought so. | 16:14 |
fullermd | -SIZE (bzrtools-1.11.0.tar.gz) = 69765 | 16:14 |
fullermd | +SIZE (bzrtools-1.12.0.tar.gz) = 69766 | 16:14 |
jam | well, also of interest: | 16:15 |
jam | 3.8M Feb 9 04:42 bzr-1.11.tar.gz | 16:15 |
jam | 3.9M Feb 13 09:53 bzr-1.12.tar.gz | 16:15 |
jam | 1 (100kB) bigger | 16:15 |
fullermd | Well, not really. It's 39807 bigger. | 16:16 |
Odd_Bloke | s/bigg/loud/ | 16:17 |
fullermd | Of course, if you subtract that from the curent bzrtools, you get 29959. Subtrace that from the previous bzrtools, you get 9848. | 16:19 |
Toksyuryel | Would Stackless provide any measurable speed improvements to bzr? | 16:19 |
fullermd | Sum those digits, you get 29, which starts the pattern. The next digit is the 9 again from the start of 9848. The 59 is one more than the trailing 48. | 16:19 |
fullermd | So it all works out anyway. | 16:19 |
* fullermd wanders off to smoke some more crack... | 16:20 | |
Toksyuryel | seems to have done a lot for EVE Online, am wondering if bzr can achive similar performance gains | 16:20 |
Toksyuryel | http://en.wikipedia.org/wiki/Stackless_Python | 16:21 |
Odd_Bloke | Toksyuryel: Without really knowing anything more, I would note that EVE and bzr are fairly different apps. ;) | 16:23 |
Toksyuryel | Granted, but still :) | 16:23 |
jelmer | emmajane: seems good to me :-) simple, and quick | 16:23 |
Odd_Bloke | Essentially, I doubt it, because bzr isn't multi-threaded. | 16:23 |
jfroy | Morning! | 16:23 |
jelmer | emmajane, why does "bzr tags --sort=time" need special attention? The other commands mentioned seem much more common | 16:24 |
jelmer | hi jfroy ! | 16:24 |
Toksyuryel | Is threading planned for a future development? | 16:24 |
Odd_Bloke | Toksyuryel: I don't know. | 16:24 |
emmajane | jelmer, it's just one that I use a lot myself (tagging what versions I send to the client). I talk a bit about it. | 16:24 |
Toksyuryel | Perhaps implimenting threading and moving to stackless coule provide performance improvements over the current model? | 16:25 |
Toksyuryel | *could | 16:25 |
fullermd | I would tend to doubt it, certainly in the near or mid term. | 16:25 |
jfroy | jelmer: congrats on 0.5 final | 16:25 |
emmajane | jelmer, thanks for taking a look. Much appreciated. | 16:25 |
Toksyuryel | fullermd: I see | 16:26 |
jelmer | Toksyuryel, what would the benefit of threading be exactly? | 16:27 |
Toksyuryel | potential speed increases? I'm just wondering and asking. someone's gotta actually answer the question with "yes that would make it faster" or "no it would not make it faster" :D | 16:28 |
jam | Toksyuryel: currently I think our big bottlenecks are stuff like graph walking | 16:29 |
jam | it is pretty hard to come up with efficient walking code | 16:29 |
jam | and even harder to do something that is also parrallel | 16:29 |
jam | One possible place would be text insertion, I guess | 16:29 |
Toksyuryel | like I said... I am just asking. I am not saying "this would definitely be faster and you should do it right now". | 16:29 |
jam | if you are trying to insert 100 different texts, you could probably farm a couple of those out to different threads | 16:30 |
Toksyuryel | please stop trying to spin my words to your own ends :) | 16:30 |
Toksyuryel | I understand that it's not a high priority compared to other things which need to be done | 16:30 |
santagada | jam: sorry to botther you but isn't this kind of stuff io bound? | 16:31 |
jam | santagada: some is, some is 'diff' bound | 16:31 |
fullermd | I expect the place we're most likely to pick up parallelism would be from python-level stuff, really. | 16:31 |
jam | stuff like 'annotate' could benefit | 16:31 |
fullermd | e.g., list comprehensions are inherently parallelizable. | 16:32 |
jelmer | Toksyuryel: You're talking about specifics, parallelism can be achieved through more than just threading | 16:32 |
jfroy | I was just asked by a friend if bzr had an equivalent to git add -p. He tells me it lets you commit a subset of all the changes in the branch, even from the same file. I've never done that in bzr, so I'm not sure. | 16:42 |
fullermd | You can specify files, you can use shelve to set aside bits before you commit, or... I think somebody wrote a plugin to do a darcs-style record? | 16:43 |
fullermd | (I don't know if/how well it works) | 16:43 |
Odd_Bloke | jfroy: Yeah, shelve is probably what he's looking for. | 16:45 |
Odd_Bloke | You use it put some of your changes on the 'shelf', commit, then use unshelve to pull them back off. | 16:46 |
Odd_Bloke | It has the advantage of allowing you to confirm that you haven't broken anything with the subset of changes you're committing before you commit them. | 16:46 |
jam | jfroy: it is sort of the "inverse" of add -p, in that you are taking off things you don't want to commit, rather than explicitly listing the things *to* commit | 16:46 |
jam | however, it leaves the tree in a state that you can run "make test" on | 16:46 |
jam | which is generally beneficial | 16:46 |
lbieber | Can someone tell me how to modify the 1200 second timeout limit in bzr? I'm experiencing a problem on several of our machines where they occasionally time out, not sure if it is because they are behind a firewall or not | 16:49 |
jfroy | Thank you all. | 16:50 |
LarstiQ | lbieber: do you have a .bzr.log of when that happens? | 16:50 |
lbieber | LarstiQ: one minute let me see if I can dig it up | 16:51 |
jam | lbieber: you can set bzrlib.lockdir._DEFAULT_TIMEOUT_SECONDS | 16:52 |
jam | though if you are hitting that | 16:52 |
jam | (default is 5 min) | 16:52 |
jam | I'm guessing it is something else. | 16:52 |
lbieber | LarstiQ: ummmm, where would I find .bzr.log, I'm not seeing it anywhere? | 16:52 |
jam | ~/.bzr.log | 16:53 |
jam | Or if on windows $My Documents/.bzr.log | 16:53 |
jam | bzr --version spells it out for you | 16:53 |
lbieber | ahhhh - let me fix this first and see if it helps, from the log file - 0.120 WARNING: using slower ElementTree; consider installing cElementTree and make sure it's on your PYTHONPATH | 16:57 |
Myrtti | I was wondering if http://paste.ubuntu.com/117733/ this is an error of bzr, launchpad or me? | 16:58 |
Odd_Bloke | Myrtti: That looks like a bzr problem. Is there any chance you could try with a newer version of bzr? | 16:59 |
jam | Myrtti: that is a known bug with bzr 1.6.1 when using -Dhpss | 17:00 |
jam | what bug happened that caused you to try and use -Dhpss | 17:00 |
jam | as that is the real issue | 17:00 |
jam | (that said, if you upgrade your bzr, it probably all goes away anyway) | 17:01 |
Myrtti | what I did was I removed some of the launchpad projects and tried to rebranch them | 17:02 |
Myrtti | bzr pull worked while the launchpad project working copies were there | 17:02 |
Myrtti | but now http://paste.ubuntu.com/117739/ | 17:03 |
jam | so that looks more like you don't have you ssh keys set up properly | 17:05 |
jam | it may have been working before because you didn't do "bzr launchpad-login" | 17:05 |
jam | (so we were using anonymous http access, rather than authenticated bzr+ssh access) | 17:05 |
Odd_Bloke | Myrtti: OK, so you probably did the inital lp:foo branch before running 'bzr launchpad-login'. So the branches had the http:// location stored (because currently we store the resolved URL, not just the 'lp:foo' bit). Then you ran launchpad-login, and it's now trying to use bzr+ssh. But you haven't set up SSH keys with Launchpad. | 17:06 |
Myrtti | well that's funny, because it gave me that even before I had logged in | 17:06 |
Myrtti | and now that there is a proper ssh key at launchpad, it still doesn't work. | 17:06 |
Myrtti | or that's what I think | 17:07 |
Odd_Bloke | Myrtti: What does 'ssh <username>@bazaar.launchpad.net' give you? | 17:07 |
Myrtti | Agent admitted failure to sign using the key. | 17:08 |
Myrtti | Permission denied (publickey). | 17:08 |
jpds | Ah, the seahorse-agent bug. | 17:08 |
Myrtti | <sarcasm>great</sarcasm> | 17:09 |
jpds | bug 328127 | 17:11 |
ubottu | Launchpad bug 328127 in gnome-keyring "gnome-keyring-daemon returns Agent admitted failure to sign using the key." [Low,Triaged] https://launchpad.net/bugs/328127 | 17:11 |
Myrtti | that's funny | 17:12 |
Myrtti | I'm on intrepid. | 17:12 |
Myrtti | >___< | 17:12 |
jpds | So am I, I have the same problem :/ | 17:13 |
* Myrtti checks | 17:13 | |
Myrtti | gnome-keyring: Installed: 2.24.1-0ubuntu1 | 17:14 |
jpds | Really odd. | 17:15 |
Myrtti | I'm on xfce4 though | 17:15 |
Myrtti | and I know about these things about as much as my guinea pigs know about particle physics | 17:16 |
Odd_Bloke | Myrtti: Try "SSH_AUTH_SOCK= ssh <username>@bazaar.launchpad.net". | 17:19 |
Myrtti | and presto it works | 17:19 |
Myrtti | Odd_Bloke: thanks | 17:22 |
LarstiQ | abentley: from the standup reports you're not yet in nested territory? | 17:23 |
abentley | LarstiQ: No. Hopefully next week. | 17:23 |
Odd_Bloke | Myrtti: :) | 17:25 |
Odd_Bloke | Myrtti: Adding a comment on the bug with your version details might be helpful. :) | 17:25 |
LarstiQ | abentley: k, I'm paging through a full test suite run log now, deferring most things for later, almost got myself convinced to commit/push the current status | 17:26 |
abentley | LarstiQ: Great. | 17:26 |
Myrtti | Odd_Bloke: done :-) thanks | 17:28 |
pickscrape1 | Is bzr-1.12 compatible with bzr-loom 1.4? | 17:29 |
pickscrape1 | I'm getting this when running bzr status: bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose' | 17:30 |
pickscrape1 | The backtrace refers to /usr/lib/python2.5/site-packages/bzrlib/plugins/loom/commands.py | 17:31 |
Odd_Bloke | pickscrape1: Could you pastebin a more complete error? | 17:31 |
pickscrape1 | sure | 17:31 |
pickscrape1 | Is there one for this channel, or should I just paste anywhere? | 17:31 |
LarstiQ | any pastebin works | 17:32 |
pickscrape1 | http://pastebin.ca/1336235 | 17:33 |
vila | pickscrape1: try updating your plugin I'm pretty sure it has been fixed on trunk | 17:33 |
pickscrape1 | I was running it direct from apt... I'll uninstall that and grab it manually | 17:33 |
vila | pickscrape1: yup, seeing the traceback I'm even more sure :) | 17:33 |
pickscrape1 | Is bzr-loom available in a PPA anywhere? | 17:35 |
vila | I don't think so | 17:36 |
vila | Do you get 1.12 from bzr-ppa ? | 17:36 |
vila | Did you get 1.12 from bzr-ppa ? | 17:36 |
pickscrape1 | vila: yes | 17:36 |
vila | pickscrape1: did you get bzrtools too ? | 17:36 |
pickscrape1 | I had to uninstall bzrtools because 1.11 was never uploaded to the PPA, so currently I have that installed manually | 17:37 |
vila | pickscrape1: could you try to install bzrtools from bzr-ppa ? | 17:38 |
pickscrape1 | vila: yes, I will once I've fixed etckeeper, which has also just started complaining :) | 17:38 |
vila | pickscrape1: argh, no wait, the builds aren't finished yet :-/ | 17:38 |
pickscrape1 | OK, using loom trunk has fixed the problem: thanks :) | 17:40 |
pickscrape1 | etckeeper needed BZR_COMMIT_OPTIONS="--unchanged" | 17:40 |
=== bac is now known as bac_lunch | ||
LarstiQ | woops, unlocking other_tree once too many | 18:11 |
vila | pickscrape1: bzrtools-1.12 available in bzr-ppa, can you try it ? | 18:36 |
pickscrape1 | vila: I just did, and it seems to work fine :) | 18:37 |
pickscrape1 | Thanks for your help | 18:37 |
vila | pickscrape1: great, thanks for your test :) | 18:37 |
vila | pickscrape1: which os/version/arch are you using ? | 18:37 |
pickscrape1 | vila: jaunty amd64 and intrepid x86 (tested on both) | 18:38 |
vila | pickscrape1: you're my man, two birds with one stone :) | 18:39 |
pickscrape1 | :) | 18:39 |
=== serg_ is now known as serg | ||
=== NfNitLoo` is now known as NfNitLoop | ||
jfroy|work | jelmer: I was wondering if you had some experience to share with setting up bi-directional bzr-svn syncing. | 19:23 |
=== bac_lunch is now known as bac | ||
ronny | jelmer: sup? | 19:55 |
jfroy|work | ronny: I believe he's away ATM. | 19:57 |
ronny | hmm | 19:58 |
ronny | -9 to 1234554321 ( 1234554330 19:45:30 UTC ) | 19:58 |
ronny | [20:45] MinceR | A4Tech: no u | 19:58 |
ronny | ops | 19:58 |
ronny | touchpads + broken syndaemon are hellish | 19:58 |
Lo-lan-do | jfroy|work: I'm usung bzr-svn, maybe I can be of help? | 20:02 |
jfroy|work | Lo-lan-do: ok, so here's the use case. Project A is hosted in a Subversion repository over which I have little or no control. I want to introduce a Bazaar bridge, of sort, to allow some developers to use Bazaar as their main VCS. However, it is likely some other will continue using Subversion. | 20:04 |
jfroy|work | I'm only interested in syncing one branch, the trunk, | 20:04 |
jam | vila: ping | 20:05 |
jfroy|work | That is, the Subversion trunk with a Bazaar branch, from which Bazaar-using developers would pull and push from. | 20:05 |
miracle2k | when I init-repo after I already have branches checked out, can I make them part of the repository, or they I need to re-clone? | 20:05 |
jam | miracle2k: check 'bzr reconfigure' I think it has some flags for that | 20:05 |
Lo-lan-do | jfroy|work: I think it's simpler for everyone if people just use bzr as a Subversion client then. | 20:06 |
jam | jfroy|work: I believe doing: | 20:06 |
jfroy|work | miracle2k: AFAIK you need to branch into the repo to get the branch to store its history data in it | 20:06 |
jam | bzr co svn+ssh://path/to/trunk | 20:06 |
jam | Should "just work" | 20:06 |
jam | as in, the developers can commit there, and it will update the subversion trunk | 20:06 |
Lo-lan-do | That's exactly what I'm doing, and it seems to works well. | 20:07 |
jfroy|work | Lo-lan-do: I see. So each developer would maintain their own Subversion trunk checkout. | 20:07 |
miracle2k | jam, jfroy|work: There's a reconfigure --use-shared which I'm gonna try. Thanks. | 20:07 |
jfroy|work | miracle2k: ah, good to know, didn't know that existed :) | 20:07 |
jfroy|work | jam: thanks for the tip | 20:07 |
jam | jfroy|work: it is certainly the easiest way | 20:07 |
jam | there are always others | 20:07 |
jam | you can also | 20:07 |
jam | cd my-local-trunk | 20:07 |
jam | bzr pull ../my-branch | 20:08 |
jam | and if that succeeds (branches aren't diverged) | 20:08 |
jam | it should be the same as doing "bzr push svn://...." | 20:08 |
pickscrape1 | Was a release email sent out for 1.12? | 20:35 |
jam | pickscrape1: I don't think so | 20:42 |
jam | Or it was sent, but Martin forgot to approve his email | 20:43 |
jam | Let me check | 20:43 |
pickscrape1 | I just enjoy reading the release notes is all :) | 20:43 |
jam | pickscrape1: http://doc.bazaar-vcs.org/bzr.1.12/en/release-notes/NEWS.html#bzr-1-12-1234567890-2009-02-13 | 21:08 |
jam | Or to see the on-going one: http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html | 21:08 |
pickscrape1 | jam: thanks | 21:08 |
jam | lifeless: to your earlier question, "groups" do not get +junk branches: | 21:28 |
jam | bzr: ERROR: Permission denied: "/~bzr/+junk/bzr-groupcompress": : +junk branches are only available for individuals. Please consider registering a project for collaborating on branches: https://help.launchpad.net/Projects/Registering | 21:28 |
zsquareplusc | bzr 1.12 and olive? i get errors on my ubuntu box. for example the log windows are shown, but the log itself is never shown | 21:29 |
jam | as such, I went ahead and created: https://edge.launchpad.net/bzr-groupcompress | 21:30 |
jam | since I needed to do a couple patches to the plugin | 21:31 |
=== kiko is now known as kiko-afk | ||
jelmer | ronny: hi | 22:44 |
jelmer | jfroy|work: hi | 22:44 |
jfroy|work | hey | 22:45 |
jfroy|work | As you can read in your history, my question was mostly answered, unless you have something to add to Lo-lan-do's recommendation. | 22:45 |
jelmer | jfroy|work: ah, sorry, hadn't seen that | 22:54 |
jelmer | jfroy|work: yeah, his answer seems to cover it all - just pretend the svn branch is a bzr branch and all should be well | 22:54 |
ronny | re | 22:55 |
jfroy|work | jelmer: just need to make sure the other developers who wish to use bzr understand they really need to not use a bound branch for daily work, because operations on that branch will be *slow*. | 22:56 |
jfroy|work | Your standard "train them a bit" situation, I suppose. | 22:56 |
ronny | jelmer: im at the final point of vcs unhappyness, all reasonable vcs's have at least one major pain point i dont want to be brothered with | 22:58 |
jelmer | jfroy|work: just tell them to use 0.5.1, which will be lightning-fast | 23:16 |
jelmer | ronny: yeah, it's tricky to get right :-/ a task-specific API is probably easier than a generic one like anyvc | 23:16 |
ronny | jelmer: nah, also all common vcs's have at least one fail that makes me hate them | 23:17 |
jfroy|work | jelmer: is that so? | 23:23 |
jfroy|work | (this is a worst case scenario, the svn server is still 1.4 with no plan to upgrade to 1.5 anytime soon :p ) | 23:24 |
sri | so.. | 23:41 |
sri | is there a irc hannel for paramiko? | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!