| maxb | What is the actual format of dump-btree --raw on a .rix / | 00:12 |
|---|---|---|
| maxb | ? | 00:12 |
| spiv | maxb: in what sense? you mean where is there a description of how to parse that format? | 00:19 |
| spiv | maxb: the docstring for bzrlib.btree_index.BTreeBuilder is probably a decent reference | 00:21 |
| maxb | seems so | 00:22 |
| maxb | I'm peeking at that corrupt openobject branch | 00:22 |
| spiv | (Despite the embarrassing mistake in the definition of the _SIGNATURE part...) | 00:22 |
| maxb | There's something very dodgy in the .rix of the last pack - it contains CR bytes! | 00:22 |
| spiv | Ooh, wacky! | 00:25 |
| spiv | After decompression? | 00:25 |
| maxb | after dump-btree --raw | 00:26 |
| thumper | spiv: hi | 00:26 |
| thumper | ErrorFromSmartServer: Error received from smart server: ('error', 'Error -3 while decompressing: incorrect data check') | 00:27 |
| thumper | spiv: is there a repair thing I can use on the server side? | 00:27 |
| thumper | spiv: or are we talking restore from backup? | 00:27 |
| maxb | That sounds like the branch I was looking at :-) | 00:27 |
| thumper | maxb: maybe | 00:27 |
| thumper | maxb: more like hopefully | 00:28 |
| thumper | maxb: which branch are you looking at? | 00:28 |
| spiv | thumper: "that corrupt openobject branch" | 00:29 |
| thumper | spiv: yeah | 00:30 |
| maxb | ~openerp/openobject-addons/trunk to be precise | 00:32 |
| maxb | well that's disconcerting. | 00:34 |
| maxb | I spliced the latest pack out of pack-names, and attempted to branch a revision left in the result. | 00:34 |
| maxb | It still died | 00:34 |
| wallyworld_ | quick ? - i have a lw co of launchpad branch db-devel. bzr info says submit branch is devel, i want to change it to db-devel. i tried editing the branch.conf with submit_branch = ... but no luck. any ideas? | 00:41 |
| spiv | maxb: hmm :( | 00:43 |
| maxb | Well that's bad. The busticated content is in a GC block in the oldest largest pack file in the branch | 00:44 |
| maxb | wallyworld_: I don't usually use lw cos, but I would tend to assume that they would not even have a branch.conf | 00:45 |
| spiv | wallyworld_: did you edit the .bzr/branch/branch.conf in the checkout? That doesn't exist. It only applies to the branch. | 00:45 |
| spiv | maxb: ouch | 00:46 |
| wallyworld_ | spiv: i think i created a branch.conf file with submit_branch= in it hoping that would work | 00:52 |
| wallyworld_ | my workflow: bzr checkout --lightweight bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel db-devel | 00:54 |
| wallyworld_ | this creates a local copy which i then branch from as required: bzr branch db-devel mynewbranch | 00:55 |
| maxb | Unless your development workstation is in the launchpad datacentre, I wouldn't recommend using a lightweight checkout | 00:55 |
| wallyworld_ | what i do is create a "master" lw co and then have several sandboxes which i use bzr switch with | 00:56 |
| wallyworld_ | eg devel-sandbox. this one has the working tree | 00:56 |
| wallyworld_ | so i have separate working tree and branch directories and i reuse the working tree dir when i switch between branches | 00:57 |
| wallyworld_ | so i reduce local disk space by only having 1 or 2 full working tree directories | 00:58 |
| wallyworld_ | at least that's how i was recommended to do it when i started :-) | 00:58 |
| maxb | Oh you're doing all of this inside a shared repository aren't you | 00:59 |
| wallyworld_ | i've been mainly working with devel not db-devel but just need to get my db-devel branch to accept that i want the submit_branch to be db-devel not devel | 00:59 |
| wallyworld_ | yes | 00:59 |
| maxb | Why use --lightweight at all then? | 01:00 |
| wallyworld_ | i think i did a bzr repo-init or somwthing in my top level lp-branches dir | 01:00 |
| wallyworld_ | that's how i was recommended? :-) | 01:00 |
| wallyworld_ | the idea is to only have one or two full working trees on disk and share these amongst the branches you are working on by doing a bzr switch as required | 01:01 |
| maxb | IIUC, you can only set things like submit_branch on a branch. And a lightweight checkout is not a branch | 01:01 |
| wallyworld_ | oh, ok. so bzr info showing devel being the submit branch must be a default or somwthing | 01:02 |
| wallyworld_ | i also tried hacking the .bazaar/locations.conf file | 01:03 |
| wallyworld_ | it seems you can create config blocks for branches in there | 01:03 |
| wallyworld_ | with things like push_location:policy = appendpath etc | 01:04 |
| spiv | wallyworld_: a lightweight checkout is a reasonable thing to use | 01:10 |
| spiv | wallyworld_: but make it a checkout of a (treeless) branch you create in your local shared repo | 01:11 |
| spiv | wallyworld_: rather than of a ~launchpad-pqm branch that you can't possible 'bzr commit' directly too | 01:11 |
| spiv | wallyworld_: and then you can use the local branch's branch.conf (or create a locations.conf entry that covers that *branch*) | 01:12 |
| wallyworld_ | spiv: i have --no-trees or something set globally. so i was just pulling from the wrong place initially? | 01:12 |
| spiv | wallyworld_: the key thing here being that "submit branch", like most things, is a setting on a *branch* | 01:12 |
| spiv | wallyworld_: so a checkout doesn't have a submit branch itself, it just asks its branch for that setting, just as it asks it for the revision contents, etc. | 01:13 |
| wallyworld_ | spiv: yes. that's why i have a "master" db-devel branch locally which i then branch from as i need to | 01:13 |
| spiv | wallyworld_: that's not the workflow you described | 01:14 |
| spiv | wallyworld_: your workflow description starts with you making a local *checkout* of db-devel | 01:14 |
| wallyworld_ | seems like i messed up getting the initial local copy of db-devel then? | 01:14 |
| spiv | (A lightweight one at that!) | 01:14 |
| spiv | You want a local branch of db-devel | 01:15 |
| wallyworld_ | yeah, i've had the devel one for so long i forgot how to "seed" a new one | 01:15 |
| spiv | You can probably just go to your 'db-devel' checkout and do "bzr reconfigure --branch" | 01:16 |
| spiv | I'm not certainly this is the cause of your immediate problem, but it's likely to be related. | 01:16 |
| wallyworld_ | cool. thanks. i'll give it a go. and the branch i've already peeled off that db-devel will be ok still? | 01:16 |
| spiv | Yes. | 01:17 |
| spiv | Well, | 01:17 |
| spiv | It'll probably think it's parent branch is the one on launchpad rather than your local mirror. | 01:18 |
| spiv | Check the 'bzr info' output. | 01:18 |
| wallyworld_ | will do | 01:18 |
| wallyworld_ | it would be great to have a way for point bzr to a top level projects directory and have it tell you things like what shared repos there were, what types of branches etc | 01:19 |
| wallyworld_ | a global overview if you like | 01:19 |
| spiv | Yes, that would be nice. | 01:21 |
| spiv | A bit tricky because there's not really any concept of a "top level projects directory" or anything like that in bzr except by convention. | 01:21 |
| wallyworld_ | spiv: the reconfigure fixed the "master" db-devel but the one i am using shows parent_branch=~projects/lp-branches/db-devel (correct) but submit_branch=~projects/lp-branches/devel (incorrect) | 01:21 |
| spiv | Well, you should be able to fix that from the branch.conf or via locations.conf | 01:22 |
| wallyworld_ | with the overview thing, you would just give it a top level directory and it would decend to all the subdirs and see what i would find | 01:22 |
| spiv | (vila is working on a config system improvement that will be able to tell to exactly where a given setting is coming from) | 01:23 |
| wallyworld_ | :-) | 01:23 |
| wallyworld_ | spiv: i edited the branch.conf for my working branch (it already had parent_location=../db-devel) and added submit_location=../db_devel but bzr info still has submit_branch wrong | 01:26 |
| wallyworld_ | thanks for the help and your patience btw :-) | 01:27 |
| spiv | wallyworld_: the setting is "submit_branch" | 01:29 |
| spiv | not "submit_location" | 01:29 |
| wallyworld_ | tried that too, but found something | 01:30 |
| wallyworld_ | in ~/.bazaar/locations.conf, there is a [/home/ian/projects/lp-branches] section as well as [/home/ian/projects/lp-branches/db-devel] | 01:31 |
| wallyworld_ | it seems the stuff in [/home/ian/projects/lp-branches] overrides the other settings | 01:31 |
| wallyworld_ | i would have though it was the other way around | 01:31 |
| wallyworld_ | and both of these seem to override what's in the local branches.conf file ?? | 01:32 |
| wallyworld_ | everything seems upside down | 01:32 |
| spiv | Yes, locations.conf overrides branch.conf: the idea is that branch.conf might not be under your control (e.g. for a remote branch) but locations.conf always is | 01:36 |
| wallyworld_ | ah, ok. makes sense now. thanks. | 01:36 |
| spiv | So it allows a branch owner to specify what they consider reasonable defaults for some things, but users can still set their own policy. | 01:37 |
| wallyworld_ | so i guess i don't really need a locations.conf if i am working locally | 01:37 |
| spiv | Well, I actually go the other way: | 01:37 |
| spiv | I just do everything in locations.conf | 01:37 |
| spiv | Because for me it's simplest to just have one place with all the settings, | 01:37 |
| spiv | but more importantly because locations.conf allows you to set something once for many branches | 01:38 |
| wallyworld_ | ok. but then i would need new config sections for each new local branch i create eg [/home/ian/projects/lp-branches/xxxx] ?? | 01:39 |
| wallyworld_ | i have a section for db-devel but stuff i branch from my local db-devel doesn't seem to reflect that when a do a bzr info | 01:40 |
| spiv | wallyworld_: that's what the foo:policy = appendpath is about | 01:41 |
| wallyworld_ | ah. makes sense. i need to go off and rtfm. sorry | 01:42 |
| wallyworld_ | i just copied those settings from an existing file and never really knew what they were for | 01:42 |
| spiv | e.g. I have push_location = lp:~spiv/bzr and push_location:policy = appendpath for the directory I keep my bzr branches in | 01:42 |
| wallyworld_ | light bulb goes on. thanks again for your help. really appreciated. | 01:43 |
| spiv | Not a problem. | 01:44 |
| spiv | It's a bit too fiddly :/ | 01:44 |
| spiv | It works well once you know how to use it, though. | 01:44 |
| wallyworld_ | the reason it's important is that i improved the bzr intellij plugin to allow change tracking against the submit branch and if the submit branch is wrong it sort of defeats the purpose | 01:45 |
| wallyworld_ | yeah, as a new user to bzr, there's a lot to learn | 01:45 |
| wallyworld_ | but i do really like bzr more than others i've used | 01:46 |
| thumper | maxb: ping | 01:55 |
| thumper | <maxb> Well that's bad. The busticated content is in a GC block in the oldest largest pack file in the branch | 01:55 |
| thumper | maxb: was that the openobject-addons? | 01:56 |
| maxb | thumper: hi, and yes. I have noted on the bug 666642 | 02:21 |
| ubot5 | Launchpad bug 666642 in Launchpad Bazaar Integration "incorrect data check branching lp:openobject-addons (affected: 3, heat: 16)" [Critical,Confirmed] https://launchpad.net/bugs/666642 | 02:21 |
| thumper | maxb: yep, ta, just commenting now | 02:21 |
| dOxxx | howdy | 02:23 |
| dOxxx | got a question about blackbox testing in bzr... how would I validate that a bzr command is changing the bzr config correctly, without affecting the user's bzr config? | 02:24 |
| spm | *** FYI. codehost will be done shortly for an update. actual downtime should be < 30 seconds *** | 02:44 |
| spm | taking it down now | 02:45 |
| spm | and should be fine again | 02:47 |
| === dOxxx is now known as dOxxx_away | ||
| jam | spiv: are you sure the email you replied to isn't just a troll? | 03:04 |
| spiv | jam: hmm | 03:05 |
| fullermd | Eh, he's always seemed honest to me. Quirky nutcase, but an honest quirky nutcase. | 03:06 |
| spiv | jam: grumpy certainly, but googling does indeed suggest they have their own SSH implementation. | 03:06 |
| jam | you mean lsh, or something else? | 03:06 |
| spiv | Something else. | 03:06 |
| spiv | Possibly something private. | 03:06 |
| spiv | A quick google didn't find it (although it did find a reference to it) | 03:07 |
| spiv | Given their attitude to the GPL I doubt they'd use GNU's ssh :) | 03:07 |
| spiv | dOxxx_away: the bzr TestCaseInTempDir class should insulate you from the user's config | 03:08 |
| spiv | dOxxx_away: grep for 'config' in the existing tests, perhaps | 03:08 |
| * spiv -> lunch | 03:09 | |
| === dOxxx_away is now known as dOxxx | ||
| dOxxx | thanks spiv | 04:44 |
| dOxxx | night all | 05:41 |
| Glenjamin | hi guys, has anyone experienced a "too many open files" error hosting the smart server over http using mod_wsgi? | 09:31 |
| Glenjamin | After much googling the theory is that there are some leaking file handles, and the long-running wsgi process ends up hitting the limit | 09:32 |
| Glenjamin | but i have no idea how to test that theory | 09:32 |
| maxb | You should be able to prove/disprove that easily with lsof -p PID# | 09:32 |
| Glenjamin | i did lsof and counted the number of files for root, www-data and the user wsgi runs bzr as - all three were within the limit | 09:34 |
| Glenjamin | but the requests still got the error | 09:34 |
| Glenjamin | oh, progress | 09:37 |
| Glenjamin | it apepars after each request the number of handles to bzr.log increases | 09:38 |
| Glenjamin | which means it's not bzr, it's my wsgi wrapper | 09:38 |
| Glenjamin | oh balls, i'm opening the bzr log on every request - due to not understanding how wsgi works at all | 09:40 |
| ssandberg_ | hi! is there a way to cherry-pick a changeset (bzr merge -r from..to) and include the changeset comments? | 14:56 |
| poolie | sorry, no | 14:56 |
| poolie | only as text | 14:56 |
| ssandberg_ | poolie, ok, that's a pity. do you know if there are any plans to add this? is there a bug report? | 14:58 |
| poolie | yes there is | 14:59 |
| abentley | james_w: What's the difference between NestPartInstruction.target_subdir and ChildBranch.nest_path ? | 15:12 |
| poolie | meeting now about launchpad for upstreams in #ubuntu-uds-bonaire1 | 15:13 |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| james_w | abentley, where it is coming from and where it is going | 15:15 |
| abentley | james_w: Remember, ChildBranch.nest_path is unset for NestPartInstructions. What is the equivalent of ChildBranch.nest_path for NestPartInstruction? | 15:17 |
| abentley | james_w: Is NestPart.subpath the equivalent of ChildBranch.nest_path ? | 15:19 |
| abentley | james_w: FWICT, target_subdir is the TARGET-DIR in "nest-part NAME BRANCH SUBDIR [TARGET-DIR [REVISION]]" and nest_path is the TARGET-DIR in "nest NAME BRANCH TARGET-DIR [REVISION]", so why aren't they the same variable? | 15:29 |
| ovnicraft | hi folks, i get myaddons/ in branch but i want to create a branch for each dir inside myaddons/ as a multibranch and keeps sync, there is any support in core of bzr? | 15:32 |
| poolie | not in core, i suggest you use scmproj | 15:34 |
| === Ursinha is now known as Ursinha-afk | ||
| ovnicraft | poolie, its supported in lp? | 15:36 |
| poolie | what would you want lp to do with it? | 15:36 |
| Tak | is the cleanup_now() method no longer used in the bzrlib command api? | 15:43 |
| === Ursinha-afk is now known as Ursinha | ||
| === Meths_ is now known as Meths | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| james_w | abentley, I don't know offhand | 16:01 |
| abentley | james_w: I see that TARGET-DIR is optional for nest-part. What do you do if you want to specify a REVISION, but not a TARGET-DIR? | 16:02 |
| james_w | abentley, you specify a target dir | 16:04 |
| abentley | james_w: what target dir would you specify? | 16:05 |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| roryy | hrm | 16:59 |
| roryy | does anyone use wine on linux to run bzr selftest? | 16:59 |
| poolie | roryy, yes, i do | 17:00 |
| poolie | not automatically, but from time to time | 17:00 |
| poolie | it's good | 17:00 |
| roryy | cool | 17:00 |
| roryy | do you use wineconsole ? | 17:00 |
| poolie | i mostly use just 'wine python ./bzr ....' | 17:01 |
| poolie | there are some list posts about it | 17:01 |
| poolie | may also be something in the testing gudie | 17:02 |
| roryy | cool, ta | 17:03 |
| lvh | Hello | 17:11 |
| lvh | Is there a way to push a bzr branch to svn? | 17:11 |
| lvh | Ideally, I'd like to create a bzr repo from svn, branch (with bzr), and then put that branch on the svn repo. | 17:11 |
| dash | yes. | 17:11 |
| dash | it pretty much Just Works. | 17:12 |
| Glenjamin | if you install bzr-svn (a plugin), it just works :) | 17:12 |
| poolie | roryy, some tests probably fail but bugs or patches are very welcome | 17:12 |
| roryy | poolie: cool. mgz got a funny result on win with a merge i proposed, but i can't reproduce it under wine | 17:13 |
| poolie | meeting now about bzr and ubuntu in #ubuntu-uds-curacao12 | 17:14 |
| mgedmin | suppose I have a checkout, not updated lately | 17:17 |
| mgedmin | how can I find how what would be changed if I run 'bzr up'? | 17:17 |
| mgedmin | I don't see a --dry-run in bzr help up | 17:17 |
| vila | mgedmin: bzr missing | 17:17 |
| mgedmin | bzr: ERROR: No peer location known or specified. | 17:17 |
| Glenjamin | bzr missing :bound | 17:18 |
| mgedmin | is there a short name for "the branch I'm a checkout of", or do I need to copy and paste--- thanks for preempting my question with an answer! | 17:18 |
| mgedmin | awesome | 17:18 |
| poolie | bzr st -r :bound ? | 17:18 |
| poolie | mgedmin, you could file a bug asking for 'update --dry-run' | 17:19 |
| mgedmin | I'm surprised you don't already have a bug "every command should have --dry-run" | 17:19 |
| * Tak bzr info --dry-run | 17:19 | |
| poolie | we may? | 17:20 |
| Tak | is UDS the reason that nobody at canonical is responding to email? | 17:20 |
| mgedmin | https://bugs.launchpad.net/bzr/+bug/37829 | 17:20 |
| ubot5 | Launchpad bug 37829 in Bazaar "dry-run option for pull, merge, etc (affected: 0, heat: 0)" [Low,Confirmed] | 17:20 |
| vila | merge has --preview | 17:20 |
| poolie | Tak, probably :) | 17:21 |
| poolie | any mail in particular? | 17:21 |
| Tak | ok - at least there's a reason ;-) | 17:21 |
| poolie | i've been dealing with some | 17:21 |
| Tak | myself and a coworker have sent some commercial-launchpad-question -related emails this week | 17:21 |
| Tak | tsk, it's even in orlando - a year ago I would have dropped by | 17:23 |
| * mgedmin wishes 'bzr unbind' wouldn't just forget the url | 17:23 | |
| jelmer | mgedmin: I think it's a feature, that way you can easily unbind and rebind | 17:23 |
| mgedmin | oh, it remembers! I assumed it forgot because 'bzr info' didn't show any related branches | 17:25 |
| mgedmin | I could've done bzr pull :bound --remember | 17:25 |
| mgedmin | instead of copying and pasting the url from my scrollback | 17:25 |
| Remaille | hi, I have some code in a folder, I did a bzr init | 17:26 |
| Remaille | and now I want to upload all of it into LP | 17:27 |
| Remaille | I did a : bzr push lp:name | 17:27 |
| Remaille | and i have : "No new revisions to push." | 17:27 |
| vila | Remaille: may be you should create a revision now before pushing: bzr add ; bzr commit -m 'import blah' ; bzr push | 17:27 |
| Remaille | This branch is empty. | 17:28 |
| Remaille | hum ok | 17:28 |
| vila | Remaille: then there is nothing to push | 17:28 |
| poolie | Tak, i'll ping people | 17:28 |
| Tak | well - I don't want to make trouble | 17:29 |
| Tak | but otoh, I /do/ want everyone here to be blown away by launchpad's awesomeness | 17:29 |
| Remaille | vila, ok thanks a lot | 17:29 |
| Remaille | I use bzr once every two years :-) | 17:30 |
| vila | Remaille: start by using it once a year then :) | 17:32 |
| Remaille | :-) | 17:32 |
| Remaille | and write down on a txt file what you told me :-) maybe you answered the same question from me two years ago ? ;-) | 17:33 |
| vila | Remaille: I can't remember that far, that's why I use a DVCS ;) | 17:34 |
| mgedmin | bug 1 | 17:35 |
| ubot5 | Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/1) | 17:35 |
| mgedmin | oops, wrong channel | 17:35 |
| james_w | abentley, any target dir you want. You probably want the same as the source dir, as that is what you get if you specify nothing | 18:52 |
| abentley | james_w: So generating a manifest for "nest-part packaging lp:~foo-dev/foo/packaging debian" would produce "nest-part packaging lp:~foo-dev/foo/packaging debian debian $REVISION" | 18:59 |
| james_w | abentley, hmm, not sure, might be a bug | 19:00 |
| abentley | james_w: I think that is what it has to produce. Based on the code, I think it actually produces "nest-part packaging lp:~foo-dev/foo/packaging debian $REVISION", but that would cause $REVISION to be interpreted as TARGET-DIR. | 19:01 |
| james_w | I think it would produce "nest-part packaging lp:~foo-dev/foo/packaging debian None $REVISION" | 19:01 |
| abentley | james_w: There is a conditional on whether target_subdir is None. If it is None, I believe it is completely excluded. | 19:03 |
| james_w | right | 19:03 |
| abentley | james_w: Which makes me think it would not produce "None" in "nest-part packaging lp:~foo-dev/foo/packaging debian None $REVISION" | 19:04 |
| james_w | right, you are correct | 19:05 |
| abentley | james_w: I can patch it. Do you think the "debian debian" version is the correct manifest output? | 19:07 |
| james_w | abentley, https://code.edge.launchpad.net/~james-w/bzr-builder/fix-nest-part-manifest/+merge/39466 | 19:07 |
| abentley | james_w: that will not roundtrip perfectly. Is that acceptable to you? | 19:09 |
| james_w | why won't it? | 19:10 |
| abentley | james_w: get_recipe_text will convert "nest-part packaging lp:~foo-dev/foo/packaging debian" into "nest-part packaging lp:~foo-dev/foo/packaging debian debian" | 19:11 |
| abentley | james_w: if you wanted to make the roundtripping perfect, you would need to do "if target_subdir is None and revid_part is not None" | 19:13 |
| james_w | abentley, I agree, but my test is saying different | 19:13 |
| abentley | james_w: branching... | 19:15 |
| james_w | abentley, I mean the second test I just wrote to fix that issue | 19:15 |
| james_w | damn, my fault | 19:16 |
| james_w | abentley, just pushed a new revision | 19:22 |
| abentley | james_w: r=me | 19:26 |
| abentley | james_w: thanks. | 19:26 |
| james_w | thank you | 19:26 |
| james_w | need a release? | 19:26 |
| abentley | james_w: no, at this point we're not using manifests in anger. | 19:27 |
| mtaylor | GAH | 19:28 |
| mtaylor | bzr: ERROR: Tree transform is malformed [('unversioned executability', 'new-737'), ('unversioned executability', 'new-738')] | 19:28 |
| mtaylor | I thought that was fixed like a million years ago | 19:28 |
| mtaylor | http://paste.drizzle.org/show/103/ | 19:29 |
| abentley | mtaylor: sorry. | 19:29 |
| mtaylor | abentley: do I just suck? | 19:30 |
| abentley | mtaylor: This would be a case where one side deleted a file and the other side changed its executability. | 19:30 |
| mtaylor | abentley: oh, lovely | 19:30 |
| mtaylor | abentley: is there anyway for me to find out which file? | 19:30 |
| mtaylor | abentley: because I can gladly fix it in one of the trees | 19:31 |
| abentley | mtaylor: I think this requires setting a breakpoint where the exception was raised and then calling TreeTransform methods. | 19:32 |
| james_w | mtaylor, we probably didn't squash all the cases | 19:37 |
| james_w | mtaylor, can you tell me how to reproduce? | 19:37 |
| mwhudson | BZR_PDB=1 should get you to an appropriate pdb prompt? | 19:37 |
| abentley | mtaylor: tt._new_name.get('new-737') or tt.tree_id_paths.get('new-737') should give you the name or path. | 19:38 |
| lvh | What are things like "lp:" called? Can I add my own? | 19:38 |
| mwhudson | lvh: its a directory service, and yes | 19:39 |
| lvh | mwhudson: Aha, thanks | 19:39 |
| abentley | lvh: mostly, you need to write a plugin to do so. | 19:39 |
| mwhudson | yeah, you need a plugin | 19:39 |
| lvh | right, but I can just use the bookmark plugin and cover most use cases, right? | 19:40 |
| mwhudson | yeah, the bookmark plugin handles many cases | 19:40 |
| abentley | lvh: that will work great for static assignments. For dynamic ones, like expanding prefix:* => http://example.com/*, I have bzr+ssh://bazaar.launchpad.net/~abentley/%2Bjunk/openlookup/, but it's not documented. | 19:41 |
| lvh | abentley: Aha, thank you. I will take a look at that | 19:42 |
| mtaylor | james_w: grab lp:~mordred/drizzle/test-elliott-release and then http://wc220.com/drizzlefiles/drizzle7-2010.10.02.tar.gz and then do bzr merge-upstream --version=2010.10.02 drizzle7-2010.10.02.tar.gz | 19:42 |
| abentley | lvh: basically, you need to add a section to bazaar.conf like so: http://pastebin.ubuntu.com/520925/ | 19:43 |
| mwhudson | i have a plugin that lets me say things like bzr pull -d plugin:svn | 19:43 |
| mwhudson | but sadly, not on this machine | 19:43 |
| mtaylor | abentley: | 19:44 |
| mtaylor | (Pdb) print tt._new_name.get('new-737') | 19:44 |
| mtaylor | None | 19:44 |
| abentley | mtaylor: okay, try tt.tree_id_paths.get('new-737') | 19:45 |
| mtaylor | *** AttributeError: 'TreeTransform' object has no attribute 'tree_id_paths' | 19:45 |
| * mtaylor pokes around... | 19:45 | |
| abentley | mtaylor: sorry, leading underscore. | 19:45 |
| mtaylor | yup. see it | 19:45 |
| mtaylor | hrm | 19:45 |
| mtaylor | u'drizzled/set_var.cc' | 19:45 |
| mtaylor | so, in trunk, set_var.cc got renamed to sys_var.cc and then a new set_var.cc was added | 19:46 |
| james_w | mtaylor, what's your version of bzr-builddeb? | 19:46 |
| mtaylor | (repeat for set_Var.h | 19:46 |
| james_w | I'm pretty sure that's one of the cases that I fixed | 19:46 |
| mtaylor | james_w: builddeb 2.2.0 | 19:46 |
| lvh | abentley: Aha! Despite the fact that that *does* look sexy, unfortunately I can't use things that are undocumented or unsupported (yay policy) | 19:46 |
| james_w | mtaylor, you need 2.6 or maybe 2.5 | 19:47 |
| mtaylor | james_w: should I just pull lp:bzr-builddeb | 19:47 |
| james_w | mtaylor, what's your platform? | 19:47 |
| james_w | that would work | 19:47 |
| lifeless | ubuflu | 19:47 |
| mtaylor | just branched - trying | 19:47 |
| mtaylor | lifeless: hah | 19:47 |
| lifeless | mtaylor: available now | 19:47 |
| mtaylor | (actually, this is on a squeze box) | 19:47 |
| mtaylor | lifeless: where r u? | 19:47 |
| abentley | lvh: Well, undocumented I could fix, but unsupported is tricker... :-) | 19:47 |
| lifeless | hallway? | 19:48 |
| mtaylor | lifeless: will find - honestly not _important_ - more an idea - coming | 19:48 |
| mtaylor | james_w: nope. still exception | 19:48 |
| james_w | mtaylor, ok, I'll take a look | 19:48 |
| mtaylor | james_w, abentley : also, the set_var.cc was modified in the same rev it was renamed in - so it may not be obvious to merge-upstream that renamed-set_var.cc is the same file | 19:55 |
| mtaylor | is there anything you can think of I can do to my local tree to un-confuse merge-upstream? (like re-commit something or something?) | 19:56 |
| abentley | james_w: are you using RenameMap to guess renames? That should be able to detect a rename if the file hasn't changed excessively. | 19:58 |
| james_w | abentley, we are not | 19:59 |
| james_w | mtaylor, not without understanding the error better, sorry | 19:59 |
| mtaylor | james_w: ok. cool | 20:00 |
| abentley | james_w: ah. Well, you might find it useful, and if not, I'd be interested to hear why. | 20:00 |
| mtaylor | abentley: well... the file _did_ change excessively ... | 20:01 |
| mtaylor | abentley: perhaps I should have done the rename as a commit and then the change as a commit... ? | 20:01 |
| abentley | mtaylor: I don't know enough about bzr-builddeb to be able to answer that, sorry. james_w? | 20:02 |
| * mtaylor is now probably being annoying... will just try things | 20:02 | |
| mtaylor | just for the record, splitting rename and new content into different commits no helpie | 20:06 |
| ovnicraft | h folks, maybe its OT but i want to know how add a user to push in my branch in lp? | 20:23 |
| mtaylor | ovnicraft: it's more a question for #launchpad - but you want to create a user in launchpad and then that user can push branches to launchpad quite easily | 20:42 |
| ovnicraft | mtaylor, yes but add a user i fixed thi teams | 20:42 |
| ovnicraft | mtaylor, thx | 20:42 |
| mtaylor | abentley, james_w: fwiw, I reverted the four files to a version before the rename, did the merge-upstream, then reverted the files to the version _after_ the rename - and all seems ok | 20:44 |
| james_w | mtaylor, I'm getting somewhere with the debugging as well | 20:44 |
| mtaylor | james_w: excellent :) | 20:45 |
| james_w | it's actually a duplicate id problem, not unversioned executability | 20:45 |
| * mtaylor likes causing complex problems... | 20:45 | |
| james_w | I'm not sure how to tell where the trans ids that I have came from though | 20:45 |
| james_w | mtaylor, plugin/haildb/tests/r/insert_null.result plugin/haildb/tests/t/type_float.test | 20:53 |
| james_w | any idea why they would be getting involved? | 20:54 |
| mtaylor | james_w: gosh no | 20:54 |
| mtaylor | james_w: they shouldn't be involved with this at all | 20:55 |
| mtaylor | james_w: unless both changes hit trunk as part of the same merge | 20:55 |
| === Ursinha is now known as Ursinha-bbl | ||
| lvh | Does svn-push no longer exist? Is it just push-with-an-svn-url now? | 22:07 |
| dash | correct | 22:07 |
| lvh | bzr push svn://host/repo/branches/new-branch-1234 will just work? | 22:09 |
| * lvh is extremely skeptical, having played with hg-svn today | 22:09 | |
| dash | lvh: yes but it might make some svn users unhappy | 22:09 |
| lvh | dash: Why is that | 22:09 |
| lvh | dash: I'm trying to merge changes into twisted trunk without using svn (if possible) | 22:09 |
| dash | lvh: if they use tools (like combinator) that expect branching to occur in a different revision from branch content adding | 22:09 |
| dash | lvh: if you use svn cp to create the branch _then_ push to it, all will be right with the world | 22:10 |
| lvh | oh okay | 22:10 |
| dash | the only other twist is that there's 'dpush' which pushes without bzr metadata on the revision | 22:10 |
| lvh | dash: Which for twisted is good? | 22:10 |
| dash | lvh: glyph will probably complain if you don't use it | 22:11 |
| dash | but i've ignored him and you can too ;) | 22:11 |
| glyph | use dpush | 22:14 |
| glyph | otherwise you will put corrupt revision metadata in the twisted repository | 22:14 |
| glyph | you might have been able to get away with it last week, but we are facebook friends now, so I know where you live. | 22:14 |
| dash | oh, hi. | 22:14 |
| lvh | glyph: my lp thing used to have my address quite accurately | 22:15 |
| glyph | lvh: More generally, dpush is the stealth way to go. it does some rebasing and loses a bunch of information, but if you use it, it is basically indistinguishable from using the stock svn client, from the perspective of everyone else on the project. | 22:16 |
| glyph | this is what it looks like if you use a regular push: https://trac.calendarserver.org/changeset/4434 | 22:16 |
| lvh | glyph: Okay so the way to not piss you off, working from scratch: bzr branch thesvnrepo; bzr branch to feature-1234; hack hack hack; create remote svn branch; bzr dpush svn://host/repo/branches/feature-1234? | 22:17 |
| glyph | lvh: except +ssh, basically, yes. | 22:17 |
| glyph | and that is the way I work these days, because of the aforementioned trac ugliness. | 22:17 |
| dash | well | 22:17 |
| glyph | Frankly if trac could hide those, and bzr never choked to death on its own metadata, I'd be fine with a normal push. | 22:17 |
| dash | better to do svn cp then 'bzr branch' or 'bzr co' from the branch url | 22:18 |
| dash | so that when you push you don't get "omg these branches have diverged" | 22:18 |
| glyph | pull first! | 22:19 |
| glyph | although man | 22:19 |
| glyph | there really needs to be a 'bzr sync' or something, so I can just run that in a hurry, get on a plane and then do the merge later | 22:19 |
| lvh | dash: Wait what pull where | 22:19 |
| lvh | dash: Also does that work if I start from lp:twisted | 22:20 |
| glyph | I hate the workflow where it's wait-wait-wait-okay connected to remote server wait-wait-wait-okay oops diverged, TIME TO WAIT AGAIN | 22:20 |
| dash | lvh: instead of creating a local bzr branch from trunk, create a local bzr branch from the svn branch you're targeting | 22:20 |
| lvh | glyph: works well IRL: "hey can you look at this piece of code" "um okay, what's wrong" "nothing I just wanted to make sure I merged first." | 22:20 |
| lvh | dash: Right okay. And bzr-svn is smart enough to make that work if everything else is a bzr repo? I already have a shared repo with a "trunk" directory which is lp:twisted | 22:21 |
| glyph | oh man | 22:22 |
| glyph | lp:twisted is not a good scene | 22:22 |
| glyph | don't use that | 22:22 |
| lvh | Okay | 22:22 |
| glyph | or... wait maybe I'm wrong, I haven't used it in a while. | 22:22 |
| dash | i think it uses bzr-svn now | 22:22 |
| glyph | Do the revision numbers match up with our branch-hosting bzr mirror? | 22:22 |
| dash | lvh: the main thing is that if you branch from lp:twisted it won't prime bzr-svn's svn rev cache | 22:23 |
| dash | glyph: AFAIR yes | 22:23 |
| * dash checks. | 22:23 | |
| lvh | So, starting from scratch: bzr init-repo Twisted; cd Twisted; bzr branch svn://svn.twistedmatrix.com/svn/Twisted/trunk trunk; svn cp create-a-branch; bzr brach that-branch awesome-feature-1234; hack hack hack; bzr dpush? | 22:24 |
| dash | yeah, looks like it. | 22:24 |
| dash | lvh: yes. | 22:24 |
| lvh | Okie, thanks | 22:24 |
| glyph | we also have a bzr mirror | 22:24 |
| lvh | glyph: Is it okay to use that or is that too a source of bad things | 22:25 |
| dash | it's created using bzr-svn | 22:25 |
| dash | as is lp:twisted | 22:25 |
| dash | they should have the same history as anything you branch from svn yourself | 22:25 |
| glyph | they match exactly | 22:28 |
| glyph | basically they're an optimized way of bootstrapping | 22:28 |
| glyph | although eventually you end up needing to prime your svn revision cache anyway | 22:28 |
| glyph | because they lag | 22:28 |
| lvh | Hm. | 22:29 |
| lvh | dash: Sorry, I disconnected. If lp:twisted and the twisted bzr mirror are both made with bzr-svn, why is one a bad idea and the other not such a bad idea? SVN metadata? | 22:29 |
| dash | lvh: glyph was remembering the old version of lp:twisted from before bzr-svn worked real good | 22:31 |
| dash | it's fine now | 22:31 |
| lvh | dash: So, I can still use my shared repo with trunk I stole from lp:twisted? | 22:32 |
| dash | yep | 22:32 |
| lvh | revno: 15682 | 22:45 |
| lvh | svn revno: 30182 (on /trunk) | 22:45 |
| lvh | dash: So, to actually merge the change, I can just do it on bzr and push to svn trunk, since everyone knows trunk exists, and that won't piss glyph off? | 22:46 |
| dash | lvh: i forget whether dpush sets svn:mergeinfo or not | 22:47 |
| dash | glyph: re trac: "hide_properties = svk:merge, bzr:file-ids, bzr:merge, bzr:revision-info" | 22:48 |
| peitschie | mornin everyone :) | 22:49 |
| glyph | dash: okay, I just told a guy that | 22:52 |
| glyph | dash: do you want to tell exarkun? | 22:52 |
| dash | glyph: in the 'browser' section, specifically | 22:54 |
| glyph | dash: now you've done it. #calendarserver | 23:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!