| beuno | got a minute? | 00:00 |
|---|---|---|
| jam | beuno: adding + and - would be a prereq, I don't know if it sufficient | 00:00 |
| poolie | oh hello jam | 00:00 |
| lifeless | beuno: sure, what should I look at ? | 00:05 |
| beuno | lifeless, have the mockups for loggerhead landed in your email? | 00:06 |
| lifeless | beuno: newer ones? | 00:18 |
| beuno | lifeless, yes, a week ago, max | 00:19 |
| beuno | the diff view, specifically | 00:19 |
| lifeless | the ones via joey ? | 00:19 |
| beuno | yeao | 00:19 |
| beuno | *yeap | 00:19 |
| lifeless | yes, I have it | 00:20 |
| beuno | good, well, how does it look to you? | 00:21 |
| jml | lifeless: can I merge my loom status branch? | 00:21 |
| lifeless | I am able to tell the red and green apart | 00:21 |
| beuno | ah, yay! :) | 00:21 |
| beuno | thanks lifeless | 00:22 |
| lifeless | however, I'm only red-green colour insensitive | 00:22 |
| lifeless | there are emulators for all colourblindness types | 00:22 |
| lifeless | if you haven't, you should simply view the page view them | 00:22 |
| lifeless | *via* | 00:22 |
| beuno | yes, I'll make sure we test it with some tool (GIMP seems to have something that does that) | 00:22 |
| lifeless | but I think the reason is solely that red is left and green is right | 00:23 |
| lifeless | any change on one side is one colour in that layout | 00:23 |
| lifeless | so you could use one colour 'change from this side' | 00:23 |
| lifeless | :P | 00:23 |
| lifeless | jml: did it get the tick ? | 00:24 |
| beuno | hrm, I wonder if it would be too invasive to cross out the actual text being deleted | 00:24 |
| jml | lifeless: it hasn't got any reply yet that I've seen | 00:24 |
| lifeless | I have a queue for loom reviews | 00:25 |
| lifeless | two for aaron | 00:25 |
| lifeless | and that one needs its final pass I think | 00:25 |
| lifeless | and 2 pqm branches to me | 00:25 |
| lifeless | *merge* | 00:25 |
| jelmer | 'evening beuno, jml, lifeless | 00:27 |
| jelmer | lifeless: any news on bzr-gtk pqm and/or a shallow-branches+bzr.dev merge? | 00:27 |
| jml | jelmer: hello. | 00:27 |
| beuno | hey jelmer | 00:27 |
| jml | lifeless: that was the tick right? | 00:27 |
| lifeless | jml: I think thats what I mean | 00:28 |
| jml | :) | 00:28 |
| === mark1 is now known as markh | ||
| jelmer | lifeless: ping | 01:18 |
| lifeless | hi | 01:19 |
| jelmer | lifeless: what's the current status of shallow branches? Planned for 1.7 ? | 01:28 |
| lifeless | jelmer: 1.6 hopefull | 01:28 |
| lifeless | jelmer: igc has posted a merged copy | 01:29 |
| jelmer | lifeless: ah, I must've missed that | 01:29 |
| lifeless | 17:28 < igc> current state of merging bzr.dev into the stacked branches loom is now pushed to http://people.ubuntu.com/~ianc/bzr/shallow-branch/ | 01:29 |
| jelmer | lifeless: thanks, I'll see if I can get bzr-svn to implement it then or at least cope with the new API :-) | 01:29 |
| lifeless | jelmer: cool | 01:30 |
| lifeless | jelmer: ping me with questions | 01:31 |
| lifeless | jelmer: I'm sure there will be various | 01:31 |
| jelmer | lifeless: will do | 01:31 |
| jelmer | lifeless: also, the bzr-gtk pqm: should I keep asking you about it or would it just be easier to set up something outside of the core bzr infrastructure ? | 01:35 |
| lifeless | I will mail you today a set of questions | 01:36 |
| lifeless | then you reply and I forward to RT | 01:36 |
| jelmer | lifeless: ah, cool - thanks again :-) | 01:37 |
| lifeless | I've been meaning to make up good answers myself | 01:38 |
| lifeless | but clearly that isn't working | 01:38 |
| jelmer | ah, ok | 01:40 |
| Pieter | "bzr missing" to a launchpad url isn't really fast | 02:13 |
| jml | Pieter: the Launchpad code server is running much slower than normal at the moment. We're trying to fix it now. | 02:14 |
| Pieter | ah ok :) | 02:15 |
| lifeless | jml: have you announced this anywhere? | 02:15 |
| jml | lifeless: no. just about to. | 02:16 |
| lifeless | jml: /topic here and /launchpad is my normal first port of call | 02:16 |
| lifeless | jml: as soon as I know there is a problem | 02:16 |
| === jml changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6beta1 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | bazaar.launchpad.net running slower than usual, we're fixing it now | ||
| lifeless | (also, put it at the left, GUI clients hide the right hand edge) | 02:21 |
| === jml changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6beta1 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| thumper | igc: ping | 02:53 |
| === gotgenes_ is now known as gotgenes | ||
| igc | hi all | 03:58 |
| igc | thumper: pong | 03:58 |
| thumper | igc: quick call? | 04:11 |
| igc | thumper: sure | 04:11 |
| igc | skype is ok if you wish | 04:11 |
| lifeless | jam: still here? | 04:14 |
| lifeless | jam: why would cvsps-import hang on 'creating a dump' | 04:14 |
| lifeless | stracing the cvps process its stuck in read(), cvs is stuck in select .. | 04:15 |
| jam | lifeless: I couldn't tell you for sure, if it was up to me, I would run cvsps manually and pass cvsps-import the dumpfile | 04:30 |
| lifeless | I've found it | 04:30 |
| lifeless | write(4, "Argument gnash\n", 15) = 15 | 04:30 |
| lifeless | write(4, "rlog\n", 5) = 5 | 04:30 |
| lifeless | read(5, "E cvs rlog: Logging gnash\n", 4096) = 26 | 04:30 |
| lifeless | read(5, "E cvs [rlog aborted]: cannot stat /var/lock/cvs/sources/gnash: No such file or directory\n", 4096) = 89 | 04:30 |
| lifeless | read(5, "error \n", 4096) = 8 | 04:30 |
| lifeless | cvsps doesn't handle rlog failures | 04:31 |
| lifeless | at least the version on tungsten | 04:31 |
| lifeless | I'm going to fix the modules file and note this somewhere | 04:31 |
| lifeless | for cscvs when we get a cvs tarball it manually creates a clean cvs configuration | 04:31 |
| lifeless | I think cvsps-import needs to do the same | 04:32 |
| lifeless | jam: I have another question now though :P | 04:33 |
| lifeless | have you seen | 04:33 |
| lifeless | request for non-existent rev 1.6573 in file ChangeLog | 04:33 |
| lifeless | before ? | 04:33 |
| lifeless | there is such a version | 04:34 |
| lifeless | at least in the commit info metadata | 04:34 |
| lifeless | and in the main content too | 04:35 |
| jam | lifeless: is the content considered deleted, etc though? | 04:36 |
| jam | or is there a Attic file hiding somewhere? | 04:36 |
| lifeless | do you mean is it flagged -k ? | 04:36 |
| lifeless | this file is not in the Attic | 04:36 |
| lifeless | nor is it shadowed in the attic | 04:36 |
| lifeless | corrupt ~/.cvsps/#home#bzr_conversion#conversions#gnash#gnash-cvs#gnash file | 04:38 |
| lifeless | and here I thought cvsps was stateless; its not! hahaha cscvs sounds more and more attractive to me ;P | 04:39 |
| bob2 | haha | 04:40 |
| jam | lifeless: Well, if it had been public, and someone else had been willing to work on it, I probably wouldn't have used cvsps either | 04:40 |
| jam | this stuff was started 2-ish years ago | 04:40 |
| lifeless | I know :) | 04:40 |
| lifeless | I wasn't intending criciscm | 04:41 |
| lifeless | spiv: is there a urlutils.unescape that doesn't go to unicode? | 04:54 |
| lifeless | spiv: I really want to just unescape :P | 04:54 |
| lifeless | nvm, I'll use urllib directly | 04:55 |
| === BasicPRO is now known as BasicOSX | ||
| * igc pick up kids | 05:43 | |
| poolie | lifeless: hi, still around? | 06:43 |
| lifeless | yes the diet hasn't worked yet | 06:44 |
| poolie | heh | 06:44 |
| poolie | i'm i'm working on test_get_texts_eol_variation again | 06:44 |
| poolie | it's failing in a way i don't remember seeing last week | 06:46 |
| poolie | http://pastebin.ubuntu.com/16771/ | 06:46 |
| poolie | you don't need to work on it i think i just need a teddybear | 06:47 |
| * abentley has disconcerting visions of poolie using lifeless as a teddy bear | 06:49 | |
| poolie | hm ok maybe it's losing a line-ending therefore the serialized form is wrong | 06:49 |
| lifeless | that indicates that a full text or delta was written as | 06:54 |
| lifeless | prefix\n | 06:54 |
| lifeless | content | 06:54 |
| lifeless | suffix\n | 06:54 |
| lifeless | one likely cause is the initial bug: a basis text with an unchanged line doesn't have the \n for the internal canonical form and thus is copied across corrupting the full text at a snapshot point | 06:55 |
| poolie | right | 06:56 |
| poolie | so taking out the cleanup_eol call, as my original patch was going to do | 06:56 |
| poolie | does fix that, but causes some failures in TestKnitMerge, a bit surprisingly | 06:57 |
| poolie | maybe also due to aliasing bugs... | 06:57 |
| lifeless | what are the failures? incorrect assignment of annotations? | 06:59 |
| igc | lifeless: I need your help if you have a moment. See http://rafb.net/p/Th8E4140.html | 07:01 |
| igc | That's the source of the broken test | 07:01 |
| poolie | ah ok | 07:01 |
| poolie | it's doing an annotation-based knit and the final newline is incorrect | 07:02 |
| igc | basically get_ancestry (revision_id) was throwing NoSuchRevision and I need to do the same in your replacement code | 07:02 |
| igc | lifeless: if found_ids is the empty set, can I then raise NoSuchRevision? | 07:04 |
| lifeless | igc: thats what was coming to my mind | 07:04 |
| lifeless | igc: please be sure to commit this to the appropriate thread, not just the top of the stack :) | 07:04 |
| poolie | yay | 07:04 |
| igc | lifeless: of course | 07:04 |
| lifeless | poolie: found a matching bug elsewhere? | 07:04 |
| poolie | yep, similar bug in handling annotated content | 07:05 |
| lifeless | igc: ;) as you haven't been working with looms I'm being cautious is all | 07:05 |
| igc | lifeless: no problems. I'll try that anyhow. | 07:05 |
| igc | lifeless: no luck with that ... | 07:15 |
| lifeless | igc: what thread is this? | 07:16 |
| igc | both found_ids and result_set = frozenset(['pizza']) | 07:16 |
| lifeless | is pizza what is meant to be missing? | 07:16 |
| igc | StackableBranch | 07:16 |
| igc | yep | 07:16 |
| igc | it's the revision-id :-) | 07:16 |
| lifeless | ok | 07:16 |
| lifeless | you need to unpack that _breadth_first_searcher use | 07:17 |
| lifeless | there are two next() methods on BFS | 07:17 |
| lifeless | one returns the ids | 07:17 |
| lifeless | one checks for ghosts and returns (present, absent) | 07:17 |
| lifeless | you need to use the latter for the first step | 07:17 |
| lifeless | and then you can switch back to the former for the rest of history | 07:17 |
| igc | what's the chain(*...) about? | 07:17 |
| lifeless | pydoc itertools.chain | 07:18 |
| igc | I read that | 07:18 |
| lifeless | :) | 07:18 |
| lifeless | ok, uhm, at this point I think its easier for me to do it | 07:18 |
| poolie | update for #234748 sent if someone wants to look at it | 07:18 |
| lifeless | or at least, I can't do what I need to do know if what I've described isn't enough for you to be unblocked | 07:18 |
| lifeless | (my head is full of cotton wool - ask jml what I sounded like on the phone) | 07:19 |
| igc | lifeless: no - I'll do it | 07:19 |
| igc | you're busy enough | 07:19 |
| jml | hmm. pizza *is* missing. | 07:19 |
| lifeless | basically for the first step use the more complex api on the searcher | 07:19 |
| igc | ok | 07:19 |
| lifeless | if you get a ghost back raise | 07:19 |
| lifeless | then you can use the pithy logic for the rest | 07:20 |
| igc | ok | 07:20 |
| poolie | lifeless: would you please send your 'add_lines' patch to pqm, it looks good to me too | 07:22 |
| lifeless | poolie: I was expecting you to merge it into your branch | 07:22 |
| lifeless | poolie: because my fix wasn't necessarily good standalone foo; and they are really about the same stuff | 07:22 |
| poolie | oh ok | 07:23 |
| poolie | i can do that | 07:23 |
| lifeless | e.g. I have a hacky workaround | 07:24 |
| lifeless | the test in mine is good to have, the extra assertion is good, but the | 07:24 |
| lifeless | if thing not ending in newline give it one | 07:25 |
| lifeless | that code shouldn't have to exist | 07:25 |
| lifeless | jml: is tonight or thurs better for you ? | 07:25 |
| jml | lifeless: tonight has become impossible since I wrote the email. | 07:26 |
| lifeless | sadness | 07:26 |
| poolie | snort | 07:26 |
| poolie | (not at you) | 07:26 |
| lifeless | also, ECHANNEL, fixed | 07:27 |
| poolie | lifeless: ok i merged your change into mine | 07:40 |
| lifeless | cool, thanks | 07:41 |
| poolie | every thing passes | 07:41 |
| poolie | um | 07:41 |
| lifeless | and you removed that hacky thing of mine ? | 07:41 |
| poolie | i think the situation i was just talking about before will obviate the need for the "add a newline back in" | 07:41 |
| poolie | not yet | 07:41 |
| poolie | would like to, i agree it's gross | 07:41 |
| poolie | can you read my patch and see if you agree it will do instead? | 07:42 |
| lifeless | url? | 07:42 |
| poolie | http://bundlebuggy.aaronbentley.com/request/%3Ce01316480806032317p11b6b885n396cb037dc55c001%40mail.gmail.com%3E | 07:44 |
| lifeless | jml: latin login support for hardy: https://edge.launchpad.net/~lifeless/+archive/+builds | 07:45 |
| lifeless | poolie: your XXX: in check will spuriously conflict with my mega branch | 07:46 |
| poolie | kk | 07:46 |
| jml | lifeless: sweet. | 07:46 |
| poolie | well it should be easy to resolve :) | 07:46 |
| * jml corrects himself | 07:46 | |
| jml | lifeless: bonus! | 07:46 |
| lifeless | ridere ex | 07:47 |
| lifeless | (ewww, I know thats wrong) | 07:48 |
| lifeless | poolie: did you ring me? | 07:51 |
| poolie | nup | 07:51 |
| lifeless | poolie: the reasons are not historical, they are current | 07:59 |
| lifeless | poolie: the reason is that this layout is the internal form used on disk by knits, so its more efficient to keep it in this form during all transformations until we need to hand it to a user | 07:59 |
| lifeless | poolie: your repr is buggy; if you really want a naked except be sure to not catch KeyboardInterrupt and SystemExit, but I question wanting that at all | 08:00 |
| lifeless | poolie: finally, yes I think you should be able to remove my hack with your patch present | 08:01 |
| lifeless | though I wonder perhaps if we're unwinding a performance tweak (presumably johns, he was focused on annotate) and whether this needs verification in that sense) | 08:02 |
| poolie | lifeless: i think naked except doesn't catch them, does it? | 08:03 |
| lifeless | it catches everything | 08:03 |
| lifeless | the general rule for it is 'it is never correct to use it' | 08:03 |
| lifeless | seeing it -> red flag | 08:03 |
| jml | except when it is :) | 08:03 |
| jml | but the flag is still there. | 08:04 |
| lifeless | jml: thats why its a general rule ;P | 08:04 |
| poolie | ok, catching Exception lets it pass through but bare except does not | 08:06 |
| poolie | i thought they were the same | 08:06 |
| lifeless | I'm still unclear why you want to catch Exception | 08:07 |
| lifeless | what errors are you expecting | 08:07 |
| poolie | i want to avoid an error in repr masking the real underlying exception | 08:07 |
| spiv | poolie: There's a BaseException now | 08:07 |
| lifeless | poolie: I can't see anything that can error there | 08:08 |
| poolie | the particular case that has bitten several times is when the object is not fully initialized | 08:08 |
| poolie | for example if the transport doesn't exist or isn't working yet | 08:09 |
| lifeless | on *KnitAccess* ?! | 08:09 |
| spiv | poolie: it's new in 2.5. SystemExit and KeyboardInterrupt in particular are now based from BaseException rather than Exception | 08:09 |
| poolie | i sent a patch proposing that we should as a general pattern we should make reprs defensive | 08:09 |
| poolie | it is not about this specific case | 08:09 |
| lifeless | oh | 08:09 |
| lifeless | It smells to me. I'll need to think about it I guess | 08:09 |
| poolie | i agree that catching interrupts is bad | 08:10 |
| spiv | poolie: the other thing "except Exception:" won't catch is string exceptions. Bare except always catches everything. | 08:10 |
| poolie | it should at most be 'except Exception' | 08:10 |
| lifeless | it smells to me of bug masking | 08:11 |
| lifeless | (trying to hunt down my dislike of this concept) | 08:11 |
| jml | poolie: regarding reprs, another approach is to define a safe_repr method. | 08:12 |
| spiv | Well, bugs in __repr__ are generally unimportant bugs. We use __repr__ for debugging rather than user output (except maybe in bzrlib.errors I guess). | 08:12 |
| poolie | jml, yes, we could call that from code that might be handling broken objects... | 08:13 |
| poolie | spiv, yes, that was my reasoning; i would rather get teh real error and only a faint indication there's a problem in repr than vice versa | 08:13 |
| lifeless | spiv: not bugs in __repr__. bugs in other code, both design and simple omissions etc which don't get diagnosed and fixed as such because they are only percieved as 'makes repr print 'unprintable'' | 08:13 |
| spiv | It certainly seems like a poor tradeoff if a bug in writing to a rarely-read log file (the ~/.bzr.log) causes a more serious problem. | 08:13 |
| poolie | perhaps just catching AttributeError would be enough. | 08:13 |
| lifeless | spiv: For me, I'd rather know that something deep is wrong and have to go fix it than have a repr that hides that from me | 08:14 |
| poolie | lifeless: well, if the bugs are in the category of "an incompletely initialized object can be seen by other code" it's pretty hard to fix/avoid in python | 08:14 |
| lifeless | poolie: __init__ is relatively easy to make very robust | 08:15 |
| spiv | lifeless: well, in debugging situations you can still sometimes see half-initialised objects. | 08:15 |
| spiv | lifeless: e.g. when attaching a gdb, or looking at gc.get_objects() when looking for a memory leak. | 08:15 |
| poolie | well, those are perhaps edge cases | 08:16 |
| spiv | That said, it hasn't often happened to me. | 08:16 |
| lifeless | I haven't seen it happen ever to me | 08:16 |
| poolie | i guess we could require __init__ always create all attributes with None first before doing anything that could possibly fai | 08:16 |
| poolie | or do them on the class... | 08:16 |
| lifeless | poolie: does this happen often to you ? | 08:16 |
| poolie | a few times | 08:16 |
| gour | arch | 08:17 |
| lifeless | is it usually on code you are crafting, or when diagnosing an existing bug ? | 08:17 |
| poolie | i have to say the absence of reprs altogether annoys me more than this | 08:17 |
| gour | oops | 08:17 |
| poolie | the second | 08:17 |
| poolie | hello :) | 08:17 |
| lifeless | poolie: I think we have quite different debugging styles; this may cause you to want a smoother repr facility | 08:18 |
| poolie | possibly | 08:19 |
| lifeless | poolie: also, I'd rather than we make __init__ on objects which are fragile in this way for you be cleaner, than use naked exceptions | 08:19 |
| poolie | i'm not talking about just interactive debugging but also tracebacks and test failures | 08:19 |
| lifeless | poolie: yes thats the broad category of 'debugging styles' I was referring to | 08:19 |
| poolie | sure, if this ever trips it is in a senes a bug | 08:20 |
| awilkins | I have some code that enhances the default traceback which I keep meaning to tidy up and submit | 08:20 |
| poolie | however, i'm concerned with catching information on first failure as much as possible | 08:20 |
| poolie | therefore catching the most important error | 08:20 |
| poolie | which is not really that __init__ has an impossible-to-totally-avoid bug | 08:20 |
| lifeless | well | 08:21 |
| poolie | s/really/usually | 08:21 |
| lifeless | I think there are other approaches to do that | 08:21 |
| lifeless | an object graph walk for instance will gather much more data | 08:21 |
| lifeless | and can be made much more robust in general | 08:21 |
| lifeless | as well as not requiring scatterings of partial-object-dump code in every class | 08:22 |
| poolie | walking the whole dir() of the classes? | 08:22 |
| jml | objgrep ftw! | 08:23 |
| lifeless | (your _KnitAccess repr is IMO hiding import data about its internals such as _need_to_create), and I often find that repr() functions bitrot, which is one reason I rarely add them - I can't depend on them so I don't | 08:23 |
| lifeless | poolie: e.g. pickle to a text backend | 08:24 |
| spiv | Except that pickle isn't exactly robust. | 08:24 |
| lifeless | which can be human read | 08:24 |
| lifeless | spiv: 'e.g.' | 08:24 |
| spiv | lifeless: sure, but solutions that are theoretical are less helpful than concrete ones :) | 08:25 |
| lifeless | spiv: well, concretely - walk the __dict__ | 08:26 |
| spiv | (pickle in particular is even more sensitive to the exact unexpected-object-state problem than repr) | 08:26 |
| jamesh | spiv: you could always post process the pickle into XML | 08:26 |
| jamesh | oh wait, this isn't #zope | 08:26 |
| poolie | ok this is definitely a difference in debugging style | 08:26 |
| poolie | i am looknig for a hint as to what it is,not the whole details | 08:26 |
| poolie | mwh i think just complained that one of them was very big | 08:27 |
| lifeless | Inventory specifically I believe | 08:27 |
| lifeless | it prints its content | 08:27 |
| lifeless | (which I find useful if I am going to poke at an inventory) | 08:27 |
| spiv | lifeless: it sounds like you're suggesting an alternative to gathering simple tracebacks. I don't think that's what poolie is talking about; he's happy with simple tracebacks, he just wants to make sure that generating them doesn't occasionally fall over and lose the original error. | 08:28 |
| poolie | not so good if someone gets a traceback contaninig one on a real tree | 08:28 |
| lifeless | poolie: I would argue its quite useful actually, it has enough to reconstruct most if not all of the inventory here and check it for consistency | 08:29 |
| lifeless | not that we've written a parser | 08:29 |
| spiv | Having richer debug tools than tracebacks could be useful, but I think is solving a different problem. | 08:29 |
| lifeless | spiv: sure, but it comes back to debugging style I think | 08:29 |
| poolie | "what poolie is talking about" <-- correct | 08:30 |
| lifeless | so I get that that is what poolie is talking about :) | 08:30 |
| poolie | anyhow... | 08:30 |
| poolie | i agree the bare except is too strong | 08:30 |
| lifeless | and I've already put my vote in which is that I would rather we fix those bugs than add 4 lines of hand holding to every single repr; and if we're going to have repr's as a policy thing, not an occasionally useful thing, thats a whole lotta code | 08:31 |
| gour | nix | 08:31 |
| poolie | any other comments on the meet of that patch? | 08:32 |
| poolie | meat* | 08:32 |
| * gour has problem switching buffers today | 08:32 | |
| lifeless | poolie: other than what I've raised I think its good | 08:32 |
| poolie | ok so | 08:33 |
| poolie | 1- correct comment about 'historical reasons' | 08:33 |
| lifeless | 2- check with John about performance with this applied | 08:34 |
| lifeless | 3-repr mumble mumble mumble | 08:35 |
| poolie | i'll take out the except; i'll leave the repr if that's ok with you | 08:35 |
| lifeless | thats fine | 08:35 |
| lifeless | thank you | 08:35 |
| === gour is now known as gour|afk | ||
| lifeless | ugh | 08:36 |
| lifeless | so one way in which check is slow | 08:36 |
| lifeless | is that it appears to check every text weave twice | 08:36 |
| poolie | i think so | 08:37 |
| lifeless | not your XXX: | 08:37 |
| lifeless | your XXX: refers to w.check() and for thing in w: | 08:37 |
| lifeless | there are two code sites calling w.check() | 08:37 |
| poolie | oh well at least twice then | 08:38 |
| lifeless | so there is w.check(), w.check() and for thing in w: | 08:38 |
| lifeless | I think your XXX: is flawed because w.check() and for thing in w: can be different statements of correctness. | 08:38 |
| lifeless | indeed, confirmed | 08:40 |
| poolie | i didn't mean strictly redundant | 08:40 |
| poolie | perhaps that is unclear | 08:40 |
| lifeless | it is | 08:40 |
| lifeless | also the code doesn't exist anymore here :) not in such a form anyhow | 08:40 |
| poolie | there is a lot of overlap but not complete overlap | 08:40 |
| poolie | otherwise i would have killed it already | 08:41 |
| lifeless | check_one_rev also checks the revision tree | 08:41 |
| lifeless | and the file text scan does that too | 08:41 |
| lifeless | which is overlap | 08:41 |
| lifeless | I'll be happy to give that comment a new home | 08:45 |
| lifeless | if you want to make it a bit clearer that would help | 08:45 |
| lifeless | hmm, interesting | 08:46 |
| poolie | tbh the only thing i am confident in is that check could be faster | 08:46 |
| lifeless | I get 10 inconsistent parents for a test that wants 9 :P | 08:46 |
| lifeless | :) | 08:46 |
| lifeless | FWIW that comment is in the class of comments I don't make; because folk wanting random things to do go to the bugtracker, and folk optimising generally start with a profile :) | 08:47 |
| lifeless | (But I don't object to them existing, just explaining why I tend not to make them) | 08:47 |
| poolie | ok | 08:48 |
| igc | lifeless, poolie, jml: rev 3250 of http://people.ubuntu.com/~ianc/bzr/shallow-branch/ now passes all tests | 08:49 |
| lifeless | igc: thanks!. the next thing for that loom is to start peeling off threads from the bottom and updating them with review comments and merging | 08:50 |
| igc | I guess the next step is to break it up into different bits for review? | 08:50 |
| lifeless | igc: it comes pre-broken :) | 08:50 |
| igc | true | 08:50 |
| igc | I think the bottom one - errors - is already merged | 08:50 |
| lifeless | igc: all the threads up to and includin external_reference_tests should be reviewed-with-comments already | 08:50 |
| igc | ah | 08:51 |
| igc | that's good | 08:51 |
| igc | I'll chase down those reviews | 08:51 |
| lifeless | note that 'revno' doesn't really apply to a loom, you need the loom's revno, which isn't currently exposed :) | 08:51 |
| lifeless | ok, that was weird: | 08:51 |
| lifeless | bzr pull http://people.ubuntu.com/~ianc/bzr/shallow-branch/ | 08:51 |
| lifeless | http://people.ubuntu.com/%7Eianc/bzr/shallow-branch is permanently redirected to http://people.ubuntu.com/~ianc/bzr/shallow-branch/ | 08:51 |
| lifeless | note the / -> no / -> / | 08:52 |
| igc | lifeless: have you already applied the reviewed comments for those early threads? | 08:53 |
| lifeless | igc: I don't believe so | 08:53 |
| lifeless | igc: I was already context switched | 08:53 |
| igc | lifeless: so I'm happy to do that but ... | 08:54 |
| igc | I'll then assume someone else - beyond you and I - will review the result | 08:54 |
| igc | (I'm concerned about reviewing my own tweaks to your code if that makes sense) | 08:54 |
| lifeless | if you did the original review I think its fine for me to ack the actual changes made | 08:55 |
| lifeless | it does - bounce them to me for +1 | 08:55 |
| igc | lifeless: so to confirm, I'll do a review of each thread and make the tweaks requested so far and my own | 08:56 |
| igc | lifeless: you'll then approve the final result | 08:57 |
| igc | i.e. review | 08:57 |
| igc | and merge to bzr.dev | 08:57 |
| lifeless | I'll approve, I'm happy for you to do the merges | 08:57 |
| igc | :-) | 08:57 |
| lifeless | the less I do until I finish the weave_store removal the better; I'm a single point of effort at the moment | 08:58 |
| igc | np - I agree | 08:58 |
| lifeless | check seems happy now (though I'm sure I have some tests to update :P) | 08:59 |
| * igc dinner | 09:00 | |
| lifeless | spiv: one reason knit reconcile is slow | 09:08 |
| lifeless | spiv: it does list_dir() of the knits tree on every loop | 09:08 |
| spiv | lifeless: ouch | 09:08 |
| lifeless | len(weave_store) -> much IO | 09:08 |
| lifeless | Its the general side effect of len being unclear about implications | 09:09 |
| lifeless | don't worry, I'm deleting the code :P | 09:09 |
| spiv | Deleting code is a wonderful thing. | 09:10 |
| * spiv heads off for a swim | 09:10 | |
| kumi_ | Hello. I upgraded to 1.5 and bzr+ssh is broken. I keep getting "The server's host key is not cached in the registry": http://pastebin.com/d52c7ea5b | 09:25 |
| kumi_ | Where _is_ the registry? :) | 09:26 |
| lifeless | on linux, ~/.ssh/host_keys I think | 09:28 |
| kumi_ | here's the Python traceback in case it's relevant: http://pastebin.com/d17386e | 09:28 |
| lifeless | 'registry' is a bit of a vague term, unless its referring to windows, where it may well be in the registry somewhere ( the registry is a windows configuration database) | 09:29 |
| kumi_ | I don't see anything in the actual Windows registry | 09:29 |
| kumi_ | the install log didn't say it was doing anything in there anyways | 09:29 |
| kumi_ | In the previous version I was using, the host keys were in C:\Documents and Settings\user\Application Data\bazaar\2.0\ssh_host_keys | 09:30 |
| lifeless | I'm afraid I don't know enough about windows ssh stuff these days to help you much :( | 09:31 |
| lifeless | is it possible the server's host key changed after the recent ssl issue on debian machines? | 09:31 |
| kumi_ | nope | 09:32 |
| lifeless | igc: errors is indeed merged - you can tell because diff -r thread: -> empty | 09:32 |
| kumi_ | in the previous version, bzr gave a nice informative error if the key was missing from ssh_host_keys. It told you to "try editing c:\document settings\etc" | 09:33 |
| kumi_ | this is rather cryptic | 09:33 |
| lifeless | please do file a bug | 09:33 |
| lifeless | I completely agree | 09:33 |
| kumi_ | OK :) | 09:33 |
| igc | lifeless: does that mean I can switch to that thread (errors) and simply 'bzr combine-thread'? | 09:34 |
| lifeless | yes | 09:34 |
| igc | lifeless: Can I then just 'bzr record' or should merge up and record at the top? | 09:35 |
| igc | (still trying to work out exactly when record is required) | 09:36 |
| lifeless | igc: you record before you push | 09:36 |
| lifeless | igc: probably in this case you would do a whole bunch of work and changes ;) | 09:37 |
| igc | lifeless: thanks. record-before-push is easy to remember :-) | 09:38 |
| * igc really heads to dinner now | 09:38 | |
| kumi_ | bug filed https://bugs.launchpad.net/bzr/+bug/237297 | 09:55 |
| ubottu | Launchpad bug 237297 in bzr "Win32: The server's host key is not cached in the registry" [Undecided,New] | 09:55 |
| lifeless | thanks | 09:55 |
| lifeless | well I'm signing off | 09:55 |
| kumi_ | have a good one | 09:55 |
| lifeless | currently working on fetch using the new apis | 09:55 |
| === gour|afk is now known as gour | ||
| === cprov is now known as cprov-lunch | ||
| === thekorn_ is now known as thekorn | ||
| siretart | james_w: woah, `bzr bd --merge svn+ssh://svn.debian.org/svn/pkg-multimedia/unstable/ffmpeg/debian` is working now. that's what I call cool! :-) | 12:42 |
| james_w | siretart: yeah! | 12:43 |
| james_w | siretart: do you need --merge? | 12:43 |
| siretart | yes, I do need --merge. but most probably because svn:mergeWithUpstream is not set on svn+ssh://svn.debian.org/svn/pkg-multimedia/unstable/ffmpeg/debian | 12:43 |
| james_w | ah, ok. | 12:44 |
| siretart | james_w: btw, I just uploaded 0.95 to unstable | 12:44 |
| james_w | thanks :-)# | 12:44 |
| siretart | sorry that I missed your mail that time on the mailing list. I really should have uploaded it faster | 12:45 |
| james_w | no problem. | 12:45 |
| siretart | that's just too cool! :) - will save me tons of time in the debian games team | 12:45 |
| === gour is now known as gour|lunch | ||
| === gour|lunch is now known as gour | ||
| awilkins | Gah, this doesn't make sense : I "bzr send"ed a bundle from my work desktop to home | 14:46 |
| gour | ohh no, svn-1.5rc9...what the hell are they doing with 1.5 release | 14:55 |
| * gour is eager to see svn-1.5 to avoid patching old one for bzr-svn | 14:56 | |
| TFKyle | gour: you could use one of the rc's or the svn svn :) | 15:03 |
| gour | TFKyle: lazy | 15:04 |
| gour | rc8 was supposed to be last one | 15:04 |
| pickscrape | rc1 was supposed to be the last one :) | 15:05 |
| gour | btw, bzr-gtk-0.95 was not released? | 15:05 |
| awilkins | Ok ; I committed a revision to a branch which is now one revision ahead of it's sibling ; I bundled that revision but it refuses to merge with the one-less-revision sibling | 15:05 |
| awilkins | It says "bzr: ERROR: Revision {('adrian.wilkins@gmail.com-20080604133624-ybwe2ll9qc0x3vyt',)} not present in "<bzrlib.knit.KnitGraphIndex" ... but the revid it's quoting is the tip revision from the bundle.... | 15:06 |
| awilkins | The bundle correctly marks the parent revision as the same revid as the tip of the target... what's wrong ?? | 15:08 |
| gour | pickscrape: something wrong with their workflow? maybe they should change VCS | 15:08 |
| gour | awilkins: have you checked bugs at LP? | 15:11 |
| james_w | awilkins: there is a bug that gives that error message | 15:15 |
| james_w | it's to do with mixing knit and pack repos IIRC | 15:15 |
| awilkins | james_w: They are both rich-root-pack | 15:17 |
| james_w | probably not that then | 15:17 |
| awilkins | These are branches which are usually bound to my USB thumb | 15:17 |
| james_w | can you reproduce with two dummy branches? | 15:17 |
| * awilkins has a go | 15:17 | |
| awilkins | They are identical apart from this last revision | 15:17 |
| awilkins | (well, should be) | 15:18 |
| james_w | https://bugs.edge.launchpad.net/bzr/+bug/177874 | 15:18 |
| ubottu | Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Critical,Fix committed] | 15:18 |
| james_w | that's the one that I was referring to. | 15:18 |
| awilkins | They started rich-root-pack because they are bzr-svn branches | 15:18 |
| awilkins | Yup, reproducible, but I'm fairly sure the use case should work | 15:21 |
| awilkins | I'm being *slightly* unorthodox with the way I'm constructing my bundle | 15:22 |
| awilkins | Possible | 15:22 |
| james_w | what's the command line you used for send? | 15:22 |
| awilkins | bzr send . -r -2.. --mail-to me@me.com | 15:23 |
| james_w | yeah, I think that's going to cause you trouble | 15:23 |
| james_w | using "." for submit branch is probably the cause | 15:24 |
| james_w | and I'm scared by "-r" to send as I know that it can often lead you to believe you are doing something that you aren't | 15:24 |
| james_w | bzr branch . ../xxx -r -2 | 15:25 |
| james_w | bzr send ../xxx --mail-to me@me.com | 15:25 |
| james_w | will probably get you the bundle that you want. | 15:25 |
| awilkins | I'm going to do it and run the bundles through diff to see what changes | 15:25 |
| awilkins | I still think mine should work.... saying "I don't have that revision" is true... BECAUSE IT's the frickin revision I want you to pulll..... | 15:26 |
| awilkins | :-) | 15:26 |
| jelmer | gour, the next version of bzr-svn will hopefully come with its own bindings for subversion | 15:30 |
| jelmer | awilkins: I started working on a branch of bzr-svn that uses C bindings rather than pyrex ones | 15:31 |
| awilkins | jelmer: Yipe | 15:31 |
| awilkins | jelmer: Are they any easier? | 15:31 |
| jelmer | yep, the bindings themselve are done now | 15:32 |
| jelmer | Now working on fixing the remaining bugs | 15:33 |
| awilkins | Oooh... bugs in the bindings, or the Python? | 15:33 |
| awilkins | And do they work for 1.46? | 15:33 |
| awilkins | james_w: That bundle differs by timstamp, target_branch and a large chunk of base64 | 15:33 |
| jelmer | bugs in the bindings | 15:34 |
| jelmer | yes, they work with 1.4.6 out of the box | 15:34 |
| awilkins | Groovy ; let me know when you have a public branch and I'll test them on Win32 for you | 15:34 |
| jelmer | wil do, thanks | 15:35 |
| gour | jelmer: great news! depending on svn is...well.. | 15:35 |
| james_w | awilkins: the base64 is the revision data, is the change addition of lots of it in the new version? | 15:35 |
| jelmer | gour, there will still be a dependency on svn itself, just not on a particular version of its python bindings | 15:35 |
| gour | right, that's what i meant | 15:36 |
| awilkins | james_w: Yes, the block is substantially longer | 15:36 |
| james_w | awilkins: it probably means that there is actually some revision data in it now, does it work if you pull/merge it now? | 15:36 |
| awilkins | james_w: Yes, it pulls perfectly as I would have expected | 15:36 |
| gour | jelmer: any eta? | 15:37 |
| awilkins | james_w: I have another case to test... | 15:37 |
| jelmer | gour: I suspect a couple of weeks | 15:37 |
| james_w | awilkins: do you understand the difference in changing the target branch? | 15:38 |
| gour | jelmer: around 1.6 ;) | 15:38 |
| awilkins | james_w: It doesn't feel intuitive to me that it would behave differently just because I specified the local branch as the submit branch | 15:40 |
| awilkins | james_w: I can understand the mechanics of what is happening but not the difference in behaviour. | 15:40 |
| james_w | awilkins: the submit branch is the branch you intend it to be merged in to, by giving it a branch that already has the revision it decides that there are no revisions to send. | 15:41 |
| === cprov-lunch is now known as cprov | ||
| vila | abentley: Tryibg to trick again ? :) What is your current bzrtools HEAD: http://code.aaronbentley.com/bzr/bzrrepo/bzrtools/ or http://bazaar.launchpad.net/~abentley/bzrtools/bzrtools.dev/ ? | 15:43 |
| awilkins | james_w: I suppose what I want is a a way to state "the target is this branch, but at -r -2" | 15:43 |
| vila | abentley: ghaa, forget the first question, look only at the second :) | 15:44 |
| abentley | http://bazaar.launchpad.net/~abentley/bzrtools/bzrtools.dev/ | 15:44 |
| vila | abentley: good, thanks | 15:44 |
| james_w | awilkins: I think that is reasonable. I don't know if it's currently possible, and if not whether we would want to make it possible. | 15:45 |
| awilkins | james_w: I'm used to that sort of thing from SVN merges (which obviously don't have local repositories) where you can always quote a particilar revision in any given location URI | 15:45 |
| awilkins | james_w: Which is why I'm being audacious enough to try it here, I suppose :_) | 15:46 |
| awilkins | I suppose, actually, that would enable it (and probably some other uses) ; being able to specify revision as part of location | 15:47 |
| awilkins | But it also makes certain things scarier because of the "local namespace for revision identifiers" paradigm that Bazaar has in contrast to centralised systems | 15:48 |
| visik7 | why bzr-svn RevNo ar different from revision number of svn | 16:48 |
| visik7 | ? | 16:48 |
| jelmer | visik7: bzr revno's are branch-specific, svn revno's are repository-specific | 16:49 |
| pickscrape | Could someone explain what is meant by the server-side hooks that 1.4 provided initial code for? | 16:49 |
| visik7 | I dunno what it means but ok | 16:49 |
| pickscrape | i.e. are they things like pre/post-commit etc? | 16:50 |
| jam | pickscrape: there is only really 1, which is a post-changed-branch-tip | 16:50 |
| jam | which should fire for push/pull/update/commit | 16:50 |
| jam | but it is a Post fire | 16:50 |
| jam | not a pre | 16:50 |
| pickscrape | So there's no way to (say) run a checker before the commit is allowed to take place? | 16:51 |
| pickscrape | One thing we do now (with svn/svk) is run php -l on all files affected by the commit to ensure that they all parse before the commit is allowed to take place. | 16:51 |
| jelmer | visik7: In subversion you have multiple branches in one repository | 16:52 |
| statik | awilkins: thanks for the patch on bzr-gtk bug 221414. are you planning on submitting a merge request for it? | 16:52 |
| ubottu | Launchpad bug 221414 in bzr-gtk "gcommit: unknown error "float division"" [Undecided,New] https://launchpad.net/bugs/221414 | 16:52 |
| jelmer | visik7: and the same namespace for revno is shared between the branches in that repository | 16:53 |
| jam | pickscrape: afaik, there is no way to do that server side, it isn't hard to do client side | 16:54 |
| jam | or via a bot which commits to the mainline | 16:54 |
| pickscrape | Like PQM? | 16:54 |
| jam | pickscrape: right, though you could have much simpler requirements depending on what you need | 16:54 |
| jam | certainly if people aren't using checkouts, server-side hooks don't help them either | 16:55 |
| jam | (if they are only committing locally) | 16:55 |
| pickscrape | No, that's true too. Most people will be using checkouts, but it can't be depended on. | 16:55 |
| Pieter | whooo | 16:55 |
| jam | hi Pieter | 16:55 |
| Pieter | bidirectional git<->bzr syncing | 16:55 |
| Pieter | it works! | 16:55 |
| Pieter | ;) | 16:56 |
| visik7 | jelmer: in subversion ? | 16:56 |
| pickscrape | I was thinking of writing a custom plugin for our internal use whicch would do things like that. | 16:56 |
| jam | pickscrape: that would certainly be my recommendation | 16:56 |
| jam | if you wanted, the plugin could even 'auto-update' itself | 16:56 |
| pickscrape | We're also wanting commits to mainline to fire off a continuous integration system too. I should read on up what PQM can do really. | 16:56 |
| visik7 | another thing that I've not undestood is why a pull doesn't work after bzr branch of an svn repo | 16:56 |
| jam | pickscrape: well, the post-branch-tip-changed hook can be set up to fire a CI without much difficulty (I assume) | 16:57 |
| jam | PQM is meant as a "before this gets integrated" not a "check after the fact" | 16:57 |
| jam | perhaps subtle, but means that bzr.dev *always* has all tests passing | 16:57 |
| pickscrape | jam: I was hoping to be able to use the plugin manager plugin that has been talked about recently to handle keeping the plugin up to date | 16:57 |
| jam | (at least on the PQM platform) | 16:57 |
| pickscrape | jam: Ah, I see... | 16:58 |
| jam | pickscrape: you probably could, but I think that means users need to run "bzr update-my-plugins" rather than having it "forced" on them by your plugin | 16:58 |
| jam | or maybe... encouraged :) | 16:58 |
| jelmer | visik7: yes | 16:58 |
| pickscrape | Maybe our plugin could auto-update all of their plugins for them :) | 16:58 |
| jam | pickscrape: certainly | 16:59 |
| jam | If you had it check every 1hr/1day or so, it wouldn't even really get in the way | 16:59 |
| pickscrape | Yeah | 16:59 |
| === kiko is now known as kiko-fud | ||
| j^ | is there a way to setup a shared repository that does not require shell accounts? sftp and bzr+ssh depend on that as far as i can see | 17:57 |
| james_w | j^: hi, you can serve your branches over plain http | 18:02 |
| james_w | if you want to give write access then ssh access is the easiest, but you can do it over http as well. | 18:02 |
| j^ | james_w, if i want someone to push changes? | 18:02 |
| j^ | ssh is easy, i just dont feel comfortable to give full shell access just for bzr | 18:04 |
| james_w | is it an open source project? | 18:05 |
| j^ | not right no | 18:06 |
| j^ | w | 18:06 |
| j^ | otherwise i would just make read only public | 18:07 |
| j^ | just thought there might be something as easy as setting up svn via https and htpasswd | 18:08 |
| james_w | http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#serving-bazaar-with-fastcgi | 18:08 |
| j^ | thats read only? | 18:12 |
| james_w | no, that should allow read-write | 18:17 |
| === strk is now known as strk_off | ||
| j^ | just that the guide says "you want to provide read-only ..." will give it a go | 18:18 |
| j^ | or look at ssh > 4.8 with chroot sftp support | 18:19 |
| james_w | 8.4.5.1 Pushing over bzr+http:// | 18:26 |
| jam | j^: or you could set up the 'authorized_keys' file so that only 'bzr' can be run | 18:27 |
| jam | there is a 'contrib/bzr_access' script that can expose only a chrooted bzr via ssh | 18:28 |
| jam | you basically just add a 'command=XXX' to the beginning of the authorized_keys line | 18:28 |
| Pieter | james_w, igc: I'm trying to make bzr-fast-import incremental. Sort of like the id-map, but then that it doesn't skip revisions | 18:55 |
| Pieter | Also, I want it to take the same input as bzr fast-export outputs | 18:55 |
| james_w | Pieter: great! That would be fantastic. | 18:56 |
| james_w | I thought it did already, am I missing something? | 18:56 |
| Pieter | bzr-fast-export adds a header | 18:56 |
| Pieter | that's why import can't read it | 18:56 |
| Pieter | and bzr-fast-import, if it uses the revmap thing, still expects the commits on the stream, but just skips them | 18:57 |
| Pieter | my exporter won't export them, so it can't skip them | 18:57 |
| Pieter | so I want to perhaps add a --import-marks and --export-marks to bzr-fast-import, but without changing too much code | 18:57 |
| === kiko-fud is now known as kiko | ||
| === mw is now known as mw|food | ||
| j^ | jam, do you know of a version of bzr_access that works, the one in bzr.dev will always give permission denied | 19:16 |
| j^ | since it requires a request != / while ssh will always send only / | 19:17 |
| === mw|food is now known as mw | ||
| vila | Has anyone ever tried to import a plugin from another plugin ? What are the rules ? How is the import order defined ? | 20:09 |
| Jc2k | vila: bzr-svn uses bzr-rebase in its svn-upgrade command | 20:11 |
| vila | Jc2k: thks, will have a look (I don't use bzr-svn nor bzr-rebase though :-/ ) | 20:12 |
| jelmer | vila, you can simply import "bzrlib.plugins.otherplugin" | 20:13 |
| vila | jelmer: simply... yes... why not ? :-) | 20:14 |
| vila | jelmer: thks | 20:14 |
| Pieter | james_w: I'd like to extract the import/export mark code | 20:16 |
| Pieter | eh | 20:17 |
| Pieter | nvm | 20:17 |
| === kiko is now known as kiko-afk | ||
| jelmer | is there some way to upgrade a read lock to a write lock? | 20:25 |
| jelmer | I need to modify the source branch from a push hook | 20:25 |
| === gour_ is now known as gour | ||
| yacc | Hmm, how can I add a file to .bzrignore "dynamically" inside a plugin. | 20:28 |
| pickscrape | I'd look at the ignore command code for that | 20:33 |
| beuno | yacc, well, you could *just* append to the file | 20:34 |
| pickscrape | One problem I noticed with the ignore command, was that if you ignore something you've already ignored, it appends anyway. | 20:35 |
| beuno | pickscrape, that sounds like a bug | 20:37 |
| pickscrape | Something else that worries me is that bzr doesn't seem to mind if you push over a shared repository | 20:38 |
| james_w | hi beuno | 20:38 |
| beuno | howdy james_w | 20:38 |
| james_w | yacc: when I had to do this appended a line to the file. It would be great if bzrlib had a better API for this. | 20:38 |
| yacc | beuno, yeah, but that would get commited, right? | 20:38 |
| beuno | yacc, it would get committed anyway | 20:39 |
| yacc | james_w, I don't want the fact that these files get ignored to get recorded. | 20:39 |
| beuno | well, ignore .bzrignore :) | 20:39 |
| james_w | yacc: ah, you just want it while the plugin is doing its thang? | 20:39 |
| yacc | james_w, exactly. | 20:39 |
| beuno | pickscrape, could you report the bug about a file getting added even though it's already being ignored? | 20:40 |
| james_w | yacc: I think there is something in bzrlib for that. | 20:40 |
| pickscrape | Certainly | 20:40 |
| beuno | yacc, interesting use case :) | 20:40 |
| james_w | yacc: add_default_ignore() or something similar. | 20:40 |
| yacc | james_w, any hints for google keywords? | 20:40 |
| james_w | yacc: I think grep would be more successful, but I may be wrong. | 20:41 |
| yacc | james_w, probably right. | 20:41 |
| james_w | yacc: add_runtime_ignores | 20:41 |
| james_w | bzrlib/ignores.py | 20:43 |
| yacc | beuno, you don't want to know what the use case is ;) | 20:44 |
| ja1 | j^: hm... I had used it before merging, it seems something funny is happening here | 20:44 |
| ja1 | j^: I would probably simplify it a lot, since (as you say) path is always '/' | 20:45 |
| === ja1 is now known as jam | ||
| newz2000 | I'm having a problem committing because of a problem with gpg but I can only reproduce it while using bzr http://pastebin.com/d3479c44e | 20:45 |
| newz2000 | anyone have a suggestiong that will allow me to commit? | 20:46 |
| j^ | jam, removing the check for path != "/" and join (base, path) it works now but yes it could be further reduced and the sample should make clear that one can not provide permissions for paths but just for / | 20:46 |
| jam | newz2000: you could disable requiring a gpg signature :) | 20:46 |
| newz2000 | :-) | 20:46 |
| newz2000 | Anything else | 20:46 |
| jam | newz2000: for starters, you are using the wrong value | 20:46 |
| jam | you want to have "create_signatures = always" in ~/.bazaar/bazaar.conf | 20:46 |
| jam | second, can you paste the traceback in ~/.bzr.log? | 20:47 |
| jam | j^: patches welcome, it is, after all, a 'contrib' item :) | 20:47 |
| jam | Seriously, I'm happy to merge fixes for it, I just don't have time right now to work on it | 20:47 |
| newz2000 | jam: bzr: ERROR: Invalid signatures policy 'always' | 20:48 |
| yacc | james_w, the Wiki page is not uptodate, any docs on how currently hooks work? | 20:48 |
| j^ | jam, ok will look into it later this week, will ping you if i come up with a patch | 20:48 |
| james_w | yacc: I'm not familiar with hooks, sorry. | 20:48 |
| jam | newz2000: really? | 20:49 |
| jam | check_signatures = require | 20:49 |
| jam | create_signatures = always | 20:49 |
| yacc | james_w, no problem, I noticed that bzrlib is installed unpacked, so I'll go and read the quality docs :) | 20:49 |
| jam | is what I have | 20:49 |
| newz2000 | oh, right, subtle diff | 20:49 |
| jam | and you want to get rid of your check_signatures entry maybe | 20:50 |
| jam | newz2000: yeah, older versions of bzr had the logic backwards, 'check_signatures' enabled signing for some odd reason | 20:50 |
| jam | what *seems* to be happening is that 'gnome-gpg' is returning non zero even if the signature worked | 20:51 |
| jam | possibly because of the agent issue | 20:51 |
| newz2000 | http://pastebin.com/d51909c30 | 20:51 |
| newz2000 | I tried with just gpg instead of gnome-gpg too, same results | 20:51 |
| jam | newz2000: what happens if you do 'gpg --cl' manually? | 20:51 |
| pickscrape | beuno: bug 237438 | 20:51 |
| ubottu | Launchpad bug 237438 in bzr "ignore adds to .bzrignore even if pattern is already ignored" [Undecided,New] https://launchpad.net/bugs/237438 | 20:51 |
| newz2000 | jam it works just fine | 20:52 |
| jam | newz2000: does it give you the same warning? | 20:52 |
| newz2000 | no | 20:52 |
| jam | and what is 'gpg --cl && echo $?' | 20:52 |
| newz2000 | oh, it does give the warning | 20:52 |
| newz2000 | but it still works | 20:52 |
| jam | newz2000: so what is the 'echo $?' value? | 20:52 |
| jam | I'm guessing it is non-0 | 20:53 |
| jam | There are 2 "fixes" | 20:53 |
| jam | get your agent to work | 20:53 |
| jam | or edit gpg.conf to not expect an agent | 20:53 |
| beuno | pickscrape, you rock, thanks! | 20:53 |
| newz2000 | I don't see the result of echo $? | 20:53 |
| jam | or some versions of gpg don't actually return non-zero | 20:53 |
| jam | newz2000: so do your normal "gpg --cl" type stuff, hit ^D | 20:53 |
| jam | it should spit out the signature | 20:53 |
| jam | then just type | 20:54 |
| jam | echo $? | 20:54 |
| jam | which should result in a number | 20:54 |
| newz2000 | oh | 20:54 |
| newz2000 | 2 | 20:54 |
| jam | newz2000: 2 != 0 so gpg is complaining | 20:54 |
| jam | saying it didn't succeed | 20:54 |
| newz2000 | http://pastebin.com/d6cf3be6e | 20:54 |
| newz2000 | oh nice, I just pastebin'd my email address | 20:55 |
| jam | newz2000: well, it is already at https://edge.launchpad.net/~newz | 20:55 |
| jam | so it isn't like it is something new | 20:55 |
| newz2000 | true | 20:55 |
| jam | newz2000: so... take your pick. Do you want to get gpg-agent working, or change 'gpg' to not expect it | 20:56 |
| newz2000 | I think I want gpg-agent working | 20:56 |
| jam | newz2000: there is a line in ~/.gnupg/gpg.conf which says | 20:56 |
| jam | use-agent | 20:56 |
| jam | comment out that line | 20:56 |
| jam | and try again | 20:56 |
| jam | just as a first pass | 20:56 |
| jam | getting agents working is a bit more work | 20:56 |
| jam | oh, and can you give 'gpg --version' ? | 20:57 |
| newz2000 | gpg (GnuPG) 1.4.6 | 20:57 |
| newz2000 | this all started because I got mad at gnome and tried to isntall kde4. It was worse so I uninstalled all the packages it installed. Now this. | 20:57 |
| jam | newz2000: weird, because with 1.4.5 I get: | 20:58 |
| jam | http://pastebin.com/mb09cd0a | 20:58 |
| jam | which says that it failed to connect to the agent, but still returned 0 | 20:58 |
| newz2000 | that is interesting | 20:59 |
| newz2000 | I wonder why we have diff versions of gpg | 20:59 |
| newz2000 | are you using hardy? | 20:59 |
| jam | that is on a different machine | 20:59 |
| jam | actually, I think that one is FC3 | 20:59 |
| jam | cygwin has 1.4.9 | 21:00 |
| newz2000 | ok, with that commented out I can commit | 21:00 |
| jam | weird, gnome-gpg seems to think it would be using Gnome keyring | 21:01 |
| jam | according to jamesh | 21:01 |
| jam | http://blogs.gnome.org/jamesh/2006/01/12/gnome-gpg-improvement/ | 21:01 |
| jam | newz2000: if you use gnome-gpg does the commit still work, and it still allows you to save the passphrase in your keyring? | 21:01 |
| newz2000 | yes, it did use gnome-gpg in my recent commit and it did not ask me for a password meaning it cached it | 21:02 |
| newz2000 | (I have it set to remoember until I logout) | 21:02 |
| jam | newz2000: then I think your setup is complete for you | 21:03 |
| jam | you probably never ran a gpg-agent | 21:03 |
| jam | and the kde stuff tried to set it up for you | 21:03 |
| newz2000 | aaah, maybe | 21:03 |
| jam | i'm guessing, but I like the answer | 21:03 |
| newz2000 | I think it did do something like that | 21:03 |
| newz2000 | I am set, thanks a bunch jam | 21:03 |
| mpt | <http://doc.bazaar-vcs.org/latest/developers/packrepo.html> says "to check the integrity of your repositories before migrating them to knitpack format [...] run: bzr check" | 21:04 |
| Pieter | Whoo | 21:04 |
| Pieter | it works like a charm | 21:04 |
| newz2000 | ok, one more question... can I change the default push location for a branch? | 21:04 |
| mpt | But when I do "bzr check", I get "bzr: ERROR: Not a branch: "/home/mpt/hacking/lprepo/.bzr/branch/"." | 21:05 |
| beuno | newz2000, bzr push new_location --remember | 21:05 |
| newz2000 | thanks | 21:05 |
| mpt | What am I doing wrong? :-) | 21:05 |
| LarstiQ | mpt: run it from a branch, not a repo? :) | 21:05 |
| mpt | LarstiQ, I don't want to check a branch, I want to check my repository | 21:06 |
| jam | mpt: you need to do 'bzr check' in a branch, however, for *this specific* case, I would upgrade and then run check/reconcile | 21:06 |
| jam | after copying '.bzr/repository' | 21:06 |
| jam | mpt: check will check everything 'down' so you start in a branch => repo | 21:07 |
| jam | or WT => branch => repo | 21:07 |
| mpt | ahhh | 21:07 |
| mpt | jam, why do you suggest upgrading before checking in this specific case? | 21:07 |
| jam | mpt: but the pack code is much faster, and it happens that it can copy slightly bogus knit data | 21:07 |
| yacc | My first Wiki update ;) | 21:07 |
| Pieter | james_w: look at this http://pastie.textmate.org/private/jvcinnuwy76kekwp532g | 21:10 |
| Pieter | james_w: I can now commit to either bzr or git, then fetch from bzr, do what I want, and push back | 21:11 |
| Pieter | it's fully bidirectional git <-> bzr | 21:11 |
| LarstiQ | _fully_ functional? | 21:12 |
| james_w | Pieter: wow, nice work. | 21:12 |
| Pieter | LarstiQ: well, it's bit fragile, but it should do everything correctly :) | 21:13 |
| LarstiQ | Pieter: sweet | 21:14 |
| gour | Pieter: this would be useful to post to DVC list. there was recent thread about bzr vs. git | 21:17 |
| Pieter | what's dvc? | 21:17 |
| Pieter | or, what's the list? :) | 21:17 |
| yacc | A plugins __init__ should register commands on import time I guess? | 21:17 |
| gour | Pieter: starting with http://article.gmane.org/gmane.emacs.dvc.devel/2119 | 21:18 |
| mpt | thanks for your advice jam | 21:18 |
| gour | Pieter: see http://xsteve.at/prg/emacs_dvc/dvc.html | 21:18 |
| yacc | The joys of DVC, two branches without a hint which an uninterested user should pull. | 21:20 |
| LarstiQ | yacc: hmm? | 21:22 |
| yacc | http://xsteve.at/prg/emacs_dvc/dvc.html <= just after reading the page you realize that these two branches are from the two maintainers. | 21:22 |
| yacc | And I guess depending which DVC you use you might decide to use one over the other. | 21:22 |
| LarstiQ | yacc: I'd go with the one labeled as 'main branch' | 21:22 |
| yacc | LarstiQ, right ;) | 21:23 |
| * mpt is thoroughly confused | 21:32 | |
| mpt | My repository is now apparently at the new format, but if so, it happened just through a reconcile, not an upgrade, and it took less than a minute for a three-year-old repository | 21:33 |
| beuno | AFAIK, if you're using shared repos, you have to upgrade the shared repo too | 21:33 |
| * vila thinks we should optimizing bzr, that confuses even old users | 21:34 | |
| mpt | That is the shared repository | 21:34 |
| vila | grr s/should/should stop/ freudian slips in jokes now :) | 21:34 |
| beuno | vila, lol | 21:34 |
| beuno | mpt, I think you have to upgrade shared_repo/ and shared_repo/branch/ | 21:35 |
| mpt | bzr check in shared_repo/branch/ gives me a KeyError | 21:35 |
| mpt | I assume that's not supposed to happen | 21:35 |
| beuno | that doesn't happen to me | 21:36 |
| beuno | what version of bzr are you using? | 21:36 |
| mpt | 1.6b1 | 21:38 |
| mpt | http://pastebin.com/m13295f47 | 21:38 |
| beuno | hrm, I wonder if it's a problem with knits... | 21:38 |
| beuno | mpt, can you backup that dir, and upgrade shared_repo/branch? | 21:38 |
| mpt | ok | 21:39 |
| mpt | beuno, bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. | 21:39 |
| beuno | hrm | 21:40 |
| beuno | bzr info -v | 21:40 |
| beuno | shows it's at packs? | 21:40 |
| mpt | beuno, no, it returns a NoSuchRevision error | 21:43 |
| mpt | http://pastebin.com/m33af5d5 | 21:43 |
| mpt | though the traceback *does* use the phrase "KnitPack" occasionally :-] | 21:43 |
| beuno | heh | 21:45 |
| beuno | doesn't look good | 21:45 |
| beuno | jam, any ideas? :) | 21:46 |
| jam | mpt: I believe that is a known bug with check and ghosts, just reported IIRC | 21:47 |
| jam | when the mailine of your branch has a ghost in it | 21:47 |
| jam | mpt: that looks like a bzr revision id, though | 21:47 |
| jam | any ideas how it could be a ghost? | 21:48 |
| jam | ahh, wait | 21:48 |
| mpt | When I ran "bzr upgrade" on the repository, it complained about a missing revision: | 21:48 |
| mpt | starting repository conversion | 21:48 |
| mpt | bzr: ERROR: Revision {robertc@robertcollins.net-20050919044328-0205c679f3051340} not present in "KnitVersionedFile(file:///home/mpt/hacking/lprepo/.bzr/repository/text%3Atools-20050707102144-fee2fd7fd6ddfc1c)". | 21:48 |
| jam | mpt: you were using packs locally, and a knit repo on the remote, right? | 21:48 |
| jam | and you probably did a push and ^C part way through? | 21:48 |
| mpt | jam, I have a local repo and a remote repo | 21:49 |
| mpt | I have been known to ^C occasionally | 21:49 |
| jam | mpt: is one knit and one pack? | 21:49 |
| mpt | but I --overwrite afterwards | 21:49 |
| mpt | hmm, good question | 21:49 |
| * mpt checks | 21:49 | |
| jam | mpt: well, technically you should never need to, ^C should be safe. There is just a known issue if you ^C a pack => knit copy while it is coping revision texts | 21:49 |
| jam | it doesn't copy them in the correct order. | 21:49 |
| jam | mpt: you should be able to: | 21:50 |
| mpt | "Shared repository (format: dirstate or dirstate-tags or knit)" | 21:50 |
| mpt | that's the remote one | 21:50 |
| jam | bzr push -r revid:MISSING_REV_ID remote:/temp/branch | 21:50 |
| jam | it will create a branch you can then delete | 21:50 |
| jam | you are just doing it to copy the revision text across | 21:50 |
| mpt | So I guess the remote repository needs upgrading, then | 21:51 |
| jam | mpt: right, we would like you to upgrade that one, too, but you still need to copy that revision across | 21:52 |
| mpt | ok | 21:52 |
| jam | there might be a bug in the knit => knit code, but the Generic fetcher is the only part I know | 21:52 |
| mpt | another KeyError :-( | 21:53 |
| jam | mpt: from which side? | 21:55 |
| mpt | http://pastebin.com/m1cbcf532 | 21:55 |
| jam | mpt: actually, I wanted you to 'bzr push -r revid:mpt@canonical.com-20080604185556-txuu6iw2ejfs0gea' | 21:56 |
| jam | not the robertc one | 21:56 |
| mpt | oh | 21:56 |
| jam | though there is still something funny happening | 21:56 |
| jam | you might actually need to 'bzr branch -r revid:... remote: .' | 21:56 |
| jam | Looking at the last traceback it looks like it is missing locally | 21:57 |
| mpt | Exactly the same error for the mpt@canonical.com revision | 21:57 |
| pickscrape | Can someone point me at a plugin that provides a good example of how add an option to an existing command | 21:57 |
| beuno | pickscrape, xml-output | 21:58 |
| mpt | jam, should I do that bzr branch command from the top level of my local repo? | 21:58 |
| jam | mpt: as long as you are in it, it doesn't really matter | 21:58 |
| pickscrape | beuno: thanks | 21:58 |
| jam | it might be 'cleaner' to do it from the top | 21:58 |
| mpt | From the top I get "bzr: ERROR: Target directory "." already exists." :-) | 22:00 |
| * mpt does it into a temporary branch instead | 22:01 | |
| jam | mpt: sorry, I didn't mean '.' I just meant to the local area | 22:02 |
| mpt | It's thinking hard about it | 22:04 |
| pickscrape | beuno: xml-output seems to do it by subclassing the builtin command handlers. What if more than one plugin wants to extend the same command? | 22:05 |
| pickscrape | Or is it Really Really clever :) | 22:06 |
| beuno | pickscrape, well, I don't really know :) | 22:07 |
| === sdboyer_ is now known as sdboyer | ||
| beuno | moquist, bzr launchpad-login your_lp_id | 22:08 |
| beuno | and it should use bzr+ssh instead of http, which will be able to write | 22:08 |
| beuno | and, I'd recommend upgrading to the newest version of bzr, using PPA :) | 22:09 |
| moquist | beuno: thx, I'm one step further now. | 22:09 |
| moquist | beuno: hrm. OK, I'll google around a bit to see if I can figure that out. | 22:10 |
| jam | bbiab | 22:10 |
| beuno | moquist, what bit? | 22:10 |
| * beuno wonders what it would take to get a newer version of bzr into 8.04.1/2 | 22:11 | |
| moquist | beuno: I don't know how to use bzr with my PPA. | 22:12 |
| beuno | moquist, https://launchpad.net/~bzr/+archive | 22:12 |
| moquist | beuno: should I go ahead and "--use-existing-dir" to start off this branch of vpnywhere? LP seemed to want to create that dir, so I suppose this is probably expected... | 22:12 |
| beuno | moquist, yeah, add it | 22:13 |
| moquist | looks like the push worked; thanks! | 22:15 |
| beuno | moquist, :) | 22:15 |
| moquist | heh - now everyone in the whole world can read my totally lame commit comments. :p | 22:16 |
| beuno | moquist, welcome to the club :) | 22:16 |
| pickscrape | jam: if you can confirm that pushing a branch over a shared repository doesn't cause damage to the shared repository, I'll go ahead and close bug 237439 | 22:17 |
| ubottu | Launchpad bug 237439 in bzr "bzr should not allow push over shared repository" [Undecided,New] https://launchpad.net/bugs/237439 | 22:17 |
| beuno | mornin' mwhudson :) | 22:26 |
| beuno | I just tried a 36k line diff on my branch | 22:27 |
| beuno | 100mb res memory | 22:28 |
| mwhudson | nice | 22:28 |
| beuno | timing it now | 22:28 |
| beuno | but it was very CPU friendly too | 22:28 |
| mwhudson | can you try two concurrent requests? | 22:28 |
| beuno | yeap | 22:29 |
| mpt | (jam, the "bzr branch -r revid:..." is still working hard 30 minutes later) | 22:29 |
| beuno | hrm, I can't get loggerhead to work with wget/curl... :/ | 22:33 |
| beuno | mwhudson, two concurrent requests, ~160mb RES | 22:34 |
| beuno | Firefox hates me though | 22:35 |
| beuno | but that's a different issue :) | 22:35 |
| mwhudson | beuno: for wget/curl you perhaps need to remember to put the url in quotes '' | 22:35 |
| mwhudson | beuno: we'd better make it faster too then, so there are less concurrent requests :) | 22:36 |
| beuno | mwhudson, still get a 500 error, seems to not pass on URL values correctly, as it tracebacks in the kwargs arguments | 22:36 |
| mwhudson | beuno: oddness | 22:37 |
| beuno | mwhudson, well, if we're going to take on concurrent requests, then I can't see anything better than caching static HTML from what we generate :) | 22:37 |
| beuno | well, the good news is that it works with other URLs, just not the one I did for diffs | 22:38 |
| beuno | I'm not sure how to make it faster without tweaking bzrlib | 22:39 |
| mwhudson | yeah, fair enough | 22:41 |
| jam | mpt: that seems odd | 22:42 |
| beuno | mwhudson, it's about 3 secs getting the diff and processing it, and 20sec applying the template to a 36k diff | 22:42 |
| mpt | jam, strace shows it's still busy, not hung or anything | 22:43 |
| beuno | mwhudson, although we use a *lot* less memory | 22:43 |
| jam | mpt: remote is on another machine, right? | 22:43 |
| jam | otherwise I would have you break in with ^|, but that hangs up connections, too | 22:43 |
| mwhudson | beuno: i wonder if we could render the diff in a less complicated way, perhaps? | 22:44 |
| mpt | jam, yes, another machine a few km away | 22:44 |
| mwhudson | beuno: but i think we work on getting some of this stuff into trunk | 22:44 |
| beuno | mwhudson, well, if we don't use a templating engine to generate it, it should improve quite a lot, as it's just manipulating strings | 22:44 |
| mwhudson | it may not be as good as it can be, but it's still a heap better | 22:44 |
| beuno | mwhudson, ok, cool. I'll focus on cleaning up the code in order for it to be mergeable. Maybe we can set it up on a different port, and test it on edge.LP for a few days? | 22:45 |
| jam | mpt: ok, my guess is that you are running into some of the performance regressions with knits, and it just has a lot of revisions to copy | 22:45 |
| fsafdsf | is there a way to add support for webdav in bzr 1.5? | 22:45 |
| jam | you *might* want to switch to an officila release (1.3, 1.4, 1.5) for the copy and just do the same thing | 22:46 |
| jam | or just let it finish | 22:46 |
| mwhudson | beuno: there is no edge for codebrowse | 22:46 |
| mwhudson | (though that would be nice) | 22:46 |
| beuno | fsafdsf, that sounds like a question for vila, if he's still around | 22:46 |
| mwhudson | but there is staging | 22:46 |
| mpt | jam, heh, how long should I wait for the latter before I try the former? :-) | 22:46 |
| beuno | mwhudson, well, if we can point edge to a different LH port, and make *that* edge... :) | 22:46 |
| vila | beuno: stop reading above my shoulder will you | 22:46 |
| jam | mpt: well, if you do tail ".bzr/repository/revisions.kndx" and it is still processing at a ... decent rate | 22:46 |
| jam | I would stick with it | 22:46 |
| beuno | vila, :p | 22:47 |
| mwhudson | beuno: yeah, i should talk to IS about that | 22:47 |
| jam | mpt: we're trying to get rid of an "unnecessary" caching layer, but not all the code paths can get by without it | 22:47 |
| jam | so for the official releases, we restore it. | 22:47 |
| beuno | mwhudson, great, that will help us test :) back to cleaning up code then | 22:47 |
| vila | fsafdsf: I'm working on the webdav plugin at this precise minute | 22:47 |
| vila | fsafdsf: since 1.6 is around the corner it will certainly be a requirement, is that a problem ? | 22:48 |
| fsafdsf | do you have a time frame or an alternative for pushing commits to central repo hosted on a shared hosting? | 22:48 |
| mpt | jam, where is that .bzr/repository/revisions.kndx supposed to be? In the target branch directory? In the repo top level? | 22:48 |
| mpt | (it's not in either) | 22:48 |
| fsafdsf | seeing it's almost impossible to get the smart server working under a shared hosting | 22:48 |
| jam | mpt: in the repo top level | 22:49 |
| jam | mpt: ah, your local is now a pack repo? | 22:49 |
| mpt | jam, allegedly | 22:49 |
| jam | mpt: then you should have a .bzr/repository/upload/*.pack that is growing | 22:49 |
| vila | fsafdsf: please file bug reports against smart server, it *should* be widely usable and will provide far better performances | 22:49 |
| fsafdsf | then I'm obviously doing something wrong | 22:50 |
| beuno | mwhudson, do you have any strong feelings against generating the diffs without a template? | 22:50 |
| mwhudson | beuno: well, i wouldn't want to generate anything as fancy as what loggerhead currently does without a template | 22:51 |
| beuno | mwhudson, well, we could add an arbitrary limit, like we have now, and generate simple diffs when it's over X lines | 22:52 |
| vila | fsafdsf: file bugs, doc bugs if needed, mention your environment as precisely as possible, os/version/web server/python/ etc | 22:52 |
| fsafdsf | that's the thing, I doubt it's a problem on bzr's end | 22:52 |
| vila | if you can't make it work it's at least a doc bug | 22:53 |
| mpt | jam, the .pack file hasn't changed size in the past three minutes, and was apparently last modified 44 minutes ago (about 10 minutes after the branching started) | 22:53 |
| fsafdsf | most likely a serer problem, seeing DH tends to cripple fcgi scripts | 22:54 |
| mpt | jam, so downgrade and try again? | 22:54 |
| mwhudson | beuno: yeah. seems like a hack though | 22:54 |
| jam | mpt: first us ^| to interrupt and see what it is doing | 22:54 |
| mpt | jam, ok, in a debugger, now what? | 22:55 |
| jam | mpt: can you paste the traceback ? | 22:55 |
| jam | "bt" | 22:55 |
| jam | backtrace in debugger terms | 22:55 |
| beuno | mwhudson, I could run some more tests with other non-xml based templating engines | 22:55 |
| mwhudson | beuno: let's get something into trunk first :) | 22:56 |
| vila | progress ! webdav failing 49/142 tests with apache2-dav instead of 4/71 without :-) | 22:56 |
| beuno | mwhudson, yes, focus, sorry :) back to cleaning up | 22:56 |
| mpt | jam, http://pastebin.com/m668806a2 | 22:56 |
| jam | mpt: interesting... I'm guessing the ghost is confusing the search stream, otherwise it looks like it was genuinely copying data | 22:57 |
| jam | anyway, try a "c" to continue, it will likely fail | 22:57 |
| jam | then downgrade and try again | 22:57 |
| beuno | vila, btw, you owe me an email reply! bzr-upload is starting to get anxious and wants to see the light | 22:58 |
| fsafdsf | is there a recored instance of someone being able to use the smart server on a shared hosting, as far as you know? | 22:59 |
| beuno | fsafdsf, I use it through bzr+ssh on a shared hosting | 22:59 |
| vila | beuno: don't worry, bzr-upload is processed in the background :-) webdav get some love now as an experiment in plugin a real http server into the bzr test suite, from there, I'll be able to do the same with ftp/sftp servers and get a better testing env for bzr-upload | 23:00 |
| fsafdsf | mind sharing how you did it? to make sure I haven't skipped any step? | 23:00 |
| beuno | vila, :) :) :) I've got some time seperated for it too, mainly in UI stuff | 23:00 |
| beuno | fsafdsf, what steps are you following? do you have bzr working on the shared server already? | 23:01 |
| fsafdsf | indeed | 23:01 |
| fsafdsf | mostly I've been following the fcgi smart server guide on the official docs | 23:01 |
| vila | beuno: wow, you send me an email may the 24th and it appears in the bzr-upload mailbox as if received today >-/ Something really wrong is going on there, anyway, I'll reply now | 23:01 |
| beuno | vila, ah, I thought it was odd it took you so long to get back, with your kitchen all done and all :p | 23:02 |
| vila | hehe, 50 years birthday party for a friend last week-end and kitchen tiling still to be done, family life, etc ;-) | 23:03 |
| fsafdsf | I think I'm messing it up when I'm trying to adapt the steps they listed to a shared hosting environment | 23:03 |
| beuno | fsafdsf, what URL are you looking at? | 23:04 |
| fsafdsf | url of? | 23:04 |
| beuno | "steps they listed to a shared hosting environment" | 23:05 |
| fsafdsf | ah | 23:05 |
| fsafdsf | http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id73 | 23:05 |
| fsafdsf | "Serving Bazaar with FastCGI" | 23:05 |
| fsafdsf | fcgi is already enabled and working | 23:06 |
| mpt | jam, ok, trying with 1.5 | 23:06 |
| beuno | fsafdsf, ah, that's not what I've got working, I use bzr+ssh, not bzr:// | 23:06 |
| fsafdsf | I can't use bzr, seeing it invokes a daemon | 23:07 |
| fsafdsf | which isn't allowed | 23:07 |
| beuno | fsafdsf, I think spiv is the expert in that area, but he may not be awake/working yet | 23:08 |
| beuno | you may want to send an email to the list | 23:08 |
| beuno | with as much information of the problem as you can :) | 23:08 |
| fsafdsf | won't vila's webdav solution be the best solution for me? | 23:08 |
| beuno | fsafdsf, well, he should know :) | 23:09 |
| fsafdsf | seeing I'm kinda pressed for time here, and I have nothing but bad experience with mailing lists and help channels | 23:09 |
| fsafdsf | vila, do you have any idea when we can see a first working version of your plugin? | 23:10 |
| beuno | fsafdsf, well, if you have a few hours, spiv might be able to help you | 23:10 |
| Peng | fsafdsf: DreamHost supports SFTP... | 23:10 |
| fsafdsf | yes, but I can't give them all the same user/password | 23:10 |
| Peng | fsafdsf: Oh. | 23:11 |
| * Peng just came in on this conversation. | 23:11 | |
| mpt | whee, progress bars | 23:11 |
| fsafdsf | and I prefer each user to have their own u/p, similar to how I do it in SVN now | 23:11 |
| mpt | Spastic progress bars, but progress bars nonetheless | 23:11 |
| Peng | fsafdsf: Also, bzr+ssh and bzr+http usually worked for me. | 23:11 |
| Peng | fsafdsf: Procwatch only ever killed them when I was doing big things. | 23:12 |
| fsafdsf | Peng, I don't doubt it.. My bet is that I'm doing something wrong | 23:12 |
| beuno | mwhudson, I'm not really updating NEWS, should I? | 23:12 |
| Peng | I've since moved to a VPS though. No more procwatch. :) | 23:12 |
| fsafdsf | and I wanted someone to walk me through it, to see if I did something wrong | 23:12 |
| vila | fsafdsf: as soon as it works :-) Should be in some days, weeks at most | 23:12 |
| vila | fsafdsf: if you can administer your server you can use ssh keys. That's better than using u/p | 23:14 |
| vila | fsafdsf: by the way, isn't launchpad an alternative ? | 23:14 |
| fsafdsf | I can use local keys, problem is.. I'm working with Windows user and I prefer not to expose them to the private key creation process | 23:14 |
| fsafdsf | vila, it would, but then I'd need a way to push all the changes upon commit to a working, live directory | 23:15 |
| fsafdsf | and I doubt launchpad will help me with that | 23:15 |
| vila | fsafdsf: you want a remote working directory up-to-date with your bzr branch ? | 23:15 |
| fsafdsf | yes | 23:16 |
| fsafdsf | similar to how I did it with SVN's post-commit-hook | 23:16 |
| mwhudson | beuno: hm, adding a note at least would be nice | 23:17 |
| vila | fsafdsf: do you need the remote branch too or is it just a way to get the remote working dir > | 23:17 |
| vila | s/>/?/ | 23:17 |
| * vila thinks sed can be as noisy as perl | 23:17 | |
| fsafdsf | let's assume the latter | 23:18 |
| mpt | jam, alas, another error - http://pastebin.com/ma1ec204 | 23:18 |
| fsafdsf | seeing I can work on the repo locally too | 23:18 |
| jam | mpt: ;( | 23:19 |
| jam | :'( | 23:19 |
| vila | if the remote branch is not a requirement, the bzr-upload plugin may help and that would be a far simpler solution | 23:19 |
| fsafdsf | and that can be used with launchpad? | 23:19 |
| jam | mpt: that is weird, as it shows that knit => pack is rather broken... can you try using sftp:// instead of bzr+ssh? | 23:20 |
| mpt | ok | 23:20 |
| vila | the plugin will upload the working tree only, the branch can be anywhere and the repo to synchronize devs in yet another place | 23:21 |
| fsafdsf | so I'll have to tell every used to use it every time they commit? | 23:21 |
| fsafdsf | user* | 23:21 |
| vila | fsafdsf: you have to tell me a bit more about your workflow to allow me to answer that ;-) | 23:22 |
| === mw is now known as mw|brb | ||
| fsafdsf | basically, I want the bzr experience to be a similar as possible to SVN for the end users | 23:23 |
| fsafdsf | at least while they adapt to bzr's | 23:23 |
| fsafdsf | so, every user works on the same working version with possible mergers and conflict resolves if needed | 23:24 |
| fsafdsf | and again, I'll still need a way to store the central repo | 23:25 |
| vila | fsafdsf: what is your project ? | 23:25 |
| fsafdsf | simple web project, similar to a CMS | 23:25 |
| vila | ok, so bzr-upload may be relevant. Do you have a test server and a production server or just the later ? | 23:26 |
| fsafdsf | one server, a shared hosting | 23:26 |
| * beuno is off for a few hours | 23:27 | |
| vila | ok, so the simplest solution is to keep the central repo and the working tree at the same place, but it's not a *requirement* | 23:28 |
| fsafdsf | not a problem | 23:28 |
| fsafdsf | that's what I wanted anyway | 23:28 |
| vila | if you want to separate them, you can use launchpad as code hosting provider and use bzr-upload to your production server | 23:28 |
| fsafdsf | assuming I want to have them both on the same server, what can I do? | 23:29 |
| vila | now, if your workflow was: hack/test/commit/hack/test/commit it would become: hack/commit/upload/test/hack/commit/upload/test | 23:30 |
| fsafdsf | which will expose the end users to another step, one that I can skip using bzr's hooks assuming I get the smart server working | 23:31 |
| fsafdsf | or wait for your plugin | 23:31 |
| vila | if you want to have them both on the same server: bzr+shh, bzr+http, bzr+webdav in better to worse order | 23:31 |
| vila | the plugin will not help for hooks | 23:32 |
| vila | the *webdav* plugin will not help I meant | 23:32 |
| fsafdsf | the hooks depend on the smart server? | 23:32 |
| fsafdsf | even if I use that auto mirror plugin for bzr? | 23:33 |
| vila | executing hooks *on the server side* yes | 23:33 |
| vila | auto mirror ? Is that the same as push+update ? | 23:33 |
| fsafdsf | then that brings me to my original problem, how do I get the smart server to work under my server environment? | 23:33 |
| fsafdsf | "Automatically update a remote working copy upon commit. " | 23:34 |
| vila | so far, spiv is the expert :) | 23:34 |
| vila | what are the supported protocols ? | 23:34 |
| fsafdsf | one moment, launchpad seems dead | 23:35 |
| vila | the crux of the problem when updating remote working trees are the permissions bits, and that can be addressed only by a process on the remote end whatever that process is | 23:35 |
| fsafdsf | when I tried it | 23:36 |
| fsafdsf | I got this error: bzr: ERROR: Generic bzr smart protocol error: Invalid http response for http://url/project/.bzr/smart: Unknown response code 500 | 23:36 |
| vila | AFAIK push and update requires sftp, the smart server is another option, but I don't remember if updating the remote working tree | 23:36 |
| vila | 500 is internal server error, look at your logs | 23:36 |
| fsafdsf | says it tried to send an empty file, ie, without any headers and then timed out | 23:37 |
| vila | vaguely rings a bell, but it's sleep time for me, I'm afraid I won't be good at debugging that | 23:38 |
| fsafdsf | FastCGI: incomplete headers (0 bytes) received from server "/dir/.bzr-smart.fcgi" | 23:39 |
| fsafdsf | ah | 23:39 |
| vila | file a bug report on launchpad or send a mail to the list or wait for spiv to appear here are my best bets :) | 23:39 |
| fsafdsf | indeed | 23:39 |
| fsafdsf | thanks anyway | 23:39 |
| vila | you're welcome, keep us informed of your progress anyway (but may be a more recognizable nick may help ;-) | 23:40 |
| fsafdsf | my usual nick is taken here | 23:40 |
| === fsafdsf is now known as tufloc | ||
| === mw|brb is now known as mw | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!