| jelmer | ChrisMorgan: this is caused by bzr probing for the smart server | 00:02 |
|---|---|---|
| ChrisMorgan | ? | 00:03 |
| ChrisMorgan | That went over my head :-) | 00:03 |
| ChrisMorgan | Just agree that it didn't work :P | 00:03 |
| spiv | ChrisMorgan: when bzr sees a http:// URL, it'll first try POST to $url/.bzr/smart with a smart server request. jelmer is saying that for some reason this probe is preventing bzr-svn from being able to do its own probe and take over. | 00:09 |
| ChrisMorgan | Shall I put that in my bug report or let you two comment it? | 00:10 |
| spiv | ChrisMorgan: (maybe the server is rejecting the bzr smart server probe with a slightly unusual HTTP response code, or something like that) | 00:10 |
| spiv | ChrisMorgan: well, please file a bug if you haven't already | 00:10 |
| spiv | ChrisMorgan: we've have a few along these lines before, no need to paste my generic explanation into the bug :) | 00:11 |
| ChrisMorgan | https://bugs.launchpad.net/bzr-svn/+bug/506196 | 00:12 |
| ubottu | Launchpad bug 506196 in bzr-svn "SVN checkout failing with empty authentication details" [Undecided,New] | 00:12 |
| spiv | ChrisMorgan: you may be able to workaround it by prefixing svn+ to the URL? | 00:13 |
| ChrisMorgan | Works. | 00:14 |
| spiv | (Or perhaps by prefixing nosmart+ come to think of it...) | 00:14 |
| ChrisMorgan | I'll leave you to comment that addition then. I've already posted mine. | 00:16 |
| ChrisMorgan | Nevertheless, it's still a bug :-) | 00:16 |
| ChrisMorgan | If it works with svn it should work with bzr :-) | 00:16 |
| ChrisMorgan | Thanks though, I really wanted all the information so I can revert to Django 1.1 if I needed to while off-line | 00:17 |
| spiv | Thanks for reporting the bug :) | 00:17 |
| ChrisMorgan | SVN is slow... now I've made it to revision 500/7768... | 00:18 |
| spiv | Yeah, it's not really designed to send you the complete history :) | 00:19 |
| ChrisMorgan | For some things I'd just want a lightweight checkout, this time I do really want it all. | 00:25 |
| lifeless | I thought someone already maintained a django bzr collection of branches | 00:28 |
| ChrisMorgan | Over 2000... | 00:31 |
| ChrisMorgan | I have heard of it... I dunno | 00:31 |
| ChrisMorgan | It's been used for benchmarks | 00:31 |
| igc | morning | 00:35 |
| poolie | ChrisMorgan: it might help if you attach the log from running | 01:39 |
| poolie | bzr co log+http:/otauhaotnhu | 01:39 |
| poolie | if you haven't already | 01:39 |
| jfroy|work | jelmer: have you had a chance to look at that new bzr-svn exception I'm hitting? | 02:04 |
| * igc lunch | 02:13 | |
| idnar | is there a better way to change a commit message than uncommit + commit? | 03:58 |
| fullermd | There's not a simpler way for simple cases (that I know of) | 04:01 |
| fullermd | Any 'better' way would be functionally equivalent in the end, anyway. | 04:01 |
| idnar | I guess I mean "easier" ;P | 04:01 |
| idnar | anyhow, no big deal | 04:01 |
| spiv | idnar: easier in what way? Open an editor with the old commit message I guess? | 04:03 |
| idnar | something like that | 04:04 |
| spiv | It'd be nice to have something like that, maybe commit --redo or something. | 04:04 |
| spiv | uncommit's useful for more than just changing the commit message, of course. | 04:04 |
| idnar | or even just avoid the risk of including uncommited changes or whatever | 04:04 |
| idnar | ironically, darcs has a command (amend-record) that lets you include additional changes but doesn't let you change the patch name | 04:05 |
| jam | poolie: I like the new "always report if it came from a user-defined source" version | 04:36 |
| poolie | thanks, sent | 04:40 |
| poolie | jam, i think our patch-landing latency is improving for developers as well as new contributors since mooloolaba | 04:40 |
| poolie | which is good | 04:40 |
| poolie | no room for complacency though | 04:40 |
| poolie | can someone help me work out where to write a test for bug 456077? | 04:50 |
| ubottu | Launchpad bug 456077 in bzr "MYSQL/BZR P3: bzr doesn't explain it's doing a slow cross-format fetch" [Medium,In progress] https://launchpad.net/bugs/456077 | 04:50 |
| poolie | or maybe it doesn't really need one | 04:50 |
| lifeless | poolie: sure | 04:50 |
| lifeless | so what do we want, a ui.note when getting a stream with a different format? | 04:51 |
| poolie | i guess in per_interrepository | 04:51 |
| poolie | yes | 04:51 |
| poolie | well, | 04:51 |
| poolie | more broadly, when the fetch is going to be noticeably slow | 04:51 |
| lifeless | so the stream interface is tested on repository, not interrepo | 04:52 |
| lifeless | and thats where the code would live, so I'd write the test there. | 04:52 |
| lifeless | as for 'when it will be slow' - there isn't a guaranteed metric for that. | 04:53 |
| poolie | and will all fetches go through the stream interface? | 04:53 |
| lifeless | so to me that means writing per-case tests. | 04:53 |
| lifeless | poolie: all the bzr <-> bzr ones do now | 04:53 |
| lifeless | it was one of the major achievements spiv and I had last year | 04:54 |
| lifeless | concretely we expect getting a revision-delta style stream to be painful on non-CHK repositories | 04:55 |
| poolie | ok, so you could possibly override InterRepository, but that's not actually expected to be done | 04:56 |
| lifeless | svn/git/hg fetches do that | 04:56 |
| lifeless | they provide specific optimisers at the moment I believe. | 04:56 |
| poolie | i wonder if a warning is useful there | 04:57 |
| lifeless | they could move to using the streaming interface at some future point. | 04:57 |
| poolie | probably not | 04:57 |
| lifeless | possibly it is, but it won't help mysql:) | 04:57 |
| lifeless | and the place to put it would be in the SVN or whatever InterRepo class anyhow, I think. | 04:57 |
| poolie | well, i was thinking of putting it in the base interrepo class | 04:58 |
| poolie | but, as you point out, that is no longer where the variation is | 04:58 |
| lifeless | fetch.py does this | 04:59 |
| lifeless | : | 04:59 |
| lifeless | source = self.from_repository._get_source( | 04:59 |
| lifeless | self.to_repository._format) | 04:59 |
| poolie | yes i see | 04:59 |
| lifeless | but its the repo _get_source that will actually know its going to be slow. | 04:59 |
| poolie | so we have a StreamSource or RemoteStreamSource locally | 05:01 |
| lifeless | specifically | 05:01 |
| lifeless | in repository.py | 05:01 |
| poolie | and i guess that can give the warning... | 05:01 |
| lifeless | _get_inventory_stream | 05:01 |
| lifeless | there is a bunch of logic that may call into | 05:01 |
| poolie | ah yes | 05:01 |
| lifeless | self._get_convertable_inventory_stream | 05:01 |
| lifeless | that *that* function is the one that does the hard work. | 05:01 |
| poolie | and that's not overridden in the remote case | 05:02 |
| lifeless | note that with fetch from bzr+ssh, this code block will execute on the smart server. | 05:02 |
| lifeless | but you can use the current 'stderr shows on the client' 'feature' to let users see the warning anyway, for now. | 05:02 |
| poolie | hm | 05:03 |
| lifeless | poolie: right, nothing is overridden in the remote case; the entire object is proxied | 05:03 |
| poolie | the comment on get_convertable... says "the source is using CHKs" but this actually seems to cover all different-format cases? | 05:07 |
| lifeless | yes | 05:07 |
| poolie | thanks very much | 05:08 |
| lifeless | np | 05:08 |
| poolie | do you recall if the deprecation warning patch landed already? | 05:08 |
| lifeless | sorry no | 05:08 |
| poolie | i guess this won't work over bzr+http or tcp until we have a way to remote ui operations | 05:12 |
| lifeless | if you were willing to bump the stream format | 05:13 |
| lifeless | you could do a step towards the progress-in-streams stuff I've speculated on | 05:13 |
| lifeless | and include a substream of type 'warning' | 05:13 |
| poolie | mm | 05:14 |
| lifeless | on push operations the RemoteStreamSink would see that and show it locally, on pull operations the StreamSink would get it from the network and show it. | 05:14 |
| poolie | alternatively we could make sure the logic runs on the client | 05:14 |
| poolie | but that seems a bit messy | 05:14 |
| lifeless | you'd have to duplicate it - cause it to run twice | 05:14 |
| poolie | right | 05:15 |
| lifeless | and you wouldn't know about config or environment on the server, so you'd be guessing | 05:15 |
| poolie | so | 05:15 |
| poolie | i guess we could make the client give this warning if it receives a stream of inventory-delta? | 05:15 |
| poolie | regardless of why the server decided to send that? | 05:15 |
| lifeless | yes | 05:15 |
| lifeless | specifically you'd want to make the Sink do that, if its not running inside a server, and RemoteSink to do it if it observes it going past. | 05:16 |
| lifeless | its a little crude, but it will do | 05:16 |
| poolie | do you think that's better? | 05:18 |
| poolie | it seems possibly better to me | 05:18 |
| lifeless | I think it will work now, as a stderr output would. It would work in tcp and http as you noted, so thats better | 05:18 |
| lifeless | OTOH deltas can be very fast chk<->chk so perhaps there will be some false positives in the future. | 05:18 |
| poolie | i'd kind of rather deal with the false positive | 05:22 |
| poolie | s | 05:22 |
| lifeless | then do that :) | 05:22 |
| lifeless | if there are are any | 05:22 |
| Peng | Isn't there some bug about dirstate when you upgrade to a rich-root format? | 05:26 |
| Peng | Should I...do something, or is it fine? | 05:26 |
| lifeless | Peng: nada | 05:26 |
| Peng | it's fine? | 05:27 |
| Peng | jelmer: ping | 05:27 |
| poolie | so, u | 05:29 |
| poolie | um | 05:29 |
| poolie | fetching from 2a into 1.14-rr does seem to use InterDifferingSerializer | 05:29 |
| poolie | which does not seem to use streams | 05:29 |
| poolie | or, not in a straightforward way | 05:30 |
| * poolie looks | 05:30 | |
| lifeless | oh, locally? | 05:32 |
| lifeless | I'd check with spiv at this point. | 05:32 |
| lifeless | spiv: ^ | 05:32 |
| lifeless | I was fairly sure that even that remnant had been dropped, but apparently not. | 05:32 |
| spiv | Hmm. | 05:32 |
| spiv | It's only used for local fetches. | 05:33 |
| spiv | See InterDifferingSerializer.is_compatible, it returns False if either side has a URL starting with file:/// | 05:33 |
| spiv | (And only if the serializers differ, etc.) | 05:34 |
| spiv | Somewhere, possibly just a mailing list thread, there's a list of things we need to fix to be able to drop IDS completely. | 05:35 |
| spiv | IIRC it was progress indication and worse speed/memory for local fetches (although the speed/memory was partially addressed?). | 05:35 |
| Peng | erk, now I can't unping him. | 05:40 |
| === arjenAU2 is now known as arjenAU | ||
| poolie | spiv actually it's false if either of them is not local | 05:51 |
| poolie | but iswym | 05:51 |
| poolie | so it seems that we need a warning in both ids and streaming | 05:51 |
| spiv | Yeah. | 05:53 |
| spiv | IDS is duplication, after all. | 05:54 |
| poolie | so | 05:54 |
| poolie | i'd like to add blackbox tests to make sure i'm actually covering the right things | 05:54 |
| lifeless | poolie: well, I'd really be inclined to write tests close to the code | 06:22 |
| lifeless | poolie: but I know we have differing opinions on this ;) | 06:22 |
| poolie | to me the risk here is not so much that my call to warning is wrong | 06:23 |
| poolie | but that the code is not reached at all | 06:23 |
| poolie | as it was not in my/our first attempt | 06:23 |
| poolie | therefore i want an integration test that checks that | 06:23 |
| poolie | spiv, i'm going to merge 2.0 back to trunk, which will carry some of your cleanup changes | 06:29 |
| poolie | just so you know | 06:29 |
| doctormo | i'm having some trouble threading bazaar when gtk is running... without the threading bzr works but locks up gtk, but with threading bzr hits Branch.open(remote_branch_url) and doesn't do anything afterwards in that thread. | 06:30 |
| doctormo | doesn't even end. | 06:30 |
| spiv | poolie: sure | 06:30 |
| spiv | poolie: I think you'll find that the cmd_annotate change from 2.0 can be discarded, but that the test that is added ought to be kept. | 06:30 |
| poolie | oh ok | 06:30 |
| poolie | that conflicted | 06:30 |
| poolie | why should it be discarded? | 06:31 |
| spiv | The command_cleanup branch included the cmd_annotate fix, but using add_cleanup rather than try/finally. | 06:31 |
| poolie | it looks like an improvement, trunk still does it without cleanups | 06:31 |
| spiv | The change in trunk was the try/finally for the tree lock IIRC. | 06:31 |
| poolie | but we want to end up with it using cleanups in trunk, don't we? | 06:31 |
| spiv | poolie: right; I mean discard the 2.0 version and keep it as it is in trunk :) | 06:32 |
| spiv | doctormo: hmm | 06:32 |
| spiv | doctormo: I doubt most of bzrlib is threadsafe | 06:33 |
| doctormo | spiv: AWOS: don't use threads it won't work? | 06:33 |
| spiv | doctormo: so your gtk program can use threads, but you should take care to only call bzrlib from a single thread. | 06:33 |
| poolie | oh i see | 06:34 |
| doctormo | spiv: OK, I think I may be able to wrangle the mental image, I think it's changing the ui outside the thread. | 06:34 |
| lifeless | spiv: our own server is multithreaded | 06:35 |
| spiv | lifeless: yeah | 06:35 |
| lifeless | doctormo: bzrlib should be pretty safe as long as you only use a given object from the same thread. | 06:35 |
| lifeless | doctormo: so you can use two threads, or N, but don't pass a (say) Branch opened from one thread to another thread. | 06:36 |
| spiv | lifeless: but we don't share objects between threads... | 06:36 |
| spiv | lifeless: it's simpler just to say "don't use multiple threads" :P | 06:36 |
| spiv | lifeless: but you're right. | 06:36 |
| lifeless | spiv: yes, I'm trying to rephrase what you said in a slightly less restrictive way ;) | 06:36 |
| doctormo | lifeless: Don't use threads unless you know how to control leaks. | 06:37 |
| lifeless | doctormo: uh, I think thats a very different statement ;) | 06:37 |
| lifeless | for all that it may be wise | 06:37 |
| Peng | lifeless: I can't land things in bzr-loom. | 06:39 |
| lifeless | Peng: aren't you in ~bzr yet? | 06:39 |
| Peng | lifeless: No. | 06:39 |
| Peng | lifeless: About once a month you suggest it, but then none of us (including me) follow up. :) | 06:39 |
| lifeless | you can now | 06:40 |
| Peng | lifeless: Cool, thanks. I'll land it. | 06:40 |
| lifeless | and you're now in ~bzr. welcome to the firehose | 06:41 |
| Peng | :D | 06:41 |
| StevenK | Peng: Are you the same Peng that hangs around in #linode, too? :-) | 06:42 |
| Peng | StevenK: Yes. | 06:43 |
| igc | bbl | 06:44 |
| chrispitzer | i want to check out from a bzr branch, but I don't want the new working copy to be a bzr repo - just a working copy. | 06:54 |
| chrispitzer | I think there's a command for this... | 06:54 |
| chrispitzer | but I can't find it | 06:54 |
| ChrisMorgan | chrispitzer: I think you want a lightweight checkout then. | 06:55 |
| Peng | chrispitzer: You don't want a local copy of the history? You're looking for "bzr checkout --lightweight" or "bzr branch --stacked", depending on whether you want a checkout or branch. | 06:55 |
| ChrisMorgan | bzr co --lightweight | 06:55 |
| chrispitzer | thanks | 06:55 |
| lifeless | chrispitzer: note that this will be very slow over the internet | 07:00 |
| vila | hi all | 07:07 |
| ChrisMorgan | lifeless: but only for things like log, annotate, etc. Diff shouldn't take longer, commit will take just as long. That's right isn't it? | 07:08 |
| lifeless | ChrisMorgan: no | 07:10 |
| lifeless | diff will take longer | 07:10 |
| lifeless | commit will take longer | 07:10 |
| ChrisMorgan | For a checkout? | 07:11 |
| lifeless | a lightweight one, yes | 07:11 |
| lifeless | diff on a heavyweight one shouldn't be affected | 07:11 |
| ChrisMorgan | Particularly though, why will diff take longer? Doesn't a lightweight checkout still have the latest revision? What would need to be looked at in the network? | 07:11 |
| spiv | ChrisMorgan: a lightweight checkout doesn't have its own copy of the original version to compare to | 07:11 |
| lifeless | commit on a heavyweight one will be slightly affected | 07:12 |
| spiv | ChrisMorgan: it has to fetch that from the repository, so diff will be slower if the repository is not local. | 07:12 |
| lifeless | ChrisMorgan: say your round trip time is 100ms | 07:12 |
| ChrisMorgan | So it's not like an SVN checkout. | 07:12 |
| spiv | ChrisMorgan: rigth | 07:12 |
| spiv | right, rather | 07:12 |
| ChrisMorgan | I thought lightweight made it that way. | 07:12 |
| ChrisMorgan | OK. | 07:12 |
| ChrisMorgan | stacked branch is the same then I presume? | 07:12 |
| spiv | Well, it's like SVN only more extreme :) | 07:12 |
| lifeless | ChrisMorgan: diff on a lightweight checkout will open the branch ~(600ms) and repository ~(400ms) before doing anything locally | 07:12 |
| lifeless | ChrisMorgan: so thats about a second of overhead, before you consider the cost of getting out basis files where a difference is detected | 07:13 |
| spiv | Stacking will at least keep some of the repo locally. | 07:13 |
| ChrisMorgan | And why, oh, /why/ do you have "lightweight" checkouts and "stacked" branches if it's the same thing? | 07:13 |
| lifeless | ChrisMorgan: lightweight makes it roughly like CVS checkouts | 07:13 |
| spiv | But stacking isn't really designed for this case (yet). | 07:13 |
| ChrisMorgan | I'm not really familiar with CVS... I tried it once for some Drupal work and haven't got over the shock yet. | 07:13 |
| spiv | ChrisMorgan: it'd be nice to collapse them, but at the moment they serve different needs | 07:13 |
| lifeless | ChrisMorgan: stacked branches can diverge | 07:13 |
| spiv | ChrisMorgan: there's a huge thread on the mailing list on (broadly) this topic atm :) | 07:14 |
| lifeless | ChrisMorgan: checkouts can't(*), so they aren't really the same thing at all. | 07:14 |
| ChrisMorgan | Yeah, but is the only difference between a checkout and a branch that the first is bound? | 07:14 |
| lifeless | the only difference between 'bzr checkout oo' and 'bzr branch oo' is that the former binds to the source whereas the latter sets the parent to the source | 07:14 |
| lifeless | checkout --lightweight doesn't create a local repo at all and replaces the local branch object with a branch reference pointing at the source | 07:15 |
| poolie | hi vila? | 07:30 |
| vila | poolie: hey ! | 07:30 |
| poolie | vila, i think we're meant to talk | 07:30 |
| vila | poolie: yup, I started the day with a crashed desktop (and was lucky enough to reboot the host only after suspending the guest...) but things seem to be ok now | 07:31 |
| bialix | hello all | 09:11 |
| lifeless | win 38 | 09:14 |
| lifeless | hi bialix | 09:14 |
| bialix | hey lifeless, what's 38? | 09:15 |
| igc | hi bialix! | 09:16 |
| * igc dinner | 09:16 | |
| bialix | hi Ian | 09:16 |
| spiv_ | bialix: the number of the irssi window he failed to switch to (he meant to type /win 38) | 09:16 |
| bialix | btw, igc, I've update explorer translation template | 09:16 |
| doctormo | I'm still having odd problems with threading, could a kind person look over the code quickly and see if they spot any dumb mistakes? | 09:22 |
| doctormo | http://bazaar.launchpad.net/~doctormo/groundcontrol/trunk/annotate/head%3A/nautilus-groundcontrol.py from line 162 to 175 | 09:23 |
| doctormo | and http://bazaar.launchpad.net/~doctormo/groundcontrol/trunk/annotate/head%3A/GroundControl/bazaar.py the entire file is probably of interest. | 09:23 |
| === spiv_ is now known as spiv | ||
| aquarius | bzr's launchpad plugin doesn't, currently, help with the creation of new projects, and I'm looking at hacking on it so that it does so. Was this left out for a reason? | 09:29 |
| spiv | aquarius: no, and we'd welcome improvements to the plugin | 09:36 |
| spiv | aquarius: (originally it was because Launchpad didn't have launchpadlib when the plugin was created, just a couple of XML-RPC methods) | 09:37 |
| aquarius | ah, cool. | 09:37 |
| aquarius | atm, all my small projects live in my svn server, because setting up a launchpad project is a pain by comparison with typing four svn commands :) | 09:38 |
| aquarius | but typing "bzr lp-new-project projectname description" in a folder to make it an LP project would get over that hump quite nicely | 09:39 |
| lifeless | aquarius: this may involve hacking on lp | 09:40 |
| aquarius | lifeless, really? launchpadlib lets me create projects, I think? | 09:41 |
| lifeless | dunno | 09:41 |
| lifeless | coverage of exposed apis can be pretty hit and miss | 09:41 |
| aquarius | should do. if it doesn't I shall whine mightily at leonardr :) | 09:41 |
| aquarius | if I've got a plugin in the system plugins folder and a plugin with the same name in my local plugins folder, the local one will override the system one, yes? | 09:42 |
| lifeless | mtaylor: you really should release a new pandora build if you're talking on it. | 09:43 |
| lifeless | mtaylor: the version I packaged in debian is way old now | 09:43 |
| lifeless | aquarius: ywa | 09:45 |
| jszakmeister | bialix: Hi! I have a quick question about scmproj... | 09:58 |
| bialix | heya jszakmeister! sure | 09:59 |
| jszakmeister | How do you work on a local branch and merge the result back in? | 09:59 |
| bialix | merge locally and then push | 10:00 |
| bialix | maybe I misunderstood your question? | 10:00 |
| jszakmeister | Let's say I have a trunk of library that's in the workspace created by scmproj... | 10:00 |
| jszakmeister | I want to create a branch of trunk for that library, make the change, and get it reviewed by the team. Does scmproj support that sort of workflow? | 10:01 |
| bialix | Usually we're creating new alt for this, and put new branch under that alt | 10:02 |
| bialix | then merging 2 alts when ready | 10:02 |
| bialix | but alts is half way to deprecation | 10:02 |
| jszakmeister | That's what I thought. :-) | 10:03 |
| jszakmeister | Do you envision some other way of doing this? | 10:03 |
| bialix | instead of alts you may want to use just new branch of project config | 10:03 |
| bialix | but today alts are still supported | 10:03 |
| bialix | and sometimes they are much easier | 10:03 |
| bialix | I'll remove alts once I will have new layout format with snapshots ready | 10:04 |
| jszakmeister | I had that thought as well. But the one project I'd like to use it for is massive. | 10:04 |
| jszakmeister | I'd rather not have a whole second tree, if I can avoid it. | 10:04 |
| bialix | new branch of project config is much closer to what nested trees should be | 10:04 |
| bialix | jszakmeister: in the past I've tried to create something like bzr-colo now | 10:05 |
| bialix | today I'd suggest using bzr-colo plugin | 10:05 |
| jszakmeister | I saw that on the list... looks interesting! | 10:05 |
| bialix | I've played with it yesterday and it really in good shape | 10:05 |
| bialix | despite version 0.0.1 | 10:05 |
| bialix | I'm not sure yet I will want to provide tight integration with colo in scmproj | 10:06 |
| bialix | jszakmeister: if you have only branch for one component then I'd use alts today, publish your branch on the server for review, then merge alts | 10:07 |
| bialix | to merge alt from server you need: bzr pcmd "merge {BRANCH_URL}" --alt XXX -i your_library | 10:07 |
| bialix | there --alt XXX will be your alt (corresponding to your new branch) | 10:08 |
| jszakmeister | Yeah, but I don't want to head down a path thats going to be deprecated. | 10:08 |
| bialix | look at http://bialix.com/scmproj/docs/howto.html | 10:08 |
| bialix | http://bialix.com/scmproj/docs/tips-n-tricks.html | 10:09 |
| jszakmeister | I'd rather say "we can't do that right now" instead. | 10:09 |
| bialix | hmm, it's so strong for me | 10:09 |
| bialix | s/so/too/ | 10:09 |
| jszakmeister | :-) | 10:10 |
| jszakmeister | The backend is actually in Subversion, so they have other choices. | 10:10 |
| bialix | you're underestimate the power of pcmd | 10:10 |
| bialix | oh | 10:10 |
| bialix | I don't see the full picture of yours | 10:11 |
| jszakmeister | They have everything in a Subversion backend, and have been using externals to manage the tree. | 10:11 |
| jszakmeister | But it's a PITA. | 10:12 |
| jszakmeister | Plus, the backend is old (before SVN had merge tracking)... | 10:12 |
| doctormo | I'm going to bed now, thanks for the help before, although the problems remain I'm sure it's a simple fix. | 10:12 |
| bialix | bzr-externals? | 10:12 |
| jszakmeister | It'd be nice to switch them to Bazaar and bzr-svn, but we don't *have* to | 10:12 |
| jszakmeister | That was the next one on my list to examine. :-) | 10:13 |
| jszakmeister | The nice thing about scmproj is pcmd | 10:13 |
| jszakmeister | and the fact that you can run operations on everything. | 10:13 |
| jszakmeister | So, bzr-colo... works for more than just trying to get colocated branch support for one "project"? | 10:15 |
| jszakmeister | I thought, from the name, it was really just trying to handle multiple branches of the same project. | 10:17 |
| bialix | bzr-colo provides git-style workflow | 10:19 |
| bialix | multiple [feature] branches of the same project | 10:19 |
| jszakmeister | Yeah, that's what I thought... which is very nice! | 10:20 |
| jszakmeister | I just need something more along the lines of scmproj for the other projects though. | 10:20 |
| bialix | along the lines? | 10:20 |
| jszakmeister | Sorry... I should use better English: "something like scmproj" | 10:21 |
| bialix | no, that's me | 10:21 |
| bialix | well, scmproj is nice when you have set of loosely related components | 10:23 |
| bialix | or when you have common library for several projects | 10:24 |
| jszakmeister | That's exactly our case. | 10:24 |
| bialix | I have no experience with svn:externals though | 10:24 |
| jszakmeister | Be happy that you don't. :-) | 10:24 |
| bialix | just read the docs | 10:24 |
| bialix | :-) | 10:24 |
| bialix | lol | 10:24 |
| bialix | but I mean maybe I'm lack some knowledge | 10:24 |
| bialix | the good thing about small company/startup is that you can choose any vcs you want | 10:25 |
| bialix | but you have to admin it yourself too | 10:25 |
| jszakmeister | :-) | 10:25 |
| bialix | jszakmeister: I'm planning to add some tips about merge in scmproj | 10:27 |
| bialix | or maybe I should finally implement it as separate command | 10:28 |
| jszakmeister | That would be great (either one!) | 10:28 |
| bialix | there is enough special cases user have to care | 10:28 |
| jszakmeister | I completely missed the merge docs the first time around | 10:28 |
| bialix | your position re alts is very strong, I did not expect people can get it this way | 10:29 |
| bialix | thanks for feedback! | 10:29 |
| jszakmeister | You're welcome! | 10:29 |
| bialix | if you have any suggestions or more question: I'll be happy to hear them | 10:30 |
| bialix | today my own experience drives the development of scmproj, but I can miss some other POV | 10:31 |
| jszakmeister | I'm actually trying to write a few things down, but I believe I will have some suggestions for scmproj. | 10:32 |
| vila | testr failiing doesn't seem to be implemented despite being mentioned in README.txt | 10:35 |
| vila | Of course that the one I was interested in :D | 10:35 |
| spiv | vila: failing to fail is still a failure, right? ;) | 10:35 |
| vila | spiv: yes, I'm whining about failing to sucessfully fail :) | 10:37 |
| vila | err, wrong channel for my remark about testr >-) | 10:37 |
| lifeless | well, it will get my attention :P | 10:38 |
| lifeless | #testrepository if you want the 'right channel' | 10:38 |
| bialix | hi vila | 10:53 |
| vila | hi bialix | 10:53 |
| quicksilver | supposing bzr+ssh://remote-a and bzr+ssh://remote-b are two different branches which share 99.9% of their revision history. | 11:14 |
| quicksilver | and they're large enough that they're slow to branch afresh. | 11:14 |
| quicksilver | and I already have a local branch of remote-a | 11:14 |
| quicksilver | what's the quickest way to get a local branch of remote-b? | 11:14 |
| fullermd | Is your local branch of remote-a in a shared repo? | 11:15 |
| RAOF | quicksilver: Have remote-a branched in a shared-repository (initialised with “bzr init-repo”) and then branch remote-b into the same repo. | 11:15 |
| quicksilver | fullermd: no, but if that's the right answer then in future I will arrange for it to be so :) | 11:15 |
| RAOF | I'm pretty sure you can reconfigure remote-a to be in a shared repository. | 11:16 |
| fullermd | Well, you could fudge without it. But you'd be wasting near double the space, from 2 copies of the history. | 11:16 |
| fullermd | Yes, you can. init-repo a repo around it, and use 'reconfigure' to move its history into it. | 11:16 |
| * fullermd sprinkles a few more pronouns into that sentence just for kicks. | 11:16 | |
| RAOF | Metasyntactic variables FTW! | 11:16 |
| quicksilver | fullermd: cool. | 11:18 |
| quicksilver | does 'bzr info' show when you've done it right, I.e. when it is using the shared-repo properly? | 11:22 |
| fullermd | It does. | 11:22 |
| quicksilver | OK. I bzr init-repo . to create my first shared repo. | 11:27 |
| quicksilver | then I bzr branch bzr+ssh://remote-a remote-a to populate it with the first branch | 11:28 |
| quicksilver | and it freezes only a second or so in, saying: | 11:28 |
| quicksilver | [#########| ] 103KB 100KB/s | Fetching revisions:Get stream sourc | 11:28 |
| fullermd | Well, you already have the first branch locally, don't you? | 11:28 |
| quicksilver | oh, it's unfrozen | 11:28 |
| quicksilver | was a good 60 seconds though | 11:28 |
| quicksilver | fullermd: yes, I do. I was faking a clean start to (a) make sure I understood the process and (b) as a basis for explaning it to colleagues | 11:29 |
| fullermd | I've been trying to fake a clean start for years, but I haven't managed to burn all copies of the.... | 11:29 |
| fullermd | Uh... | 11:30 |
| fullermd | Nevermind. Didn't say anything. | 11:30 |
| quicksilver | :) | 11:30 |
| quicksilver | I think some kind of insect is trapped inside the bzr process now. chk:chk it's going. | 11:37 |
| quicksilver | perhaps a baby bird. | 11:37 |
| fullermd | That's the buzzer. Hence the name. | 11:37 |
| fullermd | chk:chk means there's a small sliver of paper stuck between the hammer and the bell. You probably need to empty out the bit bucket. | 11:39 |
| quicksilver | OK, the results are in. | 11:41 |
| quicksilver | a clean branch of one of these branches took 4m30 | 11:41 |
| quicksilver | the first branch into a shared-repo took 13m56 | 11:41 |
| quicksilver | but then a subsequent branch (a similar but different branch) took 45 seconds | 11:42 |
| quicksilver | definitely better | 11:42 |
| quicksilver | that's quite apart from the disk space savings, which were pretty close to the 'ideal' 50% | 11:43 |
| quicksilver | but to be honest disk space isn't what I care about | 11:43 |
| quicksilver | it's branch time. | 11:43 |
| fullermd | Yeah. But they go hand in hand. | 11:43 |
| quicksilver | and making a new local branch took only 4 seconds | 11:44 |
| quicksilver | (mind you it only took 23 seconds without shared repos) | 11:45 |
| quicksilver | only takes 5 seconds to branch something which was previously local into the shared repo | 11:56 |
| quicksilver | bit suspiciously fast that ;) | 11:56 |
| quicksilver | Hmm. Trying transfer another previously local branch in has pushed a python process up to 2.2G resident | 11:58 |
| quicksilver | that doesn't sound very good. | 11:59 |
| quicksilver | and eventually died with Python(31106) malloc: *** mmap(size=1268281344) failed (error code=12) | 11:59 |
| quicksilver | *** error: can't allocate region | 11:59 |
| quicksilver | *** set a breakpoint in malloc_error_break to debug | 11:59 |
| quicksilver | I'm not sure I believe this is working right | 12:05 |
| quicksilver | It's not downloaded 100M for this branch, which is basically everything. | 12:05 |
| quicksilver | that doesn't seem like the shared-repo bit did its stuff | 12:06 |
| quicksilver | could it be a problem that the remote formats are all pack-0.92? | 12:09 |
| persia | Out of sheer curiosity, if I just want a copy of the source, ought I expect bzr branch ${foo} or bzr export ${foo} to generate less network traffic? | 12:15 |
| lifeless | persia: often branch | 12:18 |
| lifeless | though export has been improved a lot in 2.1 | 12:19 |
| lifeless | export will read less, but do more roundtrips before 2.1 | 12:19 |
| lifeless | [proportional to tree size] | 12:19 |
| persia | Interesting. Thanks. I had wondered about using export as a super-lightweight branch for review and delete, but I think I won't do that :) | 12:20 |
| quicksilver | OK. I can't even 'bzr upgrade' this particular branch in place | 12:25 |
| quicksilver | I conclude this is somehow a 'corrupted' branch. | 12:25 |
| lifeless | quicksilver: I'm going to sleep now, but I suggest yous tart giving details | 12:33 |
| lifeless | quicksilver: as I can't infer anything from the comments you've been making, and corruption is extremely rare | 12:33 |
| quicksilver | lifeless: well the details are only just beginning to come clear to me. | 12:36 |
| quicksilver | We have many branches of one basic codebase. | 12:36 |
| quicksilver | One of them, it turns out, is behaving anomalously. | 12:36 |
| quicksilver | On the server its' 300M whilst the others are 100M (I don't know if this is relevant, but it's odd) | 12:36 |
| quicksilver | and any attempt to 'branch' it causes a python out-of-memory error. | 12:36 |
| quicksilver | I also have a local copy on this machine, which is a couple of months old | 12:37 |
| quicksilver | although I presumably downloaded that successfully at the time, any attempt to branch that branch locally gives the same error. | 12:37 |
| quicksilver | and any attempt to 'bzr upgrade' it to a more modern format, same error. | 12:37 |
| quicksilver | ok, I got the uploader of that branch to push a fresh copy, and I managed to branch that fresh copy | 13:04 |
| quicksilver | but it took ages (maybe that's just consistent with the weirdly inflated size) and there is something odd about it | 13:04 |
| quicksilver | Standalone tree (format: unnamed) | 13:04 |
| vila | quicksilver: try 'bzr info -v', unnamed means you're using an unusual combination | 13:08 |
| vila | do the same for the remote branch | 13:08 |
| vila | if the repository formats are different, it's likely the slowness is due to the on-the-fly conversion | 13:09 |
| quicksilver | control: Meta directory format 1 | 13:11 |
| quicksilver | working tree: Working tree format 6 | 13:11 |
| quicksilver | branch: Branch format 6 | 13:11 |
| quicksilver | repository: Packs containing knits without subtree support | 13:11 |
| quicksilver | vila: how would I have "got into" an unusual combination? And how do I get out of it again? | 13:13 |
| vila | well, using a shared repo is one way | 13:13 |
| quicksilver | I did briefly experiment with shared repos | 13:14 |
| quicksilver | bt I'm not using one here | 13:14 |
| vila | ok (bzr info should tell you anyway) | 13:14 |
| quicksilver | and as I remarked earlier, 'bzr upgrade' crashes in this branch. | 13:14 |
| vila | that's bad, what does 'bz check' says ? | 13:14 |
| vila | s/bz/bzr/ | 13:15 |
| quicksilver | running it now... | 13:16 |
| quicksilver | seems to take a little while | 13:16 |
| vila | that's expected | 13:17 |
| quicksilver | ok I'll let you know when it's finished, and eat a sandwich | 13:19 |
| quicksilver | vila: 3927 revisions | 13:22 |
| quicksilver | 3468 file-ids | 13:22 |
| quicksilver | 330 inconsistent parents | 13:22 |
| vila | yup, that's bad enough, do 'bzr reconcile' | 13:23 |
| vila | sorry if you already reply to that but what bzr version are you using ? | 13:24 |
| quicksilver | vila: 2.0.2 on the server 2.0.1 on my client | 13:25 |
| vila | ok, not the latest but good enough | 13:25 |
| vila | any reason to keep using 0.92 as your repo format ? | 13:26 |
| quicksilver | (although the developer who created / pushed this apparently broken branch is only on 1.13.1 | 13:26 |
| quicksilver | (and we have another developer who is also on 1.13.1 | 13:26 |
| quicksilver | but they could both be told to upgrade. | 13:26 |
| maxb | quicksilver: To clarify, it's an 'unnamed' format because it's pack-0.92 repo/branch combined with Bazaar 2's tree format. bzr 2.x likes to give you the latest tree format even if it doesn't fit into one of the canned names which for {repo, branch, tree} combinations. | 13:26 |
| quicksilver | maxb: *nod* interesting. | 13:27 |
| vila | that would allow you to use 2a which will be more compact and faster across the network too | 13:27 |
| quicksilver | vila: I had been thinking about upgrading the repo format | 13:27 |
| quicksilver | vila: in fact it was this train of thought I had | 13:27 |
| quicksilver | "Hmm should use bzr better, let's learn about shared repos and upgrade our repo formats" | 13:27 |
| quicksilver | I was following that train of thought and experimenting with some of our branches when I discovered this broken one. | 13:27 |
| quicksilver | reconciliation only took 3 minutes. That's a relief. | 13:28 |
| vila | both should make a significant difference, but upgrading to 2a requires a 'bzr check; bzr reconcile' anyway, so you're on the right track :) | 13:28 |
| vila | redo 'bzr check' to be on the safe side :) | 13:28 |
| maxb | Requires? Or just a sensible precaution? | 13:29 |
| vila | precaution | 13:29 |
| quicksilver | the branch size has doubled again | 13:29 |
| quicksilver | from 300M to 600M | 13:29 |
| vila | check you /bzr/reposiroty/obsolete_packs | 13:29 |
| vila | s/you/your/ | 13:30 |
| vila | rhaa, .bzr/repository/obsolete_packs content, gee | 13:30 |
| quicksilver | I ran bzr check in another branch | 13:30 |
| quicksilver | one which, as far as I knew, was fine. | 13:30 |
| quicksilver | it also has the same 330 inconsistent parents | 13:30 |
| quicksilver | yup. 278M in obsolete_packs. | 13:31 |
| quicksilver | personally I still think it's suspicious this branch is 3x as large as the others | 13:31 |
| vila | at least... | 13:32 |
| vila | yeah, but 3x is better than 6x | 13:32 |
| quicksilver | it does have quite a few changes relative to the others, but not *that* many. | 13:32 |
| vila | err, I mean, it shoudn't be 3x | 13:32 |
| quicksilver | I am in the process of re-running bzr check | 13:32 |
| quicksilver | vila: OK, it now passes bzr check. | 13:37 |
| quicksilver | (which took 6 minutes to run) | 13:37 |
| quicksilver | but it's odd that even the branches I consider "OK" have the same inconsistent parents. | 13:37 |
| quicksilver | I'm going to try to bzr upgrade this branch now I think | 13:37 |
| vila | you want to run 'bzr reconcile' in all these branches | 13:38 |
| quicksilver | yes, I see that | 13:38 |
| quicksilver | so what does inconsistent parents mean? A problem has been lurking which by luck hasn't bitten us before? | 13:39 |
| quicksilver | and now in this branch for some reason it's biting us | 13:39 |
| vila | most probably, it's hard to say for sure from here :-/ | 13:40 |
| vila | It could also be unrelated, IIRC there was several weird cases were you could end up with inconsistent parents, not all of the same gravity | 13:40 |
| quicksilver | well if bzr upgrade works now, where it didn't work before, then I guess I have "fixed" something" | 13:41 |
| quicksilver | if not, then it's still broken. | 13:41 |
| quicksilver | and I still wonder what event in branch history made the size triple | 13:41 |
| quicksilver | if needs be, I'll binary chop the revisions | 13:41 |
| vila | you can try eyegrepping 'bzr log -n0 -v' | 13:42 |
| vila | It could be some binary file... | 13:42 |
| vila | We had a case where someone embedded a whole $DVCS_TOOL repo during several revisions, modified at each revision... ended up with quite a big repo | 13:43 |
| quicksilver | nervously watches Python's resident size increase | 13:45 |
| quicksilver | last time it hit 2G and then died with a malloc error | 13:45 |
| vila | quicksilver: well, 2.1 includes some related fixes you may want to try... | 13:46 |
| quicksilver | vila: do I need to bzr reconcile on ther server and also get everyone to bzr reconcile on each client? | 13:46 |
| quicksilver | (that or pull clean branches, presumably) | 13:46 |
| vila | yup | 13:46 |
| vila | depending on your experiences you may prefer one way or the other, it depends on too many things to have single answer | 13:47 |
| quicksilver | vila: slight reluctance to use beta versions in production, but if you strongly advise it I'd follow your advicee. | 13:47 |
| vila | if you end up with smaller repo and that people use shared repos, you may end up downloading it >1 times | 13:48 |
| quicksilver | OK, there she goes. | 13:48 |
| quicksilver | python resident space > 2G | 13:48 |
| quicksilver | malloc failure coming shortly. | 13:48 |
| quicksilver | Python(31916) malloc: *** mmap(size=759209984) failed (error code=12)revisions | 13:49 |
| quicksilver | *** error: can't allocate region | 13:49 |
| quicksilver | *** set a breakpoint in malloc_error_break to debug | 13:49 |
| vila | something fishy is going on here, first the 3x increase, now the > 2G mem footprint, that's really really far from the 100M size you're mentioning :-/ | 13:49 |
| vila | does that come with a traceback ? | 13:49 |
| quicksilver | no, in fact, in didn't even kill python | 13:50 |
| quicksilver | it just printed that message | 13:50 |
| quicksilver | its RSS has dropped to a more "reasonable" 400M and the upgrade claims to still be running | 13:51 |
| === mrevell is now known as mrevell-lunch | ||
| vila | wow, let it run then ! | 13:53 |
| quicksilver | ah, eventually | 13:53 |
| quicksilver | Python(31916) malloc: *** mmap(size=691982336) failed (error code=12)revisions: | 13:53 |
| quicksilver | *** error: can't allocate region | 13:53 |
| quicksilver | *** set a breakpoint in malloc_error_break to debug | 13:53 |
| quicksilver | bzr: out of memory | 13:53 |
| quicksilver | I think the long pause was actually the process of freeing enough memory to print the error message :-/ | 13:53 |
| quicksilver | no traceback I'm afraid. | 13:54 |
| quicksilver | vila: I have a plan to try to branch an old revision which doesn't have the problems and then successively pull forward, how does that sound? | 13:54 |
| vila | good, as long you can identify the faulty revision... | 13:56 |
| quicksilver | vila: further clue. | 13:59 |
| quicksilver | or is it | 14:00 |
| * quicksilver tries to get facts straight | 14:00 | |
| maxb | What exactly is an 'inconsistent parent'? What's it inconsistent with? | 14:01 |
| quicksilver | I was able to "bzr branch bzr+ssh:/remote-bad-branch bad-branch | 14:02 |
| quicksilver | I was then also able to "bzr branch bad-branch bad-branch-copy" | 14:02 |
| quicksilver | but since I did reconcile I can't even do that | 14:03 |
| SamB_XP | maxb: what is the exact error you're getting ? | 14:03 |
| quicksilver | I can't even locally copy the branch with bzr branch | 14:03 |
| quicksilver | before the reconcile, I could, and it only took 30 seconds or so to boot. | 14:03 |
| maxb | SamB_XP: None, just interested in understanding more about bzr's guts | 14:03 |
| SamB_XP | well, where did you see the term then? | 14:04 |
| quicksilver | in my report, SamB_XP | 14:04 |
| SamB_XP | ah. | 14:04 |
| quicksilver | when I bzr check'ed my odd branch. | 14:04 |
| SamB_XP | I was puzzled about why maxb had asked about a single consistant parent -- I've only ever heard it in the plural before | 14:05 |
| SamB_XP | er. *inconsistant | 14:05 |
| quicksilver | OK, I have confirmed by double-checking. | 14:06 |
| quicksilver | I can locally branch the un-fixed branch | 14:06 |
| quicksilver | but locally branching the 'fixed' (reconciled) branch gives the out of memory error. | 14:06 |
| quicksilver | use a DVCS for 4 years and never encounter a single problem, but when I hit a bug, boy is it a painful one :-/ | 14:11 |
| quicksilver | vila: OK, I found a sufficiently old branch not have the 'size inflation'. | 14:21 |
| quicksilver | vila: guessing that might be related, I'm going to reconcile + upgrade from this old revision and see how that goes. | 14:21 |
| vila | and from a complete branch, did you see anything suspicious in the following revs (with 'bzr log -n0 -v') ? | 14:22 |
| quicksilver | I'm currently use a bash for loop to give me a copy of every intermediate revision | 14:23 |
| quicksilver | so I can see where the size inflation is | 14:23 |
| vila | ok | 14:24 |
| quicksilver | the bzr log -n0 was rather long to look at... | 14:24 |
| CaMason | I've got a branch which I've been using as my 'trunk'. To move this to a different physical location, can I just move the repo? | 14:29 |
| rubbs | CaMason: best way is to just branch it to the new location then delete the old one. | 14:30 |
| rubbs | CaMason: I knoticed that the actual repo (on my windows machine) wouldn't work if it wasn't in it's old path for some reason. | 14:30 |
| CaMason | ok. That maintains all of the branch history yes? | 14:30 |
| rubbs | but if I branched it and deleted the old one it worked. | 14:31 |
| rubbs | yes | 14:31 |
| CaMason | sounds good | 14:31 |
| quicksilver | vila: OK. Using an old branch revision which doesn't suffer the size inflation, the sequence check/reconcile/upgrade worked. | 14:35 |
| quicksilver | vila: so I am inclined to consider the size inflation to be related to this bug, somehow | 14:35 |
| vila | that would be really weird | 14:36 |
| quicksilver | vila: I note taht format 2a does seem to be about 1.5x larger than pack-0.92 | 14:36 |
| quicksilver | is that expected? | 14:36 |
| quicksilver | I don't really mind. | 14:36 |
| vila | larger ? Certainly not, check /obsolete_packs again | 14:36 |
| quicksilver | right. roger that. | 14:37 |
| quicksilver | looking good. | 14:37 |
| quicksilver | about 80% the size? | 14:37 |
| quicksilver | 20% smaller, i.e. | 14:37 |
| quicksilver | now I'm going to try to pull into this "good" branch from the other | 14:37 |
| vila | 20% smaller is a bit deceiving but still smaller, we've seen more savings | 14:39 |
| vila | quicksilver: do that on a copy if you don't mind :) | 14:39 |
| vila | I thought you made several branches to identify the size inflation ? | 14:40 |
| quicksilver | yes, I have many many branches | 14:40 |
| quicksilver | and yes, I made a copy :) | 14:40 |
| quicksilver | in fact, I did this check/reconcile/upgrade experiment on revision 896 | 14:40 |
| quicksilver | I started that *before* I learn that revision 915 was the last revision not to suffer size inflation. | 14:41 |
| vila | ok | 14:41 |
| quicksilver | so what I'm doing now is, (in a copy) pulling into my upgraded 896 from 915 | 14:41 |
| quicksilver | that went fine, apparently. | 14:41 |
| vila | so what's in 916 ? | 14:41 |
| quicksilver | unfortunately it's a massive merge | 14:42 |
| quicksilver | 39 merged revisions | 14:42 |
| vila | how many files ? Any binary ? | 14:42 |
| quicksilver | yes there is a binary file in there. It's 1.3 megabytes | 14:42 |
| quicksilver | (and a few smaller binary files) (and many many text files) | 14:42 |
| quicksilver | I believe this is about to crash | 14:43 |
| vila | 1.3M is not big, search for > 50M | 14:43 |
| quicksilver | Python process up to 1G resident and climbing. | 14:43 |
| vila | amazing | 14:43 |
| quicksilver | pretty sure there are no files that big. | 14:43 |
| vila | any chance to publish these branches ? | 14:43 |
| quicksilver | not really :( | 14:46 |
| quicksilver | 4 years of private code history. | 14:46 |
| quicksilver | two python memory errors but the bzr pull is still running so I'll let it try. | 14:48 |
| vila | quicksilver: still using 2.0.3 ? | 14:49 |
| quicksilver | 2.0.1 in fact | 14:50 |
| vila | quicksilver: trying with bzr.dev is worth it I think, try pinging jam to get his opinion though he made most of the memory fixes | 14:50 |
| jam | morning vila | 14:50 |
| vila | magic.... | 14:50 |
| jam | no opinions here | 14:50 |
| jam | :) | 14:50 |
| jam | let me read | 14:50 |
| vila | morninbg jam | 14:50 |
| quicksilver | vila: well knock me down with a feather | 14:50 |
| * vila stop chewing while typing | 14:50 | |
| jam | you guys have been chatting for a long time... | 14:51 |
| quicksilver | vila: despite two scary looking memory errors, the bzr pull has succeeded. | 14:51 |
| jam | care to summarize? | 14:51 |
| quicksilver | jam: painful out of memory errors doing certain operations with a particular branch | 14:51 |
| vila | yup, quicksilver is encountering memory errors (no traceback, direct from python) while pulling 0.92 branches | 14:51 |
| quicksilver | jam: including: errors when branching, errors when merging, errors when trying to 'bzr upgrade' | 14:51 |
| vila | that's with bzr-2.0.1. | 14:52 |
| jam | quicksilver: no traceback even with -Derror? | 14:52 |
| jam | (and nothing in ~/.bzr.log ?) | 14:52 |
| quicksilver | jam: comparing my branches en-masse, these errors seem to be co-incident with the repository size on disk jumping from 100M to 300M at a particular revision | 14:52 |
| vila | <quicksilver> Python(31916) malloc: *** mmap(size=691982336) failed (error code=12)revisions: | 14:52 |
| quicksilver | and I don't believe there is a good reason for the size jump; I don't think we added then deleted a 50M binary file or anything of that nature. | 14:53 |
| jam | quicksilver, vila: allocating 691MB in a single shot? | 14:53 |
| quicksilver | yes. | 14:53 |
| quicksilver | other errors with slightly different numbers | 14:53 |
| vila | no, more like 200M | 14:53 |
| vila | haa, the malloc hyes | 14:53 |
| jam | quicksilver: 64-bit machine? | 14:53 |
| quicksilver | e.g. | 14:53 |
| quicksilver | Python(32408) malloc: *** mmap(size=1267761152) failed (error code=12) | 14:53 |
| quicksilver | *** error: can't allocate region | 14:53 |
| quicksilver | *** set a breakpoint in malloc_error_break to debug | 14:53 |
| quicksilver | Python(32408) malloc: *** mmap(size=759758848) failed (error code=12)xts:texts | 14:53 |
| quicksilver | *** error: can't allocate region | 14:53 |
| quicksilver | *** set a breakpoint in malloc_error_break to debug | 14:53 |
| quicksilver | jam: core2, so technically yes, but running OSX 10.5, so in practice I believe it counts as 32 bit. | 14:54 |
| jam | quicksilver: just run 'python' and see what it says | 14:54 |
| quicksilver | note that those two errors I just pasted occurred during a bzr pull which appears to have succeeded! | 14:54 |
| jam | I'm not sure about mac, but on Windows I get: [MSC v.1500 32 bit (Intel)] | 14:54 |
| quicksilver | it spewed out that malloc stuff but still ran to completion. | 14:54 |
| quicksilver | Python 2.6.4 (r264:75706, Nov 12 2009, 09:19:07) | 14:56 |
| quicksilver | [GCC 4.0.1 (Apple Inc. build 5488)] | 14:56 |
| quicksilver | not much help there. | 14:56 |
| jam | quicksilver: import sys | 14:56 |
| jam | sys.sizeof(1) | 14:56 |
| jam | sorry | 14:56 |
| jam | sys.getsizeof(1) | 14:56 |
| jam | 12 == 32-bit, 24 == 64-bit | 14:57 |
| quicksilver | 12 | 14:57 |
| quicksilver | vila: so, that bzr pull which appeared to succed, has jumped the repo size to 470M (from 80M) | 14:57 |
| vila | bam 400M | 14:58 |
| quicksilver | vila: admittedly some more crap has appeared on obsolete_packs which I could remove, but there is still 250M in packs | 14:58 |
| vila | so 170M increase | 14:58 |
| quicksilver | yes, or roughly 3x | 14:58 |
| vila | and that's with your upgraded branch right ? So 2a format ? | 14:58 |
| quicksilver | 80->250M is quite consisten with the 100M -> 300M I had in pack-0.92 | 14:59 |
| quicksilver | yes, this is with 2a format | 14:59 |
| quicksilver | find . -size +1000 | xargs ls -lh | 15:00 |
| quicksilver | the only files > 500K are one 500K jpeg and a few .pack, .cix, .tix files | 15:00 |
| vila | quicksilver: that may not be enough, you may have to bisect in the merge revisions | 15:01 |
| quicksilver | in particular, one killer .pack of 192M and one of 55M | 15:01 |
| vila | but those are in .bzr not committed in your branch right ? | 15:01 |
| quicksilver | right | 15:02 |
| quicksilver | there are no large files in the working tree | 15:02 |
| vila | quicksilver: it's really weird to see the same size increase in 0.92 and 2a that use very different conpressions algorithms | 15:02 |
| quicksilver | (that jpg of 500K is the largest) | 15:02 |
| quicksilver | I'll knock up a script to bisect all the merge revisions | 15:03 |
| vila | in the mean time, 'bzr log -r-2..-1 -n0 -v' may be less huge | 15:03 |
| vila | than it was for the whole branch | 15:03 |
| rubbs | isn't there a bisect plugin already? | 15:03 |
| rubbs | I've used it before | 15:03 |
| jam | rubbs: there is | 15:04 |
| quicksilver | Im' not actually going to bisect | 15:04 |
| quicksilver | I'm lazy | 15:04 |
| quicksilver | I'm just going to branch ever intermediate revision and look at the disk spaces they use | 15:05 |
| jam | vila, quicksilver: well, if you are versioning binary files like .jpg, it isn't like we can get tremendous size improvements | 15:05 |
| jam | quicksilver: are you running from source? | 15:05 |
| quicksilver | jam: I don't think the binary files are the issue here | 15:05 |
| jam | I just want to check that you built the extensions | 15:05 |
| quicksilver | they are small and change rarely. | 15:05 |
| quicksilver | I'm running from macports, which kind-of-source | 15:05 |
| jam | The 2a pure-python compressor doesn't do nearly as good of a job as the C version | 15:06 |
| vila | jam: a review of https://code.edge.launchpad.net/~vila/bzr/conflict-manager/+merge/16785 will be highly appreciated | 15:06 |
| jam | quicksilver: I think it compiles extensions, though | 15:06 |
| vila | jam: but the size increase was there for 0.92 too... | 15:06 |
| jam | vila: so I think he has more data | 15:06 |
| jam | but the question is how much should it increase | 15:06 |
| jam | quicksilver: the loop over pull is often a good indicator | 15:06 |
| quicksilver | what do you mean? | 15:07 |
| * vila needs to reboot, bbiab | 15:07 | |
| quicksilver | jam: of course it's only a hunch that the weird out of memory errors I have seen are related to this sudden lurch in repo sizes. | 15:09 |
| quicksilver | jam: but we have many many branchs, some live, some dead, and we use bzr a lot | 15:10 |
| quicksilver | and it's just on one particular branch that we have this strange issue | 15:10 |
| quicksilver | ...and that's the branch with the inflated repo size. | 15:10 |
| jam | quicksilver: there are a few different ways it could happen, old code or new code | 15:14 |
| jam | the new format hasn't been super-tuned for memory performance during pack | 15:14 |
| jam | it is better for getting data out, commit, etc | 15:15 |
| jam | but 5x the size of the largest file wouldn't suprise me | 15:15 |
| jam | that doesn't quite explain 1GB that you pasted earlier, though. | 15:15 |
| quicksilver | understood, but as far as I know there are no large files. | 15:15 |
| jam | Python(32408) malloc: *** mmap(size=1267761152) failed (error code=12) | 15:15 |
| quicksilver | unless you think a 500k jpg is large? | 15:15 |
| jam | quicksilver: no I'm talking 100+MB files | 15:15 |
| * quicksilver nods | 15:16 | |
| quicksilver | ok well there's another python memory error | 15:16 |
| quicksilver | looks like I may have found the precise revision that causes it | 15:16 |
| * quicksilver reviews changelog for that revision | 15:16 | |
| jam | vila: personal impression, 'bzr resolve' is a bit confused as to what it wants to be, and it is hard for me to give a clear-cut answer for it | 15:16 |
| quicksilver | it is also odd that these memory errors can occur but the branch still succeeds | 15:17 |
| jam | quicksilver: that is quite surprising to me as well | 15:18 |
| jam | I do believe that the OS is the one reporting the error | 15:18 |
| jam | and not python | 15:18 |
| jam | but if the OS is not returning NULL on a bad malloc | 15:18 |
| jam | something is weird | 15:18 |
| vila | right, but what about the rest ? I said to poolie this morning that 1) I targetting 2.2 so no hurry, but no review means I'm stuck 2) I'll try to do a summary mail about the main aims of this work but that mp is just a first step | 15:19 |
| jam | quicksilver: http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man3/malloc.3.html | 15:19 |
| quicksilver | HAHAHA | 15:19 |
| jam | You might look at setting one of the ENV vars | 15:19 |
| quicksilver | ok, so it looks like part of this is myfault | 15:19 |
| quicksilver | or at least one of my developer's faults :P | 15:20 |
| jam | quicksilver: what's up? | 15:20 |
| jam | (custom plugin?) | 15:20 |
| quicksilver | there is a 691 megabyte text file in this revision | 15:20 |
| * vila bets for a bzr branch committed into the branch | 15:20 | |
| quicksilver | (which he deleted in the next revision) | 15:20 |
| vila | haaaaaaaaaaaaaa | 15:20 |
| jam | well, that explains the bloat :) | 15:20 |
| quicksilver | and it *probably* explains the bugs too | 15:20 |
| quicksilver | in that that was probably causing out of memory errors all over the shop. | 15:21 |
| jam | quicksilver: well it explains why we would try to malloc a huge range | 15:21 |
| jam | I'm not sure why it succeeds but complains about malloc, etc. | 15:21 |
| vila | quicksilver: time to teach about 'bzr uncommit' in cases like this | 15:21 |
| jam | vila: and it would be good to have a "bzr nuke-this-frickin-file" | 15:22 |
| quicksilver | so, what is the most efficient way to change history? | 15:22 |
| vila | quicksilver: history being immutable, you can't just take that revision out of the repo, you'll have to recreate that branch with | 15:22 |
| jam | quicksilver: rebase | 15:22 |
| vila | quicksilver: yeah bzr-rebase, jam finishes my sentence :) | 15:23 |
| jam | I think it is called "bzr-rewrite" as the plugin name | 15:23 |
| jam | but "rebase" or "replay" would be the commands you'd want | 15:23 |
| quicksilver | that will let me replay a bunch of revisions, including their commit messages, leaving out some detail? | 15:25 |
| quicksilver | http://wiki.bazaar.canonical.com/Rebase ? | 15:26 |
| === mrevell-lunch is now known as mrevell | ||
| vila | quicksilver: https://launchpad.net/bzr-rewrite | 15:27 |
| vila | but yes, that's the idea | 15:27 |
| jam | quicksilver: yeah, the plugin changed names | 15:27 |
| jam | well sort of | 15:27 |
| jam | I don't think he has finished migrating | 15:27 |
| jam | because debian hasn't changed his package name | 15:28 |
| jam | so I think you have to "bzr co lp:bzr-rewrite rebase" | 15:28 |
| jam | which is... odd :) | 15:28 |
| quicksilver | there is a bzr-rebase 0.53 in macports | 15:29 |
| quicksilver | the description at http://wiki.bazaar.canonical.com/Rebase does not suggest to me it can actually change revisions | 15:30 |
| quicksilver | sounds like it just changes tree shape | 15:30 |
| quicksilver | (I've changed tree shape in the past by carefully chosen back-and-forth merges) | 15:30 |
| jam | quicksilver: the idea of rebase is "take a commit that looks like X, and create a new commit with the same delta, but applied to a different base" | 15:32 |
| jam | So the idea is that for the branch where he added and removed the file | 15:32 |
| jam | you would rebase the commit after removing the file | 15:32 |
| jam | onto the commit before adding the file | 15:32 |
| jam | note that it requires rebasing all revisions that follow | 15:32 |
| jam | which is... unfortunate | 15:32 |
| quicksilver | ah, so you "coalesce" the two revisions which add+remove the file into one | 15:33 |
| quicksilver | which makes the file vanish from history entirely | 15:33 |
| quicksilver | and then you have to replay the rest of history after that. | 15:33 |
| jam | quicksilver: right | 15:33 |
| quicksilver | the first part I could do easily enough by hand. | 15:33 |
| quicksilver | the annoying part is replaying history | 15:33 |
| jam | yep | 15:33 |
| quicksilver | especially if I want to maintain the merge shape | 15:33 |
| quicksilver | although, bzr bundle is enough to maintain commit messages isn't it? | 15:34 |
| quicksilver | no, bzr bundle will have a note of the missing revision | 15:34 |
| quicksilver | and complain it's not there. | 15:34 |
| quicksilver | in fact I can't see how do to this by hand. | 15:38 |
| quicksilver | in a way which preserves the merge points with external revisions | 15:38 |
| quicksilver | (of which there are many) | 15:38 |
| jam | quicksilver: I believe you can rebase --include-merges | 15:38 |
| jam | but yeah, it is quite tricky to do by hand | 15:38 |
| quicksilver | well I'm installing bzr-rebase now | 15:39 |
| gerard_ | hey all, any reason for the terminal window you get when launching Bazaar Explorer on windows? | 15:40 |
| quicksilver | jam: OK I've installed bzr rebase, I've read the bzr rebase documentation, and I still don't understand what I'm supposed to do. I don't see how to tell it to ignore/coalesce the bad revisions. | 15:42 |
| jam | gerard_: lack of developer time to get rid of it :) | 15:42 |
| === SteveA_ is now known as SteveA | ||
| jam | it isn't terribly hard, but I ran into version compatibilty problems when i tried | 15:43 |
| jam | (py2.6 + pyqt4.5 + py2exe didn't like to play well together) | 15:43 |
| jam | it shouldn't be hard to fix as those seem to have gotten sorted out | 15:43 |
| gerard_ | jam: ah ok | 15:43 |
| gerard_ | it might just annoy me enough to get rid of it | 15:44 |
| jam | gerard_: Quick note, you want to set up a 'py2exe' target in bzr's setup.py that uses "window = ['bzr-explorer.py']" | 15:45 |
| jam | and then implement a bzr-explorer.py that is running the equivalent of "bzr explorer $ARGS" | 15:45 |
| jam | I can give some more help if you want to work on it. | 15:45 |
| jam | it is something I would *like* to get to, but not enough tuits yet :) | 15:45 |
| quicksilver | I see no alternative but to work carefully up through the revision history and re-apply partial diffs, being sure to re-merge wherever there was a merge | 15:55 |
| vila | quicksilver: I never used it myself but I was almost sure it was included in bzr-rewrite, jam, could I be confused with something in bzr-fastimport instead ? | 15:56 |
| quicksilver | we surely can't be the first people to ever need to change history in this way ;) | 15:58 |
| jam | quicksilver: I don't know what 'bzr replay' or 'bzr rebase' supports. I know there is an "include-merges" flag. | 15:58 |
| gerard_ | jam: thx, I'll keep that in mind, I might have some time tonight | 15:58 |
| quicksilver | jam: yes, I see the merge options, but I don't see how to start it off by saying "pretend this bit never happened" | 15:59 |
| vila | quicksilver: Be also aware that the branch you are re-building should become the reference and that no-one should merge a poisoned branch into it... | 15:59 |
| gerard_ | bye | 16:00 |
| quicksilver | vila: yes, need to expunge all poisoned branches. | 16:01 |
| quicksilver | vila: but first I need to build a good one | 16:01 |
| quicksilver | I wonder if a careful bit of shelving is enough | 16:02 |
| jam | quicksilver: so create a branch that is just before the add | 16:05 |
| jam | then tell bzr-replay to replay the revision just after | 16:05 |
| jam | or create a branch just after | 16:05 |
| jam | bzr uncommit | 16:05 |
| jam | bzr rm bad-file | 16:06 |
| jam | bzr commit -m "new rev without bad file" | 16:06 |
| jam | then bzr replay everything after that | 16:06 |
| jam | (or rebase) | 16:06 |
| quicksilver | right. That makes perfect sense. | 16:06 |
| jam | the specific syntax isn't great, and I'm never quite sure whether rebase is "apply this to that" or "apply that to this" | 16:06 |
| quicksilver | bzr rebase takes a branch as its only parameter | 16:07 |
| jam | quicksilver: doesn't it take --revision (-r) as well? | 16:07 |
| jam | vila: quick question | 16:07 |
| jam | for Copyright headers | 16:07 |
| * vila afk for ~ ok | 16:07 | |
| jam | when would you collapse to 'range' notation? | 16:07 |
| jam | would you collapse 2007, 2008, 2009 or only at 2007, 2008, 2009, 2010 ? | 16:08 |
| jam | I certainly wouldn't collapse 2007, 2008 => 2007-2008 | 16:08 |
| vila | Never said I will, but I've seen multi-lines copyright just after you mentioned the problem | 16:08 |
| jam | also, should it be "2007-2010" or "2007 - 2010" | 16:08 |
| vila | I thought range notation ought to be avoided but IANAL and I forgot why | 16:09 |
| jam | vila: I thought so too, but poolie just submitted a patch with ranges | 16:09 |
| jam | and I have to say, it looks a lot nicer than 2005-2010 expanded | 16:10 |
| jam | -# Copyright (C) 2005, 2006, 2007, 2008, 2009 Canonical Ltd +# Copyright (C) 2005-2010 Canonical Ltd | 16:10 |
| vila | and the multi-line occurrence was from a source I thought was valid and serious when I read it | 16:10 |
| vila | yeah, not sure lawers care about nice looking :) | 16:10 |
| jam | ok, for now I'm using >= 4 years as the collapsing point | 16:11 |
| vila | so, afk for ~<1h starting now :) | 16:11 |
| jam | vila: enjoy your time off :) | 16:12 |
| jam | http://www.mateoaboy.com/f6/blog_files/e740002542ebfcf81fae2653baaf4170-12.html | 16:12 |
| jam | "In the cases of derivative works it is recommended to indicate a range of years for a work (although this is not required by law)." | 16:12 |
| jam | I haven't found anything about not using "-" | 16:13 |
| quicksilver | jam: hm. Of coruse. The uncommit version leaves the uncommited revision in the repo :) | 16:14 |
| quicksilver | jam: so my large file is still there, just in an orphaned revision. | 16:14 |
| jam | quicksilver: yep, but fetching out of that repo won't | 16:14 |
| quicksilver | IIRC there is no way to remove orphaned revisions. | 16:14 |
| jam | quicksilver: well there is the "create a new repo and fetch" | 16:14 |
| jam | but *today* we don't have a "bzr gc" command. | 16:14 |
| jam | quicksilver: also note that after replay you'll have the same objects 2x in the repo | 16:16 |
| jam | so you'll probably want to do it in a temp repo | 16:16 |
| jam | and then create a pristine repo from that | 16:16 |
| quicksilver | you mean if I were using shared repos? | 16:16 |
| quicksilver | I'm not, at the moment, although way back at the beginning of this conversation I was trying to switch to them :) | 16:16 |
| jam | I'm not 100% sure how replay works | 16:17 |
| jam | I'm guessing it does leave the "from" revisions in the local repo | 16:17 |
| jam | again, fetching out of there won't propagate them | 16:17 |
| * quicksilver nods | 16:17 | |
| quicksilver | ok, so I have my clean repo at revision "N+1" with the altered revision not to commit that horrible file. | 16:18 |
| quicksilver | I want to bring it up to the most recent version | 16:19 |
| quicksilver | I bzr rebase <path/to/most/recent> ? | 16:19 |
| jam | quicksilver: you have reached the limit of my rebase knowledge | 16:20 |
| * quicksilver nods | 16:20 | |
| quicksilver | well I'm trying it | 16:20 |
| jam | I think you'll have to somehow say you don't want N | 16:20 |
| quicksilver | that's the part I don't get, yes :) | 16:20 |
| jam | so "bzr rebase -r N+1..-1 path/to/old/brancH" | 16:20 |
| quicksilver | I think it might be --onto | 16:20 |
| quicksilver | bzr rebase --onto N+1 path/to/most/recent | 16:21 |
| quicksilver | certainly bzr rebase /path/to/most/recent gives the familiar malloc error | 16:21 |
| quicksilver | OK I'm pretty sure that was wrong, since it's given hundreds of conflicts which are wrong | 16:23 |
| quicksilver | maybe I want to be *in* the recent branch | 16:23 |
| quicksilver | and bzr rebase relative to the fixed branch | 16:23 |
| quicksilver | maybe I just want to wait to jelmer to appear :) | 16:23 |
| salgado | jam, around? I was just wondering if there's anything else I need to do to get my fix for bug 308122 through review... | 16:28 |
| ubottu | Launchpad bug 308122 in bzr "No reliable way to show shelved changes" [Medium,In progress] https://launchpad.net/bugs/308122 | 16:28 |
| === beuno is now known as beuno-lunch | ||
| quicksilver | possiblye https://bugs.launchpad.net/bzr-rewrite/+bug/329951 is what I need | 16:41 |
| quicksilver | but that's an open wishlist :) | 16:41 |
| ubottu | Launchpad bug 329951 in bzr-rewrite "support squashing commits" [Wishlist,Triaged] | 16:41 |
| davidstrauss | I'm having trouble with bzr-svn. I need it to use a Subversion 1.5+ client, but the OS X install appears bundled to 1.4. | 16:42 |
| davidstrauss | I have Subversion 1.6 installed to my Mac. | 16:43 |
| * vila back from garage, talk about a time-off it's freezing outside :) | 16:57 | |
| maxb | quicksilver: I think the bzr-rewrite code for choosing merge base revisions is a bit dodgy when rebasing merge commits | 16:57 |
| quicksilver | maxb: I have managed to get bzr replay to do something useful | 17:02 |
| quicksilver | but only one revision at a time | 17:02 |
| quicksilver | and it throws out of memory errors | 17:02 |
| quicksilver | but they don't appear to *matter* | 17:02 |
| quicksilver | it still works. | 17:02 |
| maxb | It does not help that bzr replay is a hidden command | 17:03 |
| quicksilver | so by sitting in the "fixed" dir which has the bad commit removed | 17:04 |
| maxb | Why only one revision at a time, though? | 17:04 |
| quicksilver | I can do "bzr replay -rX.Y.Z ../newest-ver" | 17:05 |
| quicksilver | each time I do that, it brings in that actual changeset | 17:05 |
| quicksilver | but nothing older | 17:05 |
| quicksilver | so I need to do that for each value of X,Y,Z | 17:05 |
| quicksilver | still if it works, I can do that mechanically | 17:05 |
| quicksilver | I have the list of revisions. | 17:05 |
| quicksilver | however, I have a conflict because I missed one | 17:07 |
| quicksilver | I did that deliberately to check my understanding of what it was doing | 17:07 |
| quicksilver | missing one really does miss out that change | 17:07 |
| quicksilver | Yes, this actually does seem to work! | 17:08 |
| quicksilver | well let's see what happens when we get to the first merge revision though | 17:08 |
| quicksilver | that's what matters | 17:08 |
| quicksilver | maxb: hmm this may actually work. bash for loop reapplying revisions one by one. I've found another 'evil' one which is using up all my python memroy though | 17:15 |
| quicksilver | not sure why this one is evil. | 17:15 |
| quicksilver | ack repo size up to 470M again :( | 17:17 |
| quicksilver | clean branch just to check, maybe that's orphaned revisions. | 17:17 |
| quicksilver | ok, clean copy is still only 80M | 17:19 |
| quicksilver | I'll shift to useing that | 17:19 |
| quicksilver | hmm. I seem to have got to a critical point where every single replay is upsetting it, by making it thing about the large file | 17:21 |
| quicksilver | but it *is* working. | 17:21 |
| === thunderstruck is now known as gnomefreak | ||
| vila | quicksilver: someone may have merged the poisoned revision | 17:22 |
| quicksilver | vila: well the poisoned revision hasn't come back yet | 17:23 |
| quicksilver | vila: (using repository size as the proof) | 17:23 |
| vila | quicksilver: sry for the noise then, I thought you were saying it was back | 17:23 |
| quicksilver | vila: well it's coming back as an orphaned revision. | 17:24 |
| quicksilver | vila: something keeps bringing it back into .bzr/repository | 17:24 |
| quicksilver | vila: but, because it's not referenced by any version in my history, if I do a clean branch or push it vanishes. | 17:24 |
| vila | ok | 17:26 |
| quicksilver | unfortunately it makes every replay slow | 17:27 |
| quicksilver | because I have to replay each revision independently, and each replay is 'worrying' about that huge file in some way I don't understand | 17:27 |
| quicksilver | or maybe not. | 17:28 |
| quicksilver | they're going faster now. | 17:28 |
| quicksilver | Ah, but in a critical way they're not working. | 17:29 |
| quicksilver | they're not actually recognising merges as merges. | 17:29 |
| quicksilver | OK, so replay isn't the right tool. | 17:31 |
| quicksilver | so maybe rebase is | 17:32 |
| quicksilver | but I really don't understand how | 17:32 |
| vila | damnghosts | 17:46 |
| Adys | is there a command for cleaning up all the .~1~ files? | 17:47 |
| Adys | other than find and xargs rm | 17:47 |
| maxb | clean-tree | 17:47 |
| quicksilver | vila: I've established that "replay" neveer seems to replay merginess in the way I want, so it's presumably the wrong tool. | 17:47 |
| quicksilver | vila: It's possible that rebase may be the right tool | 17:48 |
| Adys | cheers | 17:48 |
| quicksilver | but I can't work out how to use it. | 17:48 |
| vila | quicksilver: I don't use it myself, let's try to ping jelmer | 17:48 |
| vila | damn he's not online | 17:49 |
| quicksilver | replay replays simple commits (no merge involved) fine | 17:50 |
| quicksilver | preserving the author, the message, etc | 17:50 |
| quicksilver | I wonder if it preserves the ID | 17:50 |
| maxb | It would be erroneous to preserve the revid | 17:51 |
| quicksilver | OK, so other merges from this branch would be broken | 17:51 |
| ronny | quicksilver: talking about bzr-svn? full roundtrip is supported by using svn revision properties and/or storing metadata in rich-root | 17:51 |
| quicksilver | or at least will need the same kind of fixing. | 17:51 |
| quicksilver | but fortnuately I don't have any of those | 17:51 |
| maxb | ronny: No, not bzr-svnhere | 17:51 |
| quicksilver | ronny: no. Just trying to use rebase to rewrite history. | 17:52 |
| ronny | ok | 17:52 |
| quicksilver | vila: I will keep an eye open for jelmer. | 17:52 |
| maxb | quicksilver: rebase won't rebase merge revisions either, at least rebase's official versions | 17:52 |
| maxb | I have a branch pending that I need to cast a final eye over and submit to jelmer | 17:52 |
| quicksilver | maxb: you mean it won't rebase them preserving their "merginess" ? | 17:52 |
| quicksilver | replay will replay them as naive diffs | 17:52 |
| quicksilver | but that doesn't solve hte problem - it means later merges will conflict all over the shop | 17:53 |
| maxb | The trunk bzr-rewrite's rebase starts by picking out a leftmost path, and only ever rebasing revisions on that path | 17:53 |
| maxb | I have no idea why anyone would want that | 17:53 |
| maxb | So I rewrote it | 17:53 |
| quicksilver | I don't actually understand the connection between what I want to do and what rebase's docs claim it is for | 17:54 |
| quicksilver | but jam + vila suggested it. | 17:54 |
| quicksilver | the docs for rebase look to describe something which simple re-pivots an existing history | 17:54 |
| jam | salgado: It looks like you've covered our requests, I'll merge it | 17:54 |
| quicksilver | which you can actually just do with back-and-forth merging | 17:54 |
| jam | I think the delay is just that it isn't always clear when someone has done work | 17:54 |
| quicksilver | although some might consider that inconvenient | 17:54 |
| quicksilver | maxb: do you understand the probelm I'm trying to solve though? | 17:54 |
| maxb | I think I do | 17:55 |
| salgado | jam, great, I can't wait to have the feature available in a release. thanks a lot! | 17:55 |
| === beuno-lunch is now known as beuno | ||
| maxb | What's the proper URL for the bzr pqm status page? | 17:59 |
| === mrevell is now known as mrevell-dinner | ||
| Peng | maxb: http://pqm.bazaar-vcs.org/ ? | 18:00 |
| maxb | wiki/BzrDevelopment links to the SSL version of that, which then triggers a SSL error since the certificate is for canonical.com | 18:00 |
| maxb | Maybe I should just edit the wiki page to point to the plain-http url? | 18:01 |
| * Peng shrugs | 18:08 | |
| Peng | I usually use the SSL version (I'm weird), but I linked to the non-SSL version because it came up first in my browser history. | 18:09 |
| Peng | maxb: ...The HTTPS version redirects to the HTTP version... | 18:10 |
| maxb | Peng: Not if your browser complains about the SSL certificate first. | 18:10 |
| Peng | maxb: Well yeah. My point was, it seems HTTP is canonical. | 18:10 |
| Peng | (No pun intended. Although it was probably a bad choice of word anyway.) | 18:11 |
| vila | maxb: but if you accept and makes a security exception *then* it redirects | 18:11 |
| Peng | maxb: For whatever it's worth, editing the wiki sounds good to me. | 18:11 |
| vila | maxb: it's probably a typo in the wiki as https makes no sense here | 18:12 |
| Peng | maxb: Also, grepping my IRC logs, everybody (including core devs) uses http. | 18:13 |
| maxb | right. wiki amended. | 18:13 |
| Peng | :D | 18:14 |
| quicksilver | maxb: I think I'm going to solve it by a mixture of replay (when it's a plain revision) and careful manual merging to exact revids (when it's a merge) | 18:18 |
| quicksilver | maxb: I only have 40-odd revisions to go through | 18:18 |
| maxb | The only alternative I can think of would require some tweaks to the rebase sourcecode | 18:20 |
| quicksilver | it's quite painful when I have a major conflict though | 18:20 |
| quicksilver | (which was already resolved by the developer concerned" | 18:20 |
| quicksilver | I wish there was a way to say "give me the working tree state of this revid, without actually 'pull' ing it. | 18:21 |
| quicksilver | becauase I"m courrnetly not seeing a simple way to 'get' his conflict resolution. | 18:21 |
| quicksilver | maxb, vila: any clever suggestions? | 18:23 |
| maxb | I'd be tempted to avoid doing this manually at all costs | 18:24 |
| maxb | Perhaps trying to write some code using bzrlib if need be | 18:24 |
| maxb | I wonder if 'bzr rebase -r (revno after problem).. ../original-branch' would work out | 18:24 |
| maxb | Using --include-merges, and my branch of bzr-rewrite (lp:~maxb/bzr-rewrite/rebase-merges-properly) | 18:25 |
| quicksilver | maxb: with the working directory being the 'fixed' branch? | 18:25 |
| maxb | Indeed. | 18:26 |
| quicksilver | maxb: I've not used python in anger ever (I've dabbled, and I can read it, but that's not he same as being comfortable enough to knock up a quick bzrlib script ;) | 18:26 |
| vila | quicksilver: hmm, did you look at fastimport ? I'm not sure it has been implemented but I think their was talk about that scenario (excluding a file from history) | 18:26 |
| quicksilver | vila: I took a brief look and it seems to require writing an exporter to tweak the history. | 18:27 |
| vila | damn | 18:27 |
| maxb | Couldn't you just fast-export the revisions after the problem and fast-import them onto the fixed branch? | 18:27 |
| quicksilver | maxb: well I'm on a train now so I'm not going to try downloading your launchpad now :) | 18:27 |
| maxb | quicksilver: If you have a branch of lp:bzr-rewrite, there's only about 6 more revisions in mine | 18:28 |
| quicksilver | maxb: I don't. I'm using the 0.53 bzr-rebase from macports | 18:29 |
| vila | I think bzr-rewrite is python only so you should be able to install it from source in your $HOME/.bazaar/plugins | 18:30 |
| maxb | It's 539KB to branch, if you want | 18:30 |
| vila | maxb: ^ ? | 18:30 |
| maxb | the size of the branch, should quicksilver choose to download it | 18:31 |
| vila | maxb: sry, my question was: is it python-only ? | 18:31 |
| quicksilver | oh, that is quite small, even over 3G. | 18:33 |
| maxb | Yes, it's python-only | 18:33 |
| maxb | quicksilver: So, it would actually be more like: in a branch of the original branch: bzr rebase --always-rebase-merges -r (first revno to rebase).. ../the-fixed-branch | 18:39 |
| quicksilver | how will bzr cope with having two plugins with same name? will the one in ~/.bazaar/plugins take priority over the globally installed one? | 18:39 |
| maxb | yes | 18:40 |
| quicksilver | maxb I think I've symlinked it in; is there an easy way to confirm I have your version? | 18:45 |
| quicksilver | ah, bzr puglins -v | 18:45 |
| quicksilver | maxb: bzr: ERROR: no such option: --include-merges | 18:54 |
| quicksilver | bzr oh, always-rebase-merges? | 18:54 |
| maxb | --always-rebase-merges | 18:54 |
| quicksilver | not what you said the first time. | 18:54 |
| quicksilver | but now I'm confused; you say to run it in a branch of the original? | 18:54 |
| quicksilver | I thought I was supposed to run it in the fixed one? | 18:54 |
| quicksilver | maxb: whose numbering scheme should I use for the -r? | 18:56 |
| maxb | You should run it in a fresh branch of the original | 18:56 |
| quicksilver | ah. I'm getting trouble because the repo formats differ. | 18:57 |
| quicksilver | which is a bit of a problem because I was never able to "bzr upgrade" the original | 18:57 |
| quicksilver | that was one of the symptoms of the bug. | 18:57 |
| quicksilver | however my new fixed one has been upgraded | 18:57 |
| maxb | rebase is a little weird. It basically does a pull --overwrite of the "other branch" and then re-adds rebased forms of some revisions of the branch you ran it in on top of that | 18:57 |
| quicksilver | since at one stage I thought that might fix the problems. | 18:57 |
| quicksilver | my original branch is stuck in pack-0.92 | 18:58 |
| quicksilver | so, I need to make a pack-0.92 version of the 'fixed' one | 18:58 |
| quicksilver | how do I ask for a specific format? | 18:58 |
| * quicksilver rebranches from a branch in old format. | 19:04 | |
| === khmarbaise_ is now known as khmarbaise | ||
| === khmarbaise_ is now known as khmarbaise | ||
| rubbs | Got a friend here whose given me a problem I'm not sure how to best solve. He's looking to version a bunch of managerial documents, and only wants certain people to have access to it. I mentioned making them all wikis so they are versioned, but he said they need to be offline and some are spreedsheets. He was trying to tell me he wanted to use bzr, but I told him at best he'd have to separate all his managerial documents into a separate repo and | 20:06 |
| rubbs | He keeps wanting a per-file authorization within bzr... I don't think that possible though | 20:06 |
| rubbs | My other issue is that most of these docs will be binary... so versioning them is going to get big. | 20:07 |
| luks | bzr doesn't handle authorization at all | 20:07 |
| rubbs | I didn't think so... I also told him that due to the distributed nature once it was branched it's out of his control anyway | 20:07 |
| beuno | rubbs, I think someone was working ona plugin for that | 20:08 |
| beuno | not sure where it got | 20:08 |
| rubbs | I tried to tell him that a CMS might be better, but he said that they didn't version attached files. (I havent vetted that claim yet) | 20:09 |
| luks | well, he can use bzr to manage history of the documents | 20:09 |
| luks | but then needs some layer to make them available to users | 20:10 |
| === salgado is now known as salgado-afk | ||
| rubbs | I'm thinking of having bzr behind a CMS, | 20:11 |
| rubbs | so luks I think you got the best idea. | 20:11 |
| luks | I'm sure some existing CMS can make static documents available to users with per-file access | 20:13 |
| luks | I've never tried, but it doesn't seem as a rare problem | 20:13 |
| rubbs | yeah... I'm thinking he wants these users to have the ability to checkout old verstions too :( This is a hard one... I'm gonna keep diggin | 20:14 |
| luks | oh | 20:15 |
| luks | yeah, that would be more complicated | 20:15 |
| rubbs | yeah. I guess he's just brainstorming... so I don't know how crutial this is yet. | 20:16 |
| quicksilver | maxb: bzr rebase -r... ../fixed-branch wants a revision number relative to the 'current' branch | 20:41 |
| quicksilver | i.e. the original branch | 20:42 |
| quicksilver | oh eys, that's what you said | 20:42 |
| quicksilver | maxb: No revisions to rebase | 20:42 |
| quicksilver | it says. | 20:42 |
| quicksilver | OK, I have another approach. | 21:14 |
| quicksilver | I need to be able to accept a merge but reject all its changes | 21:15 |
| quicksilver | I'm sure I remember reading about that one day | 21:15 |
| quicksilver | ah, bzr revert . | 21:15 |
| quicksilver | YES. I think this works. | 21:18 |
| quicksilver | no, it doesn't. | 21:18 |
| quicksilver | jelmer: was looking for you earlier. Trying to find a good way to rewrite history. | 21:19 |
| quicksilver | Ah. Pebkac. | 21:24 |
| quicksilver | my solution does work. | 21:24 |
| quicksilver | It's a bit painful but it works. | 21:24 |
| quicksilver | vila, maxb, jam : I have a solution :) | 21:24 |
| mkanat | What's the best way to sync a bzr branch back to CVS? | 21:49 |
| mkanat | kiko: ping ^^^ (The above question is our primary hold up on actually switching now.) | 22:03 |
| lifeless | vila: http://junit.sourceforge.net/doc/faq/faq.htm#tests_7 | 22:06 |
| vila | lifeless: been there, seen that, not an *expected* failure only an test using assertRaises | 22:07 |
| quicksilver | ok that's odd. | 22:07 |
| MFen | how do i fix not compatible because "different rich-root support" during a merge? | 22:08 |
| quicksilver | why would a bzr merge explictly create 'OTHER' files? | 22:08 |
| quicksilver | instead of a proper conflict? | 22:08 |
| lifeless | MFen: you have to upgrade | 22:08 |
| quicksilver | side effect is if I "bzr revert ." the file gets deleted. | 22:08 |
| MFen | lifeless: is it definitely me that has to upgrade and not the other person? i thought i was recent, but i'm not positive | 22:08 |
| lifeless | quicksilver: if the files are not textually mergable | 22:08 |
| MFen | i'm at 2.0.3 | 22:08 |
| lifeless | MFen: if you are merging, and get that error, then you need to upgrade the repository that your data is stored in to a rich root capable format - e.g. 2a, the default in the 2.0 releases | 22:09 |
| MFen | lifeless: i'm not sure whether that means the other guy's remote branch, my local branch, or even the remote trunk. is there a way to inspect the version? | 22:10 |
| lifeless | bzr info | 22:10 |
| lifeless | vila: its the closest I've found so far | 22:10 |
| quicksilver | lifeless: I mean, it actually displays +N /path/to/file.OTHER when I merge | 22:10 |
| lifeless | quicksilver: then someone add file to the branch and you already have it in your branch | 22:10 |
| lifeless | they haven't edited your file, they started over | 22:11 |
| vila | lifeless: yeah, me too :-/ | 22:11 |
| MFen | lifeless: ok, bzr info -v on my local branch shows control: Meta directory format 1 | 22:11 |
| MFen | (and some other versions of stuff too) | 22:11 |
| quicksilver | lifeless: ah right. another botched merge. | 22:11 |
| lifeless | MFen: whats the top line | 22:11 |
| quicksilver | damn I need sleep. | 22:11 |
| quicksilver | will come back to this tomorrow. | 22:11 |
| MFen | Standalone tree (format: unnamed) | 22:11 |
| vila | lifeless: but from there I got the feeling that I was chasing a ghost | 22:11 |
| lifeless | MFen: bleh :P | 22:11 |
| lifeless | MFen: whats the Repository line then | 22:11 |
| MFen | repository: Packs containing knits without subtree support | 22:11 |
| lifeless | right | 22:12 |
| lifeless | so your format can't do rich roots | 22:13 |
| lifeless | whomever you are merging from can. | 22:13 |
| lifeless | this is a one-way transition | 22:13 |
| lifeless | and it occurs by default in 2.0 | 22:13 |
| MFen | lifeless: ok. i don't know what to do. i'm at 2.0.3 so whatever was supposed to occur doesn't seem to have occurred | 22:14 |
| lifeless | MFen: run 'bzr upgrade' | 22:14 |
| lifeless | it will migrate your data | 22:14 |
| MFen | lifeless: you are an enlightened gentleman. thank you. | 22:15 |
| lifeless | MFen: np :P | 22:18 |
| lifeless | vila: xfail - try this: change the <failure> to <xfail> but keep the exception type and everything else | 22:24 |
| poolie | hi vila, lifeless | 22:28 |
| lifeless | hi poolie | 22:28 |
| poolie | lifeless: of course you're welcome to use my screenshot | 22:29 |
| lifeless | \o/ | 22:29 |
| poolie | i hope it may do more stuff before your talk but no promises | 22:29 |
| poolie | if not, then i have a ~24 hour flight, that always seems good for hacking | 22:29 |
| poolie | assuming one gets a decent seat | 22:29 |
| jam | hi lifeless and poolie | 22:39 |
| poolie | hi jam | 22:40 |
| jam | poolie: so... the SilentUIFactory stuff strikes again | 22:40 |
| lifeless | hi jam | 22:40 |
| jam | running the 'unshelve --preview' stuff passes manually | 22:40 |
| jam | unless you redirect to a file | 22:40 |
| jam | then 100 test fail | 22:40 |
| poolie | jam, oh, really? | 22:41 |
| jam | lifeless: did you see my message about testr? | 22:41 |
| poolie | do you mean if the stdout of selftest is redirected? | 22:41 |
| jam | poolie: yeah, because ShelfUi now calls make_output_stream | 22:41 |
| poolie | that's quite a bug | 22:41 |
| poolie | i was hoping to do that soon after finishing the mysql cross-format-fetch bug | 22:41 |
| poolie | jam, it seems like a separate bug if the code under test can even ever be influenced by redirection of the test output | 22:42 |
| jam | well, without that, we would have hooked up the diff to write to stderr I think | 22:42 |
| jam | well, stdout | 22:42 |
| jam | and just never generated the diff | 22:42 |
| lifeless | jam: found it | 22:42 |
| jam | of course, I just ran without redirect, and 14 tests fail... | 22:42 |
| poolie | i don't really understand, but did you send mail about this already? | 22:43 |
| jam | I'm not sure why the tests would have passed before | 22:43 |
| jam | I sent main to the review list | 22:43 |
| jam | that I can't land it because tests fail | 22:43 |
| jam | but since I'm PP I figured I should try to debug it | 22:43 |
| poolie | ok i'll look in a sec | 22:43 |
| jam | of course, it *also* fails because of a mismatched lock count, which makes the test results pretty hard to read | 22:44 |
| dutchie | I tried to "bzr mv chapter6.tex maintenance.tex" but it said "bzr: ERROR: Specified file "maintenance.tex" is outside the current view: chapter6/chapter6.tex". WTF is going on? | 22:44 |
| jam | (and I can't redirect to a file :) | 22:44 |
| jam | dutchie: you have a view specified | 22:44 |
| jam | which limits what files will be effected by commands | 22:44 |
| jam | so you don't commit/etc files outside of that | 22:44 |
| dutchie | how do I un-specify it? | 22:44 |
| jam | I don't know *why* you have a view | 22:44 |
| jam | but check "bzr view" | 22:44 |
| jam | bzr view --delete --all | 22:45 |
| dutchie | ok, thanks | 22:45 |
| jam | or just | 22:45 |
| jam | bzr view --delete | 22:45 |
| jam | poolie: so if I do this: http://paste.ubuntu.com/355766/ | 22:48 |
| jam | the test suite passes | 22:49 |
| jam | basically, it is just 'delay calling make_output_stream()' until we actually try to write the diff | 22:49 |
| jam | and since 99% of the tests don't, and the ones that do already set everything up correctly | 22:49 |
| jam | it works | 22:49 |
| poolie | !! | 22:49 |
| jam | lifeless: oh, and 'testr failing' doesn't exist... :) | 22:50 |
| spiv | Good morning. | 22:50 |
| jam | poolie: right, the failure is that the default ui is Silent which doesn't support make_output_stream | 22:50 |
| jam | (especially when redirected) | 22:50 |
| jam | this avoids trying to grab an output stream at all | 22:50 |
| jam | (which is decent if it isn't going to be used) | 22:51 |
| jam | poolie: btw, I don't think 'make_output_stream' is particularly clear on who is supposed to close it. | 22:52 |
| jam | maybe I'm wrong | 22:52 |
| lifeless | jam: yeah, I'll write that one this afternoon :P | 22:52 |
| jam | lifeless: so having a "testr load -v" would be nice | 22:52 |
| jam | if it could do the progress bar stuff | 22:52 |
| lifeless | Sure | 22:55 |
| poolie | jam, so | 22:59 |
| poolie | which test is this? | 23:01 |
| poolie | jam, sorry, another call now | 23:01 |
| poolie | istm that setting that globally will just make the diffs go to selftest's stdout | 23:01 |
| poolie | which would be weird | 23:01 |
| jam | poolie: 'bzr selftest -s bt.test_shelf' with salgado's patch | 23:02 |
| jam | the code as written | 23:02 |
| jam | always calls make_output_stream in ShelfUI's constructor | 23:02 |
| jam | even if it never generates a diff | 23:02 |
| poolie | oh i see | 23:02 |
| jam | if a file isn't passed in | 23:02 |
| jam | so the tests that did care about the diff | 23:02 |
| jam | passed a file | 23:02 |
| poolie | and there are some tests that assume that if it isn't going to create a diff, they can use the default ui | 23:02 |
| poolie | i see | 23:02 |
| jam | and ones testing the behavior made sure the factory was available | 23:03 |
| poolie | ok i see | 23:04 |
| poolie | so istm that if the tests want to install a Silent factory, it should probably discard output? | 23:04 |
| poolie | that would be correct for these tests at least | 23:05 |
| jam | poolie: for code that existed before make_output_stream, I think we would have just written to stdout | 23:05 |
| mkanat | poolie: Hey, do you know of any really good ways to mirror a bzr repo back to CVS after each commit to bzr? | 23:05 |
| mkanat | poolie: That's the only thing we really need help with, right now, for Bugzilla. | 23:05 |
| jam | mkanat: you could look at a "post_branch_tip_changed" hook | 23:06 |
| mkanat | jam: Yeah, I know what hook I'd use. | 23:06 |
| jam | mkanat: then i would just have a co-located cvs repo and bzr repo | 23:06 |
| mkanat | jam: What I was hoping to find was some code that already does what I want. | 23:06 |
| jam | and the post-change hook would update & commit in a loop | 23:06 |
| mkanat | jam: That's not possible. | 23:06 |
| jam | not possible? | 23:06 |
| mkanat | jam: Well, yeah, that's what I was thinking of doing, sort of. | 23:06 |
| jam | oh, there was also a plugin a while back that provided a cvs *view* of a bazaar repository | 23:06 |
| mkanat | jam: Yeah, but that won't work, for sure. :-) | 23:06 |
| jam | so you could "cvs co :pserver:/path/to/bzr | 23:07 |
| jam | but you couldn't commit to it | 23:07 |
| mkanat | jam: I know, I wish I could just use bzrcvsserve. | 23:07 |
| jam | mkanat: trying to allow commits to cvs *and* bzr *and* have the bzr commits auto-mirrored back to cvs are going to be a real pain | 23:07 |
| mkanat | jam: There will be no commits to CVS. | 23:07 |
| jam | mkanat: then what is wrong with cvsserve ? | 23:07 |
| mkanat | jam: The path to the CVS repo can't change. | 23:08 |
| jam | mkanat: so cheat | 23:08 |
| chx | hi. bzr shelve and unshelve is very very cool but is there a way to specify my own id? would mesh with the ticketing system very well. | 23:11 |
| mkanat | Basically, I need to copy the bzr repo's contents into a CVS directory, do "cvs add" in a loop until there are no more ? outputs, then do "rm; cvs rm" for any files that don't exist in the bzr repo, and then properly mark and binary files, and then get the log message, and then commit to CVS. | 23:12 |
| chx | huh | 23:12 |
| mkanat | And I need to do it for one bzr commit at a time. | 23:12 |
| chx | hi. bzr shelve and unshelve is very very cool but is there a way to specify my own id? would mesh with the ticketing system very well. (sorryfor repea but it seems i asked in the middle of a netsplit) | 23:12 |
| lifeless | chx: no, there isn't. | 23:24 |
| lifeless | chx: I believe you can make a comment though, or description. | 23:25 |
| lifeless | or something like that | 23:25 |
| chx | yes but that's not something i can specify to bzr unshelve | 23:25 |
| chx | but i guess i can write two handy lil shell scripts that fix this | 23:25 |
| lifeless | chx: you could improve unshelve so that you could say unshelve --description bug-45 | 23:26 |
| chx | lifeless: that'd require me coding python :P | 23:26 |
| chx | lifeless: some other time :) | 23:27 |
| lifeless | its not contagious ;) | 23:27 |
| chx | no but i do not have the time | 23:27 |
| chx | last i tried it was a breeze to code python | 23:27 |
| chx | so to quote Jeff Eaton, I am Py-curious :) | 23:27 |
| lifeless | :) | 23:28 |
| MFen | nice | 23:30 |
| === pgalbraith is now known as CaptTofu | ||
| chx | yeah, last i tried (it was the first serious try really) i whipped a two way gateway in 40 min between skype and konversation.... | 23:37 |
| chx | messages travelling on d-bus :) | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!