[01:03] Question: How do you check to see if your local branch copy of a project is current? [01:03] so, I wrote a couple of Bazaar commands over the weekend. I'd like it if someone could look over the code and tell me if I'm doing anything gratuitously stupid: lp:~jml/+junk/bzr-establish [01:03] Without actually merging [01:04] Leefmc: bzr missing, I think. [01:04] nice, thanks [01:04] Leefmc: or you could do 'bzr merge --preview' [01:04] gotcha [01:08] Now if i have a /trunk and a lightcheckout of /trunk at /wrk, and im _in_ wrk, will merge commands and whatnot mess up my light checkout? In otherwords, do i need to do all merge previews and merges in /trunk and not /wrk? (ie, merge in trunk, and update my light checkout.. or something.) [01:08] they'll modify the checkout [01:09] and if you commit, modify /trunk [01:24] bob2: Ok i think i understand, but is that a good thing or bad thing? Is merging from the server to the working branch (lightcheckout) /wrk a bad thing? Should that server/client transactions be done in the real branch (/trunk)? [01:24] no, it is fine [01:28] You can't merge into a branch per se; only into a working tree. The working tree colocated with the branch isn't any more "real" than any other. [02:00] Does 'UserWarning: lock on not released' imply I've taken a lock on a tree object and not explicitly unlocked it? Or maybe a branch object? Any other clues? [02:01] markh: that you've taken a lock on a tree and not released it, yes. [02:01] spiv: thanks [02:06] are there any bzrlib api functions that implicitly take a lock for you and expect you to release it? [02:07] * markh wouldn't have thought so... [02:07] lifeless: Can you elaborate a little on what that means re manually zeroing errno? [02:07] markh: not that I can think of [02:09] fullermd: errno = 0; retvalue = readdir(handle); if (!retvalue) { if errno == XXX ()... [02:10] markh: I think DirState.initialize and maybe a couple others, but generally, no [02:11] markh: not sure if you're already considering this, but it could be a lock_read rather than a lock_write. [02:11] .oO( Why did I read that as DireStraits ?) [02:11] LeoNerd: because you're dreaming about getting Money for Nothing? :) [02:11] spiv: its the chicks; its always the chicks [02:11] jam: thanks. All the locks I can see correctly use finally, so its something subtle. I think I'm getting closer via 'print' debugging :S [02:12] lifeless: Mmm. Does readdir() even set errno? [02:12] fullermd: is that rhetorical? [02:14] Mmph. Blah, need to fix that manpage :| [02:14] I hate functions like that :| [02:15] fullermd: apue recommends this for all C library functions - set errno before calling if you want to consult it after for any reason other than 'I already know an error has occured' [02:15] fullermd: its the 'NULL -> EOF || ERROR' that makes readdir suck in this case [02:16] Yah. There's a half dozen functions with those sorta stupid dual meanings. [02:17] I don't recall that suggestion in the book, though. I don't think I've seen such a thing recommended elsewhere. [02:17] it's not prhased quite like that [02:17] quoting mwhudson quoting it [02:17] "There are two rules to be aware of with respect to errno. First, its value is never cleared by a routine if an error does not occur." [02:18] That's not quite always true. There are a few functions that will zero it first [02:19] well, eratta -> the author :P [02:19] Generally, because it internally calls one of those stupid ambiguous functions. [02:20] Wow, I've got a receipt for a muffler I bought 10 years ago serving as a bookmark in it, too. [02:26] * fullermd sighs. [02:26] It should take me less than 30 seconds to figure out why 'bzr diff' isn't working right in a CVS checkout :( [02:28] lifeless, why would you want to check errno if an error has not occurred? [02:28] i thought it's value was undefined then [02:28] poolie: Because some functions (like readdir()) have ambiguous returns. [02:28] It returns NULL for both "Done" and "Oops" [02:29] ah, i see [02:29] that's pretty crazy [02:30] istr there are other routines which tread on errno - changing the value from 0 even if an error did not occur [02:30] because one occurred at a lower level [02:30] Lots of them do. [02:31] You just have to know which of them have ambiguous returns. [02:31] spiv: just email bugs to me. [02:31] jml: but how will I know what their Status and Importance are? ;) [02:32] spiv: The planning committee will inform you in due course === kiko is now known as kiko-zzz [04:01] argh [04:01] jelmer: please please please please please please please please [04:01] jelmer: stop bzr-svn bitching about versions ? kthx [04:06] lifeless, uhm [04:06] lifeless, when does it do that? [04:06] $ bzr info [04:06] bzr-svn is not up to date with installed bzr version 1.8dev. [04:06] There should be a newer version of bzr-svn available. [04:06] bzr: ERROR: Version mismatch [04:06] it already doesn't if you're running a development (e.g. not released) version [04:07] jelmer: I run whatever branch you tell me to [04:07] jelmer: till it breaks, then I generally remove it until I actually need it [04:08] if (bzrlib_version in desired or [04:08] ((bzrlib_version[0], bzrlib_version[1]-1) in desired and [04:08] bzrlib.version_info[3] in ('dev', 'exp'))): [04:08] return [04:08] lifeless, what bzr-svn branch are you running? [04:09] I don't know, I removed the symlink already [04:09] sorry [04:10] I have a trunk, 0.3, 0.4 [04:11] trunk was most recently pulled into [04:11] 0.3 is waay outdated (and would rightly warn about being incompatible), the other two are marked as being compatible with bzr 1.7 [04:11] http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk/ [04:11] so shouldn't warn if you run bzr 1.8dev [04:11] jelmer: I should note, I don't pull plugins routinely [04:12] jelmer: I bet if I pull and build it will get your update to say 1.7 is ok [04:12] 2008-09-24 10:44 [04:12] is the last date on the trunk dir [04:13] the latest revision should be from about 10 hours ago [04:13] sure [04:13] I'm not saying you haven't updated it to say 1.7 is ok [04:13] that's interesting, you can using sigaction to say that system calls should be automatically restarted after particular signals [04:13] ah, sorry [04:13] I'm saying that *I haven't updated* and I wish it would not force me to to shut it up [04:13] it seems like this would fix bug 173007 for instance [04:13] Launchpad bug 173007 in bzr "SIGQUIT debugging breaks networking" [Medium,Triaged] https://launchpad.net/bugs/173007 [04:13] lifeless, so it sounds like you should update :-) [04:14] lifeless: There's no easy way to warn lazily [04:14] jelmer: uhm, thats the point, it interrupts workflow to force that, for instance on a train its hard [04:15] jelmer: sure, check the api minimum version rather than the bzrlib version [04:15] jelmer: and ask for module specific versions for more precise api's that you depend on [04:15] thats what we wrote that stuff for, to stop bzr-svn and bzrtools having to be so whingy [04:17] lifeless, what APIs have a separate version though? [04:17] there is no evolution at the moment because you're checking the bzr command version not the library api compatibility version; and we're not being granular about the library because noone is using it [04:17] start using granular apis and tell me what you're using and we'll start being explicit about those modules [04:18] but please don't claim a better way isn't possible - we discussed this, came up with a solution, I wrote the bzr end, and nothing has happened since [04:18] I'm claiming bzr-svn can't do better than this at the moment [04:18] I'll happily use other APIs that are available when they're there [04:19] and matter [04:19] import bzrlib.api [04:19] api.require_api(bzrlib.repository, (1, 6)) [04:20] the api is available [04:20] ok, fair enough [04:21] please file a bug [04:22] done [04:24] lifeless, i fixed 279381, and found quite a nice other bug right next to it [04:29] lifeless, just tried it out [04:29] lifeless, require_api() doesn't allow multiple versions [04:29] lifeless, which makes it impossible for bzr-svn to claim support for bzr 1.6 and 1.7 [04:30] bug 279447 [04:30] Launchpad bug 279447 in bzr "bzrlib.api.require_api() doesn't allow multiple versions" [Undecided,New] https://launchpad.net/bugs/279447 [04:33] lifeless, it also doesn't allow bzr-svn to provide any information about which API versions it itself provides, e.g. new arguments to functions can break code that calls out to bzr-svn [04:37] jelmer: so for the former [04:37] jelmer: are you doing conditional stuff in bzr-svn? [04:38] jelmer: or is it just that the bzrlib api update wasn't granular enough? [04:38] lifeless: both [04:38] for the latter I'm not all that concerned, once we know what you're using and have api versions in place it should stop being an issue [04:38] erm [04:38] yes, but that will still hurt people in the mean time [04:38] for 'wasn't granular enough' ^ [04:39] I run both bzr.dev and bzr 1.7 with the same bzr-svn [04:39] jelmer: secondly, it raises incompatible version - you can probe twice [04:39] try: [04:39] api.require_version() [04:39] except IncompatibleApi: [04:39] using bzrlib.api.require_api() will break [04:39] api.require_version() [04:40] we can add a require_any_version(object, version_list) if you like [04:41] that would be nice, otherwise I have to add utility functions that myself [04:41] jelmer: as for "doesn't allow bzr-svn to provide any information about which API versions it itself provides" - I'm not sure what you mean there [04:42] lifeless, If a new argument is added for e.g. Branch.update_revisions(), does that mean the minimum_api_version and api_version are both updated? [04:42] even if a default value is set for that argument? [04:42] jelmer: yes [04:42] ok, that addresses my concern [04:42] jelmer: we can also look at being more precise [04:43] jelmer: e.g. we could have bzrlib.branch.client_api and bzrlib.branch.provider_api [04:43] jelmer: the big problem is that noone is using this stuff [04:43] another thing is that the error message from require_api() is not shown to the user - bug 279451 [04:43] Launchpad bug 279451 in bzr "IncompatibleAPI error should not be masked by "could not load plugin error"" [Undecided,New] https://launchpad.net/bugs/279451 [04:44] jelmer: so I can write tweaks to it and it still won't fit what you need: you have to tell us, and I will fix the things you tell me, and we'll iterate [04:44] jelmer: I'll add a multi-version require [04:44] I'm not sure about the second, it sounds like the could not load plugin error hack is broken [04:45] or perhaps 'import foo' is translating the error to ImportError [04:45] I just get "Unable to load plugin 'svn' from '/home/jelmer/.bazaar/dev-plugins'" if IncompatibleAPI is raised by bzr-svn [04:46] lifeless: Thanks - I'll happily migrate once it's at the same level as it is atm [04:46] jelmer: try python -c 'import bzrlib.plugins.svn' [04:46] bzrlib.errors.IncompatibleAPI: The API for "" is not compatible with "(1, 7)". It supports versions "(1, 7, 0)" to "(1, 7, 0)". [04:46] jelmer: ok, so its the bzrlib wrapper that needs tuning [04:57] poolie: whats the standard for bazaar plugin maintainers now? [04:57] a high standard :) [04:57] I mean [04:58] more specifically? [04:58] what group [04:58] should they join on launchpad? [04:58] no [04:58] what group should be the maintainer for a new plugin [04:58] whats the meta group, is it still 'bzr' ? [04:58] or is it different [04:59] launchpad.net/~bzr explains that ~bzr is the overall thing, ~bzr-core is for just bzr itself [04:59] therefore, plugins can either get their own group of which ~bzr is a member, or just be owned by ~bzr [05:01] lifeless, speaking of (vaguely) this kind of thing, you have an approved patch "make dist includes plugins" [05:01] should we just do it, or withdraw the patch? [05:01] http://bazaar-vcs.org/BzrMigration doesn't mention lp's code import service; hmm [05:02] poolie: there is a note in the comments/thread/etc about that patch, it doesn't run setup.py for plugins, so e.g. bzr-svn will fail [05:02] ok [05:02] I said in the thread that I might get back to it 'eventually' but that we probably need that to go forward [05:02] does that mean we can use it but just not include bzr-svn? [05:02] and if someone else wanted to that would be loverly [05:02] poolie: yah, anything trivial will just work [05:03] poolie: 'trivial' -> bzrtools, bzr-loom, etc [05:04] mwhudson: oh lol; when will launchpad support --development2 ? :> [05:05] lifeless: i sent you an email about that [05:05] mwhudson: did you? cool [05:06] I have lots of mail [05:06] could i beg a review from someone for the bug 279381 fix so it can go in 1.8rc1 [05:06] Launchpad bug 279381 in bzr "_readdir_pyx.pyx in python 2.5 causes errors with bzr" [High,In progress] https://launchpad.net/bugs/279381 [05:07] mwhudson: any hint on finding it? [05:08] lifeless: well, not really, but i sent a mail saying that something like bazaar.edge.launchpad.net would make it a lot easier [05:09] fullermd: https://code.edge.launchpad.net/~bzr/bzr-cvs/trunk [05:09] fullermd: I'm just about to 'upgrade' it to pack-0.92 [05:09] fullermd: but if you're in the bzr group you can read it direct from the writable area [05:11] Huh? [05:11] fullermd: ? [05:11] In reference to what? [05:12] 12:25 < fullermd> It should take me less than 30 seconds to figure out why 'bzr diff' isn't working right in a CVS checkout :( [05:14] fullermd: ^ [05:15] Oh :p [05:15] Yeah, I'm still short a month and a hundred gigs of space to do the conversion... [05:15] fullermd: you don't need to [05:15] fullermd: install that plugin [05:16] Yah, but it offers me conversion options, is my point :p [05:16] fullermd: thats to be helpful [05:16] fullermd: it will stop the confusion though [05:16] Well, ending the use of CVS will do that too :) [05:17] It's the VCS version of bug 1 after all. [05:17] https://bugs.launchpad.net/ubuntu/+bug/1 (Won't display info) [05:17] lol [05:18] anyhow, quick hack done, install it or not :P [05:18] but don't complain about taking 30 seconds to realise its CVS in future :> [05:22] mwhudson: is there some way to trigger mirrors yet ? [05:22] spiv, still here? [05:23] lifeless: the api might work at last, i haven't tried for a while [05:23] https://code.edge.launchpad.net/~bzr/bzr-cvs/trunk [05:23] its hosted, pack-0.92 *now* [05:23] poolie: yeah [05:23] been > 5 minutes, no change [05:23] could you read http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480810062029v75a37f54qb79c168f3b81cab2%40mail.gmail.com%3E for me quickly? [05:25] poolie: looks wrong to me: [05:25] poolie: EINTR is ctrl-C yes? [05:25] no, that's sigint [05:25] I thought it was one of those dual-arrival-path things [05:25] like SIGPIPE/EPIPE [05:26] http://www.wlug.org.nz/EINTR [05:26] it will happen if for example somebody suspends the process or resizes the window while you're in that system call [05:27] it looks like you have altered ENOENT's behaviour [05:28] i don't think i did, but i do notice that it's inconsistent with the comment [05:29] i think that in both the before and after versions, we terminate the loop successfully on getting enoent [05:29] lifeless: the ENOENT behaviour looks the same to my eyes [05:29] i.e. ENOENT -> continue [05:30] bb:approve [05:30] i inverted the sense of that test for (subjective) clarity [05:30] spiv: continue will exit the loop, I think poolie is right it was inconsistent with the comment [05:30] mvo: hi1 [05:30] so the comment should be s/swallow this and continue/treat this as the end of the directory [05:31] poolie: I also voted bb:approve, but technically it should bb:tweak because I pointed out an unnecessary semi-colon ;) [05:31] poolie: actually I suspect all those special cases were due to the missing errno=0 [05:31] linux doesn't document that it can happen and http://www.opengroup.org/onlinepubs/009695399/functions/readdir.html is unclear about how it should be handled [05:31] the eintr thing is definitely wrong and potentially quite scary [05:31] as i said [05:31] anyhow thanks [05:32] hey lifeless [05:32] I don't know that EINTR can happen here; it backs onto getdents - Id need to read through [05:32] but its not a bad condom to have [05:32] hi mvo [05:33] I saw your mail, I don't have any handy suggestions, that looks like storm complaining about something [05:34] lifeless: thanks, I had hoped you had some sort of magic bullet. I look into it again then (squeeze it in between the ubuntu beta bug squashing) [05:34] i wonder if i should just delete the enoent case [05:34] neither treating it as eof (and potentially missing things) or retrying (and spinning) is very desirable [05:36] poolie: I suggest not at this point, rather get this change in [05:37] poolie: and do a test branch people can test with other changes; pqm is not a good assessor for this [05:43] is 1.8 still open ? [05:47] poolie: ^ [05:47] yes [05:47] but i'm planning to start making it soon [05:47] I'm asking because I've got a little api patch for jelmer [05:48] I don't care if it goes in 1.8/1.9, but the docstring needs a version :P [05:52] I love bzr-search sometimes :) [05:52] :!bzr search -d ../bzr.dev Unable to load plugin [06:01] jelmer: [06:01] :!./bzr st [06:01] Unable to load plugin 'cvs'. It requested API version (1, 0, 0) of module but the minimum exported version is (1, 7, 0), and the maximum is (1, 8, 0) [06:01] jelmer: better? [06:31] Good day. I'm trying to solve a particular problem in arranging a branch history, and wondered if anyone could help me with a recipe. [06:31] hey [06:31] maybe [06:32] Specifically, I want to revert about 20 commits from trunk to get back to an older version, add some patches that were applied back then in some new revisions, and then reapply the changes to trunk as a base for a new revision. [06:32] (this is a workaround for a package only partially managed in VCS in Ubuntu) [06:33] ok [06:34] so if i were in this situation i'd think about just being lazy and applying the old changes on top of your current tip [06:34] otherwise, you should look at launchpad.net/bzr-rebase to rewrite the revisions [06:36] bzr-rebase looks like what I want, but it seems to assume I have a clean starting point. Is there perhaps a means by which I can start a branch from an earlier revision? [06:36] sure [06:36] bzr branch -r 123 . ../rewritten-trunk [06:36] for instance [06:37] then work over there, and when you're sure you're happy, bzr push --overwrite into your publishing location [06:37] Thanks! That's precisely what I want. That way I can pull the old version, apply the patches, and bzr merge will do the right thing. Thanks! [06:37] you're very welcome [06:37] * persia deletes everything [06:38] !! [06:38] I work with patchsets. quilt is very comfortable for me. replaying the set of changes I made is trivial, but I need to rebranch to get clean history. [06:39] I'm pretty sure rebase can do what you want from an older base [06:40] lifeless, Hrm? There's only one extant branch, which has more in it than I want. My first attempt included reverting stuff that I then wanted to unrevert. bzr branch -r makes it trivial to get it right. [06:41] persia: I may be wrong; you have a something that works now though, so cool - use that [06:48] hi all [06:49] hm, our extern decl of errno doesn't quite work for it to be assigned [06:49] this may be tricky [06:49] as it's not a real variable... [06:51] not necessarily a real variable anyhow... [06:52] usually isn't [06:55] ah, "global errno" [06:56] python scoping yay [07:09] regarding bug #277537, I found a problem exhibited here: http://paste.ubuntu.com/54894/ [07:09] Launchpad bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [Undecided,New] https://launchpad.net/bugs/277537 [07:09] ubottu: thats due to merges, its not a bug [07:09] Error: I am only a bot, please don't think I'm intelligent :) [07:10] And I just came across a comment saying: '# we hope there are no repositories with inconsistent parentage anymore.' in knit.py [07:10] Did I found such a repo ? [07:10] vila: well, I'll have to look I guess [07:10] vila: but I suspect its linear-expectations confusing people [07:11] seen my paste ? [07:11] annotate is provided with parent in wrong order, which is the cause of the wrong annotation [07:11] s/parent/&s/ [07:13] lifeless: here is the script I used: http://paste.ubuntu.com/54897/ [07:13] branches built as explained in https://bugs.edge.launchpad.net/bzr/+bug/277537/comments/3 [07:13] Launchpad bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [Undecided,New] [07:14] ubottu: you just said that, pay attention please :) [07:14] Error: I am only a bot, please don't think I'm intelligent :) [07:15] hey vila [07:15] hey :) [07:17] i have to say that's really not one of python's nicest features, that adding an assignment statement changes the meaning of references to that variable occuring earlier in the text [07:17] i understand what's happening but it's still gross === gour_ is now known as gour [07:20] jelmer: pong [07:42] lifeless: Tell me where you end up before leaving and if you think I can continue from there (sounds a bit hairy to me, but yet, I didn't think I could go that deep before trying either) [07:43] vila: I probably won't look at it this week [07:43] vila: I was simply commenting [07:44] oh :-/ [07:46] lifeless: may be you can give some hints about that comment then ? A way to find if parentage *is* inconsistent in that repo ? [07:47] 'bzr check' [07:49] ouch, I can go fix some coffee then :) [08:57] lifeless, if you're still here, what was it that you wanted to merge into 1.8? [08:57] oh the api thing [08:58] poolie: I put 1.9 in the docstring [08:58] so you did [08:58] i was just looking at it [08:58] poolie: as it sounds like 1.8 is basically baked [08:58] i'm just seeing if a knife comes out cleanly [08:59] ?! [09:00] lifeless: were you using 'baked' in a more colloquial sense? [09:01] The old murder/cake confusion. [09:03] First you will be baked, then there will be cake. [09:04] jml: no, I'm just sufficiently tired that following my sentence and poolies reply stumped me [09:04] lifeless: :) [09:05] Rest assured that there is absolutely no chance of a dangerous equipment malfunction prior to your victory candescence. [09:10] you want me to DE before VC ? [09:11] abentley: In the 'merged' messages Bundle Buggy sends, would it be possible to show the revision number in which the change was merged, or would that cause considerable extra grief? [09:12] * Odd_Bloke is trying to mark a bug as Fix Released, and likes to mention when it was merged to bzr.dev so people can be sure they have the fix. [09:13] Odd_Bloke: Launchpad should so do that for you. [09:13] * jml waves his hands a bit [09:14] jml: Less waving, more coding! :p [09:15] Odd_Bloke: I'm waiting for some tests to run :) [09:15] Oh. Carry on. [09:17] One thing that would be nice to do in LP is to link a bug report to an arbitrary URL, which Launchpad then goes and mirrors for you, unlinking it if the URL isn't mirrorable. [09:28] jml/lifeless, i was referring to cookbook instructions as to when a cake is cooked [09:30] poolie: yeah, I guessed. [09:30] but thanks for the Portal reference [09:31] > "1953 - Aperture Science begins operations as a manufacturer of shower curtains. Early product line provides a very low-tech portal between the inside and outside of your shower. Very little science is actually involved. The name is chosen to make the curtains appear more hygienic. [10:21] poolie: heh [10:21] poolie: where's that from? === mneptok_ is now known as mneptok [10:57] Could someone have a look at this for me please - http://pastebin.ubuntu.com/54943/ - i have a problem pushing with http. Giving me you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. I am using --use-existing-dir [11:10] stefanlsd: try pushing to bzr+ssh://bazaar.launchpad.net/~stefanlsd/mplayer/devel [11:12] stefanlsd: what led you to try pushing to http://code.edge.launchpad.net/...? [11:14] stefanlsd: Actually, you probably need "bzr push bzr+ssh://stefanlsd@ssh://bazaar.launchpad.net/~stefanlsd/mplayer/devel" [11:15] stefanlsd: Or more simply, "bzr push lp:~stefanlsd/mplayer/devel" (do "bzr launchpad-login stefanlsd" first if you've never run "bzr launchpad-login" before). [11:20] spiv: mm. i wanted to do http as im going thru a proxy... [11:21] stefanlsd: Launchpad doesn't offer any way to push to a branch via HTTP at the moment. [11:21] Only via sftp/bzr+ssh. [11:22] spiv: aah. that sucks :) - so you can only branch from http currently? [11:22] That's right. [11:22] spiv: kk. thanks for that. === Freeky is now known as Freaky [13:31] Odd_Bloke: It would be a bunch of extra work, because Bundle Buggy doesn't currently determine which new revision merged the change. [13:46] abentley: OK, don't worry about it. [13:46] abentley: If I were to look into it sometime, would you be open to a patch to do it? [13:47] Odd_Bloke: certainly. === doko_ is now known as doko === Guest448` is now known as Leonidas === Mathilda is now known as uws [14:51] hi, does anybody know if there is any Bazaar plug-in for visual studio 2008? === kiko-zzz is now known as kiko [15:01] how do i see the version of bzr on a remote server, like bazaar.launchpad.net? [15:01] other than the web interface :-) [15:04] sabdfl: I'm not sure whether we can do that. [15:04] I can grovel the code... [15:05] So I have a varchar() column in my database, when I try to save something like P4_testCases, I get the following message:/mysql/base.py:83: Warning: Data truncated for column 'project_id' at row 1 [15:05] any ideas? [15:05] wrong channel :D [15:07] <__lucio__> hi. bzr question: im trying to merge my branch into trunk, but bzr merge thinks trunk is newer, so its removing my changes. same thing if i merge trunk into my branch. what can i do? [15:09] __lucio__: How do you mean 'removing your changes'? [15:10] <__lucio__> Odd_Bloke: i have more lines in the new branch, but when i merge with trunk, the lines are gone. [15:10] __lucio__: Have you committed them? [15:10] <__lucio__> its trying to make my branch look like trunk, not trunk look like my branch [15:10] thanks abentley. would be a nice little hpss patch if we can't already do it [15:10] bzr version URL [15:10] <__lucio__> Odd_Bloke: yessir [15:11] __lucio__: And you're just running 'bzr merge '? [15:11] <__lucio__> Odd_Bloke: trunk$ bzr merge $MY_BRANCH and mybranch$ bzr merge $TRUNK [15:12] sabdfl: Yes, grovelling the code suggests we can't do it yet. [15:12] __lucio__: Can you make these branches publically available? [15:12] thanks abentley for checking it out [15:12] <__lucio__> Odd_Bloke: not really. are you in canonical? [15:12] __lucio__: Nope. [15:13] sabdfl: np. I'm taking Community Help Rotation to new levels :-) [15:14] abentley: Speaking of which, can you help __lucio__? I'm at something of a loss (and meant to be working :p). [15:15] __lucio__: when you split the branch did you use "revert" at all? [15:15] <__lucio__> one clue: i may have branched the full branch and removed some of the code there. that branch is in trunk now. [15:16] <__lucio__> james_w: i dont remember. [15:17] yeah, I've you've reverted the bits left in your branch in something that has ended up in trunk then I think bzr will consider them unwanted and not merge them,. [15:17] I'm not sure what debugging flags we have for merge [15:19] Odd_Bloke, __lucio__: bbs [15:19] james_w: -Dmerge is it. [15:21] thanks abentley [15:21] __lucio__: could you run again with "bzr merge -Dmerge $MY_BRANCH" please? [15:21] <__lucio__> james_w sure [15:22] __lucio__: if there is no extra output then it means it goes in to ~/.bzr.log [15:22] james_w, what's happening is actually expected [15:22] he had 1 big branch [15:22] hey beuno [15:22] branched from that [15:22] and deleted all the branched lines from the second and first one [15:22] merged the first one [15:23] and is now merging the second one, which is the parent of the first, and deletes it's lines [15:23] hi :) [15:23] ah, rubbish [15:23] do you know of a way to get the result he wants? [15:24] my guess would be that he may be able to, either merge, commit, and merge from the old revision again [15:24] james_w: merge, revert text changes, commit. [15:24] that's it [15:24] what abentley seaid [15:24]