[00:10] igc: whats the testing guide and why isn't it part of the dev guide? [00:11] sorry if that came across picky, I'm just a little surprised / concerned about fragmentation [00:11] lifeless: someone moved it out (vila maybe) [00:12] lifeless: http://doc.bazaar-vcs.org/developers/ [00:12] oh [00:13] so this is a terminology thing [00:13] thats all dev guide to me [00:13] and I suspect to poolie as well [00:13] just chapters in the dev documentation [00:20] Is http://bazaar-vcs.org/bzr/.bzr/repository/packs/ really badly compressed, or did I accidentally misplace most of my repo while upgrading to 2a? [00:21] Oooh. Never mind. That is a 1.9-format repo. Hm. [00:22] Ohh! http://bazaar-vcs.org/bzr/bzr.dev/ is a branch reference now. Clever! [00:22] Confusing, too. [00:23] So lp:bzr is now the official location for bzr.dev? [00:23] yup [00:24] What should I set bzr to use as the public/submit branch? [00:25] check the docs ;) [00:25] :< [00:25] .....Which docs? :D (kidding) [00:25] [I've paged it out] [00:26] The doc directory in the source tree doesn't help. [00:28] I'll keep the public and submit branches set to bazaar-vcs.org for now, then. [00:31] Peng_: HACKING.txt [00:31] look for locations.conf [00:36] Ah, thanks. That didn't help very much, though. I'm not a PQM user. [00:37] And LP is open source now. I have missed a lot! [00:39] Peng_: well, lp:bzr then ;) [00:40] Literally "lp:bzr", or the http or bzr+ssh location that points to? [00:43] literally [00:43] if you just want 'bzr send' to work [00:49] OK. [00:55] hi all [00:55] welcome back igc [00:55] thanks poolie [00:55] Good morning. [00:55] Good morning. Or whatever. :) [00:55] hi spiv [00:55] Is it morning? [00:55] hi Peng_ [00:56] Peng_: it is here :-) [01:40] hi ho [01:40] what is the simplest way to allow people to push to a machine with bzr+ssh but not to have shell access? [01:41] There's a script, contrib/bzr_access or somesuch. [01:41] authorized_keys policy [01:41] Yeah. [01:41] and or that script [01:41] oh kay... [01:42] which is easier / more configurable? [01:42] launchpad :P [01:42] Heh. [01:42] lifeless: haha [01:42] He's right... [01:42] where does the package install the contrib dir? [01:42] I don't think it does [01:42] Peng_: it is for some friends polytech work [01:42] no project [01:42] and they don't want it public [01:43] and I don't want them poking around my machine [01:43] Umm. Install Launchpad on your machine? :D [01:43] heh [01:43] no [01:43] You could just give them SFTP access. [01:44] Peng_: that isn't great [01:44] this should be an easy thing to set up for bzr [01:44] I've been frustrated that it wasn't easier [01:44] like sticky group bits [01:44] Peng_: you'd want to give 'em smart server access too ... [01:44] and umasks [01:44] et al [01:44] I think we should be able to set something in the locations.conf (or something) [01:44] and have the smart server set the right groups [01:44] IMHO [01:45] SamB_XP_: I know [01:58] spiv, hello [01:59] poolie: hi [02:00] poolie: I've done a couple of rounds of "do something to a bug" "gar, file a bug on launchpad" this morning. [02:01] poolie: I have a fix for the 2 hpss vfs calls on incremental push; I've played a bit with trying to anticipate future requirements with the new verb I'm adding, but decided against it so I'll just submit the simple fix. [02:03] igc, to answer the only other question on our agenda [02:03] see my mail to emma on friday, i'm aiming to get the site up this week [02:03] from a shared branch deployed to escudero [02:03] spiv, cool [02:03] poolie: thanks [02:03] or you can if you get to it first [02:03] spiv, we still seem to get a lot of 'medium(?) in use' errors [02:04] maybe this should be handled under -Dcleanup but perhaps there's something else we should do that would avoid them obscuring the real error? [02:05] poolie: hmm [02:10] my thoughts exactly :) [02:10] :) [02:10] maybe we'll try -Dcleanup first and then see what happens [02:10] or more importantly, putting a choke point for all cleanups [02:13] spiv: whats trigering vfs on incremental push ? [02:13] lifeless: "cannot update remote workingtree" warning [02:14] meep yes I saw that [02:14] what was it? [02:14] push explicitly checks for a working tree so that it can issue that warning, and we have no HPSS way to find a working tree. [02:15] It doesn't actually care what format or anything it is, just whether or not there is one. [02:16] So I've made a new BzrDir.open verb that returns a yes/no for the presence of a workingtree in this bzrdir. [02:16] +1 [02:16] have you seen spurious outputs of that warning btw? [02:16] I could have made a has_workingtree verb, but may as well cut out the roundtrip and take the opportunity to slightly decruft the BzrDir.open verb :) [02:17] No, I don't think so. [02:17] so, I think has_workingtree would be more precise [02:17] but as we don't support working with them remotely anyway [02:17] doing what you've done is fine [02:18] Right. [02:18] what cruft are you deing? [02:18] [if its the declarative capabilities, I'm not sure we want to remove them] [02:18] The current BzrDir.open verb squashes some error conditions into just 'yes'/'no', for backwards-compat reasons. [02:19] I see, cool. [02:20] poolie: one thing I forgot to discuss on the phone: elmo's email re the karmic chroot [02:20] poolie: one of us should reply [02:23] hmm, why does multi-pull try to pull data from a file URL when i want to fetch from a bzr+ssh URL? even worse, it sees the path the branch was on the other machine from which i first pushed it up [02:24] zsquareplusc: it uses the remembered pull locations, IIRC. You can use "bzr pull --remember NEW_URL" in those branches to change that. [02:26] hm, doesn't this make the multi-pull more or less useless? it apparently manages to find these branches on the remote URL but then it turns to a completely different location to download?!? [02:27] zsquareplusc: no, it just does the same as "bzr pull" with no arguments would do in each of the individual branches. [02:28] Which is often the right thing, and if it's not it's usually easy to use either --remember or edit your locations.conf to make it do the right thing. [02:28] It would be nice to have a "pull all of these from *over there* just this once" feature too, though. [02:30] well the branches were created on one machine, converted from CVS. i pushed them to a repo on sf.net. so i have to manually touch each of these again, re-push etc :( [02:33] spiv: i disagree that it is doing the right thing in this case. i have no local copy yet, just and empty shared repo. i'd certainly expect that multi-pull downloads from the URL i'm giving it not from anywhere else. [02:36] how do i see the saved push location? bzr info? [02:36] because i don't see it there on the branch i pulled (one of those were multi-pull failed) [02:38] zsquareplusc: if you don't have a branch yet, then pull (and multi-pull) aren't the commands you need. [02:38] i don't see a multi-branch :/ [02:38] Yeah :( [02:39] I agree there are things we could support better, I'm just explaining that multi-pull is doing what it was designed to do. It would be nice to have multi-branch or similar. [02:40] We're actually planning to rethink how we deal with groups of branches for 3.0, because we know we're a bit lacking. [02:40] well if it would just fail, OK. what's irritating me is that it somehow remembers a local path on my other machine [02:41] i ran a bzr info on the branch i originally pushed, it has that file URL there listed as parent [02:42] zsquareplusc: that does sound weird. multi-pull walks all the subdirectories of the directory you run it in looking for branches to pull, perhaps one of those has a branch with that info? [02:42] Whatever multi-pull does with an individual branch you ought to be able to reproduce with plain "bzr pull" on that branch. [02:43] i gave it the URL of the remote repo, so it apparently walks trough those :/ [02:43] Oh! [02:43] That does sound likely to confuse, yes. [02:43] I guess that's like doing "bzr pull -d REMOTE_URL"... [02:47] that the branches remember that file:// parent does not hurt? at least the fresh branch i made from the remote repo (using bzr branch) does not list it anymore, it has the remote repo URL as parent, which makes more sense [02:49] and is there a special reason that when i bzr branch, that same URL is not right away saved as push, pull and merge location? at least the way i was using it, that would have been helpful [02:56] spiv: yeah, it does seem a bit silly for it to be attempting to pull *into* an HTTP url ;P [03:01] SamB_XP_: there might be a smart server there :P [03:01] it was a bzr+ssh URL [03:02] oh, that's a bit less dumb then [03:09] I thought that the bug with bzrlib/bzrlib/*.so was fixed? [03:10] hmm. getting access denied on c:\...\temp\xxx.pag [03:16] i made a bash script that does several bzr branch(es) now when i run it under cygwins bash it prints that its connected using ssh and then the error about access denied on the temp file :( [03:24] when i run the command manually it fails the same way - when run in a bash shell. it works in a cmd.exe :/ [03:35] it seems to be paramiko/win_pageant.pyo:121 that causes the error (official bzr 1.15 windows distribution) === timchen1` is now known as nasloc__ [04:48] * igc lunch [05:13] spiv btw bug 432993 is the kind of thing i was referring to earlier [05:13] Launchpad bug 432993 in bzr "TooManyConcurrentRequests when failing to connect over ssh" [High,Confirmed] https://launchpad.net/bugs/432993 [05:38] * igc medical appointment - bbl [06:01] i can haz hard linkz agan plz? [06:01] poolie: you're working on a bug script? [06:02] thumper: what do you want them for? [06:02] i am [06:02] lifeless: hardlinking working copy files is not currently supported in [06:02] lifeless: just how I work [06:03] thumper: tell me more [06:03] lifeless: I have light weight checkouts of devel [06:04] many? [06:04] lifeless: and I build new branches using 'cbranch --lightweight --hardlink' [06:04] lifeless: now about 20 [06:04] have you considered using switch ? [06:04] yes [06:04] I use pipelines [06:04] What doesn't it do/does wrong for you? [06:05] but I like to keep my work in meaningful directories [06:05] it adds context for me [06:05] sure [06:05] I started with switch originally [06:05] so I use meaningful directories [06:05] but I found I had too many copies on the go [06:05] and switch [06:05] do you mean 'you forgot where you were' [06:06] or 'you actually needed multiple work areas at once due to $thing' [06:06] lifeless: it had to do with work that was in various states of review [06:06] lifeless: I often have tests running in one branch [06:06] while hacking in another [06:06] 888 Confirmed [06:06] 353 Triaged [06:06] 265 New [06:06] 147 Incomplete [06:06] 47 In Progress [06:06] 17 Fix Committed [06:06] or even running LP locally in another [06:06] poolie: welcome to API's [06:07] mm, i have poked at them before [06:07] lifeless: I also found that using TAGS, with multiple directories, I need different emacs buffers [06:07] the vodka is strong but the meat is no good [06:07] lifeless: or I can get jumped around into the wrong directory [06:08] thumper: would it be a good idea for 'bzr switch' should incremental-update TAGS? [06:08] thumper: here's where I'm coming from: we're doing UI overhaul around groups of branches. [06:08] I don't pretend to understand TAGS [06:09] I know [06:09] thumper: I suspect many folk have 'lightweight + switch' as key building blocks in how they want to tackle that. [06:10] I guess I use my checkouts as a kinda "work in progress" list [06:10] thumper: so I want to understand the friction you felt more [06:10] I delete them when they are merged [06:10] I use multiple checkouts for various reasons [06:10] I like to be able to run against trunk without switching my current work [06:10] thumper: so just click affectsmetoo on the bug and then... oh :) [06:10] to perhaps test stuff [06:11] more seriously, we could look at in content filtering [06:11] and sometimes running long tests locally while wanting to hack other stuff [06:11] so I need more than one concurrent checkout [06:11] one I had more than one [06:11] I found that I wanted meaningful directory names [06:12] the easiest way I found was to have lightweight checkouts for my work [06:12] and moved to cbranch [06:12] from there to hardlink [06:12] perhaps having a way to tag branches in a local repo as in various states would help me [06:13] so I could easily see which branches I have locally that aren't merged [06:13] without having them all in their own checkouts [06:13] fwiw, i work almost exactly like thumper [06:13] as long as I could list them easily [06:13] thumper: I use directories to tag branches [06:13] lifeless: inside the repo? [06:13] thumper: mkdir pending; mkdir review; mkdir experimental [06:14] fwiw, thumper works almost exactly like me :-) [06:14] yup [06:14] i don't actually have any real problems with bzr here, as 'make build' takes far longer than tree building :( [06:14] I don't have trees in my repo [06:14] it seems ick to me [06:14] mwhudson: true [06:14] thumper: thats not anything to do with trees :) [06:14] thumper: I put branches under there [06:15] lifeless: but if you have a lightweight checkout, and you move the branch [06:15] lifeless: how do you reconcile that? [06:15] bzr switch --force [06:15] but it happens rarely [06:15] as I have only a few checkouts [06:16] and usually state changes are also when I need to stop editing (or conversely start editing) branches [06:16] lifeless: I got my workflow from jamesh [06:16] lifeless: when I first started using bzr [06:16] thumper: I'm not criticising it! [06:16] lifeless: I'm not saying you are [06:16] lifeless: I'm trying to give context [06:17] thanks ;) [06:17] lifeless: part of it is "this is how I was taught" [06:17] righto [06:17] lifeless: I have thick skin, you have to be a hell of a lot more direct for me to think you are criticising :) [06:18] All the rugby [06:18] lifeless: I didn't start rugby until I worked in the UK [06:18] lifeless: never played in NZ before that [06:18] :) [06:36] what's the recommended workflow when working on a feature branch while trunk keeps actively updated? [06:37] hack;hack; commit; merge trunk; check for regressions; commit; hack; hack; loop [06:39] I'm using launchpad, I have one branch in rev 18, and other in rev 21 which is the trunk. I'm afraid that when I merge the former (likely to keep at rev 18) with the latter, that could be at rev 25 for example, well I'm afraid I have problems... [06:39] what are regressions? [06:39] when things stop working [06:39] and so I need to keep in sync with the target branch? [06:40] up to you [06:40] you asked for recommended ;) [06:40] hum so it is recommended to avoid regression? [06:40] the more diffs between branches, the more likely the merge will break code? [06:41] * RenatoSilva how merges are get done is still an enigma for him [06:46] RenatoSilva: avoiding regressions is a fancy way of saying 'don't introduce bugs' :) [06:47] RenatoSilva: I dunno if falling behind and having to do larger merges is more likely to introduce bugs (probably), but it's also harder and more likely to conflict [06:47] and bugs can happen when you merge. [06:47] RenatoSilva: basically, bzr compares the history of all the changes in the two branches, and applies the changes that are present in the merge source but not yet present in the target. [06:48] bob2: yeah, I don't know about bugs either (generated by the merge itself?) [06:49] RenatoSilva: but bzr is just software; the way it understands changes is by seeing which lines of text have changed, rather than understanding that e.g. "function X was renamed to Y", so it's possible that the result bzr merge will produce something other than what a human would have done if they were applying those changes manually. [06:49] RenatoSilva: by combining your code with the trunk - e.g. if you modified some function to introduce a bug [06:49] RenatoSilva: the classic thing is stuff like adding a required argument to a function in one branch while adding a call to that function in another [06:50] RenatoSilva: both branches are correct, but the combination is not, and you'd need to be waaay cleverer than any vcs tool is today to figure that out automatically [06:50] spiv: that's what I imagined, for example if I merge branch X in rev 19 with trunk rev 21, where they have diverged at rev 17, so bzr will take revs 18 and 19 and try to apply the diffs to rev 21 on the trunk, right? [06:51] RenatoSilva: and sometimes changes in the two branches are simply incompatible as-is, e.g. one branch may add a new argument to a function, and the other may add a different new argument instead. (or mwhudson's example, which is similar) [06:51] RenatoSilva: the mechanics of the merge - bzr will merge unmerged work. [06:51] RenatoSilva: you should just try; nothing like experimentation to help you see [06:51] RenatoSilva: if you merge X into trunk, then yes. [06:52] RenatoSilva: (although not via diffs, precisely; diffs don't handle renames and bzr does, for instance) [06:52] Hmm, well, I guess diffs can do renames. [06:53] diffs aren't so good for changes to symlinks or binary files, though :) [06:55] Well, merging isn't so good for symlinks or binary files..... [06:55] spiv: ok I don't mean `diff`s are generated, I just think it's sort of magic :) [06:56] Peng_: yeah, but at least it DTRT when only one side has changed them. [06:56] spiv: Oh, cool. [06:56] Peng_: for bin files you have to choose between one and another versions right? there's no merge for them ... [06:57] RenatoSilva: Well it's totally theoretically possible to develop merge tools for binary files. [06:57] RenatoSilva: Merging really isn't scary, and it's a major part of using a DVCS. [06:57] RenatoSilva: Even if things go horribly wrong, you can just "bzr revert". [06:58] lifeless: well I have merged a few times, I just see it as magic :) (just curious about how it works -- because of the initial issue) [07:01] spiv: well I think something similar to a merge-directive is used [07:01] RenatoSilva: well, if a file originally had a series of lines ABCD, and one branch changed it to ABC, and the other changed it to AECD, then merge would result in AEC. [07:01] spiv: except that the commits are "packaged" under another one [07:02] spiv: AEC? weird, so bzr tries to do same-line merges? o.O [07:03] RenatoSilva: no, by "ABCD" I mean four lines [07:03] RenatoSilva: just using a very compact notation because IRC isn't really designed for multi-line examples :) [07:04] ok :) [07:04] so it is recommended that as I update trunk, I do a bzr pull in the other branch? [07:05] no, you can't [07:05] (In principle a merge algorithm can work with sequences of bytes rather than sequences of lines, but for various reasons lines tend to be a good tradeoff for performance and human-intelligible results for source code) [07:05] because the other branch has different changes [07:06] back [07:07] lifeless: hum you can't pull from a diverged branch, right [07:07] so what should I do? [07:07] merge trunk into the other? [07:07] yes; as I said waaaay above :) [07:08] let's use an example [07:09] branch X rev 19, diverged from trunk at rev 17, and trunk is at rev 21 [07:09] so I merge trunk into X, and X get a new rev 20 { trunk 18-21 } ? [07:09] RenatoSilva: yes [07:10] cd X; bzr merge trunk; ; bzr commit -m 'merge trunk' [07:11] and when I'm done I merge X into trunk, that gets a rev 22 { X 18, 19, 20 { trunk 18-21 } } ? [07:11] * trunk, which gets [07:11] Not sure exactly what you mean by that notation. [07:12] spiv: that's the only way I can see it :( [07:12] It's tip revision, rev 22, would have two parents, trunk's 21 and X's 20. [07:12] spiv: rev 22 of trunk will contain 3 revs from X: 18, 19 and 20, where 20 is a merge with trunk [07:12] RenatoSilva: "contain" isn't really the right relation. [07:13] RenatoSilva: "has parent" is the relation. [07:13] what's a tip revision? [07:13] RenatoSilva: the most recent revision in that branch. The "tip" of the branch :) [07:13] the most recent commit on a branch [07:13] Also known as "head" [07:14] RenatoSilva: have you seen the output of "bzr viz" (if you have the bzr-gtk plugin) or "bzr qlog" (if you have qbzr)? [07:14] spiv: I think if you explain me using my notation I could easily understand :) [07:15] * RenatoSilva trying to understand "It's tip revision, rev 22, would have two parents, trunk's 21 and X's 20." [07:15] RenatoSilva: I can't, because I think the way you read your notation presumes a view of the system that isn't accurate [07:15] poolie: so whats your bug thing? [07:15] spiv: I'm pretty sure that notation means rev 22, which contains X's 18, 19, 20. X's 20 contains trunk's 18-21. [07:15] davidstrauss: contains is the problem though :) [07:15] davidstrauss: as revisions are not containers for revisions [07:16] lifeless: what does it mean when they're nested in the log output, then? [07:16] davidstrauss: a) what lifeless said, b) that reading would confirm my suspicion that it's an inaccurate model for bzr [07:16] davidstrauss: non-left hand parent [07:17] davidstrauss: e.g. a merge occured, and the revision that is indented was not present in the left hand ancestor of the above revision [07:17] lifeless: last time I saw a merge commit the revisions merged were showing "inside" the merge revision [07:17] RenatoSilva: so, a commit has links its parent(s), and they are links rather than copies. [07:18] RenatoSilva: and those parents in turn have links to *their* parent(s), and so on. [07:18] lifeless: I have never seen one for the scenario I mentioned though [07:18] RenatoSilva: yes, they will show like that; this indicates 'merged by' not 'contained within' [07:18] lifeless: i'd like to make the state of the queues more visible [07:18] maybe with a graph of open bugs etc [07:19] and to have a list of tags perhaps [07:19] RenatoSilva: so you can draw a diagram of the revision ancestry back to the start (a revision with no parents) by repeatedly following those links. [07:19] and just generally get a better feel for how much things can be extended using apis [07:19] poolie: what I'd love: a google appengine web page; showing the bzr project [perhaps project-group even] bugs in my preferred sort order [07:19] spiv: so replace "contains" with "has children linking to it, which are:" [07:20] spiv: is that accurate? [07:20] davidstrauss: if so, that notation is inaccurate, and should be trunk 22 { X 20, trunk 21 } [07:20] lifeless: yeah me too but small steps [07:20] hi all [07:21] i'd like to prototype some kind of dashboard [07:21] spiv: why would a single revision have children from two different branches? [07:21] davidstrauss: and expanded out one more level would be trunk 22 { trunk 21 { trunk 20 }, X 20 { X 19, trunk 21 } } [07:21] spiv: I mean, direct childred [07:21] children* [07:21] davidstrauss: that's what a merge is [07:21] spiv: A merge pulls in revisions from one other branch [07:22] davidstrauss: also, "parent", not "children", unless you're asking a different question to what I think you are? [07:22] spiv: which may have children from other branches still [07:22] lifeless: i guess overall the thing is that all the data is there, but the tools for querying it are not so great [07:22] for something as simple as 'how many bugs are open in bzr' you need to iterate them [07:22] which is the opposite of what you want [07:23] spiv: but if i merge from another branch and commit as rev 22, revision 22 should only have direct child revisions from one other branch [07:23] poolie: meep, theres no __len__ on search results? [07:23] davidstrauss: it will have two parents [07:23] davidstrauss: and no children (yet) [07:23] spiv: so, the indented revisions below a merge revision in log are *parents*? [07:24] poolie: the API folk have expressed a strong desire to be told about issues [07:24] davidstrauss: those parents will be the previous tip of the branch you just committed in, plus the revision you merged in from the other branch. [07:24] davidstrauss: have you seen "bzr viz" or "bzr qlog"? [07:24] trunk 22 { X 20, trunk 21 }? [07:24] spiv: haven't used any gui tools [07:24] davidstrauss: the history is a DAG, and those tools do a good job of visualising it [07:25] davidstrauss: "bzr log" makes an attempt to represent some the structure of that DAG in plain ascii, which is inevitably a bit hard in complex cases :) [07:25] spiv: I'll jsut keep X updated by merging trunk into it regularly, then when I'm done I'll merge X into trunk, and then see what happens in log/qlog :) [07:26] davidstrauss: if you pass --show-ids to log it will explicitly give the "parent:" links for each revision. [07:26] RenatoSilva: good idea :) [07:26] spiv: ok, so let me rephrase my previous statement. "rev 22, which has parents {X's 18, 19, 20}. Also, X's 20 has parents {trunk's 18-21}. [07:27] A revision only has 1-2 parents. But its parents have their parents, and on up the chain. [07:27] spiv: I still don't see how a revision could have parent revisions other than (1) in the same branch and (2) in one other branch [07:27] davidstrauss: "rev 22, which has parents {trunk 21, X 20}." [07:27] Peng_: N parents [07:27] (Not that it has to be restricted to a simple chain.) [07:27] Peng_: hg has the 2 thing [07:27] spiv: Is rev 22 in X? [07:27] lifeless: Oh, I thought bzr did too. [07:27] davidstrauss: "and consequently some of its ancestors are X 19, X 18, etc." [07:27] Bazaar supports octopus merges? [07:27] Peng_: yes [07:27] Peng_: nope, 0 through to 'overflow a 4K b+Tree zlib page' [07:27] Peng_: which is 'many' [07:28] davidstrauss: this stuff is really ahrd to understand :) [07:28] hard [07:28] RenatoSilva: Is rev 22 on branch X? [07:28] lifeless: I hope that doesn't mean there will be some obscure index exception instead of a simple WhatTheHellAreYouDoingError. [07:29] "bzr merge" will let you do it? [07:29] Peng_: it will except on commit; and yes bzr merge will let you do it - --force [07:29] davidstrauss: I mean the whole subject [07:29] Given that rev 22 has parents X:22 and trunk:21 (according to spiv), it should follow that rev 22 is either on branch X or trunk, correct? [07:29] davidstrauss: I can't see it as anything different from the weird rev 22 { X 18, 19, 20 { trunk 18-21 } } [07:29] I meant "Given that rev 22 has parents X:20 and trunk:21 (according to spiv), it should follow that rev 22 is either on branch X or trunk, correct?" [07:30] davidstrauss: I'll just try to do it in pratice and see what happens [07:30] lifeless: Cool. I always figured --force would lose the other revision information or something, like with a cherrypick. [07:31] davidstrauss: yes, I'm talking about the example where X is merged into trunk [07:32] davidstrauss: e.g. "cd trunk; bzr merge path/to/X; bzr ci" [07:32] spiv: OK, this suddenly makes a bunch more sense. [07:32] spiv: I was assuming rev 22 was on yet another branch [07:32] Which AIUI was the example under discussion [07:32] But I might be wrong :) [07:32] davidstrauss: phew :) [07:32] spiv: and that's why i couldn't understand how it could have parents on two other branches [07:33]