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