s in most places which require content to be replaced, but this causes linebreaks around it. Is there a better element to use, or do I need to add 'tal:omit-tag=""' to all of them? [11:05] james_w: yeah [11:05] james_w: neobug, emilis_info, cyberix and mhammond are also here right now. [11:06] james_w: The two Italians (I don't know their names unfortunately) are having lunch. [11:06] :) === cprov is now known as cprov-lunch [11:10] Odd_Bloke, well, span elements won't add line breaks [11:11] Odd_Bloke: use

[11:11] instead of tal:content=... [11:32] neobug, emilis_info: so how are you doing? :) [11:34] LarstiQ: I fixed that bug with spaces in editor path, now writing the test [11:36] neobug: cool [11:38] poolie: hi; I'll ring you in a minute [11:50] emilis_info: to summarize, you're looking at bug 109115, you're looking at code to see what the codepaths are that call bytes_to_gzip()? [11:50] Launchpad bug 109115 in bzr "nicer error when unable to commit large files" [Medium,Confirmed] https://launchpad.net/bugs/109115 [11:50] LarstiQ, yep [11:50] I'm trying to find the correct place to show the error [11:51] right [11:51] now int repository.py ... record_entry_contents() [11:51] s/int/in/ [11:53] emilis_info, LarstiQ: rockstar was looking at that bug the other day. I think he was working out how to test it. [11:54] james_w, I have some shell code that reproduces it [11:56] rockstar: ayt? [11:57] Jc2k: ping === Tank|Away is now known as Linnk [12:37] Hi. What is the best way to put a local bzr branch into a new branch on a pristine svn repository (no branches yet). I tried push but got "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified." === bac|away is now known as bac [12:39] ChristopheT: bzr svn-push [12:40] ChristopheT, There's an open bug about this [12:41] jelmer: indeed, I get "bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ('Delta does not fill the target window', 185003)" [12:41] ChristopheT: Hmm, that bit is not expected actually [12:41] ChristopheT, What version are you running? [12:42] LarstiQ: hi === SteveA_ is now known as SteveA [12:42] bzr 1.6b3, bzr svn 0.4.11exp0. I will pull the lastest version of bzr-svn [12:42] ChristopheT: This is most likely a regression in 0.4.11 [12:44] jelmer: I still eget the same exception [12:44] ChristopheT, is this a public branch you're trying to push? [12:44] ChristopheT: With 0.4.10? [12:44] hi jelmer :- [12:44] ) [12:45] jelmer: I am trying to push to svn+ssh://svn.forge.ocamlcore.org/svnroot/pa-do/trunk [12:45] SteveA: Hoi Steve [12:45] I have the rights to do so [12:45] ChristopheT: What branch are you trying to push? [12:45] jelmer: Hi, interested in bzr2svn here. SteveA said it'd be... useful. [12:45] olleolleolle: Hi [12:46] Thinking of using its API to avoid lotsa munging and collecting SVN metadata. bzr2svn could be a friend in that case, I hope. [12:47] olleolleolle: What sort of metadata would you ike to gather? [12:48] ChristopheT: What branch are you trying to push? [12:48] "Gimme all the diffs from rev 0 to now," so I can visualize it nicely. I had started with "svnadmin dump" output. [12:48] ChristopheT: Can you run with BZR_PDB=1 set? [12:48] is bzr2svn a Tailor script? [12:49] jelmer: I did a "svn co https://pa-do.svn.sourceforge.net/svnroot/pa-do" and a "bzr branch my-branch trunk"; can I just add, commit and push? [12:49] olleolleolle: bzr-svn is a bzr plugin, there's also svn2bzr which is a python script [12:49] ChristopheT, yeah, you should be able to [12:50] jelmer: BZR_PDB=1: I am in the debugger. Now what do I do? [12:50] Thanks, jelmer. [12:50] olleolleolle: Are you interested in the unified diffs as text or rather the semantical information? [12:50] jelmer: my thought was, if they're working on visualizing revision history, then using bzr's API is going to be a good thing to use. [12:51] (unified diffs as text, I think. I am kinda making a "terrain map of my code") [12:51] SteveA: Ah, that makes sense [12:51] jelmer: and, as it's reasonably easy to either convert a SVN repo to bzr format, or to interact with it using bzr-svn, then that makes it a good plan. [12:52] jelmer: It starts with [12:52] **** entering debugger [12:52] > /home/trch/.bazaar.dev/plugins/svn/commit.py(539)commit() [12:52] -> lock.unlock() [12:53] olleolleolle,SteveA: Just running "bzr viz" on a Subversion repository should work [12:53] ChristopheT, Can you pastebin the backtrace ("bt") somewhere? [12:53] jelmer: I'm flying back to amsterdam shortly. see you later. olleolleolle's going to keep hacking on this here :-) [12:54] SteveA: Ah, you're at EuroPython? Have a good flight [12:55] olleolleolle: Are you looking to just browse the history of your project or actually generate a report with all the diffs, etc? [12:55] generating a report, painting a picture, using that information, yep. [12:56] Dumb q: When I install the bzr-svn plugin, is it enough to do "sudo python setup.py install"? Or is there a step I am missing? [12:56] jelmer: .bzr.log: http://pastebin.com/d2a21fd36 [12:57] olleolleolle: No, that should be sufficient if you've also got bzr itself installed [12:57] I installed bzr 1.5 using the Installeer for OS X 10.5. [13:00] olleolleolle: You will also need to have the Python Subversion bindings (with several patches) installed if you're using a released version of bzr-svn [13:01] This is a bit of a pain at the moment, but necessary because there are several bugs in the bindings that bzr-svn otherwise hits [13:01] Oh, thanks. The reason I tried to avoid MacPorts was that... I have a functioning Python that I don't want to break. I'll go look for the bindings now. [13:01] Alternatively, you can use the development version of bzr-svn which only requires the (vanilla) Subversion development headers are present [13:02] Sounds good to me. [13:03] ChristopheT, thanks === bac is now known as bac|away [13:25] blegh, annoying netsplits... [13:25] ChristopheT, Hmm, doesn't help much determining what's wrong :-/ [13:26] jelmer!! [13:26] jelmer: je werd genoemd! [13:26] uws!!1!!!!1!1!!ONEONE! [13:27] jelmer: ging over bzr-svn en bzr mirror van gnome [13:27] hello uws [13:27] hi poolie [13:27] ah, cool [13:27] hey poolie [13:28] you're at europython? [13:28] uws, is de beslissing al gevallen? [13:28] uws, no, I'm in dublin [13:28] uws, @ wilmers [13:28] dinner [13:28] * uws at guadec [13:29] night [13:31] http://people.samba.org/bzr/jelmer/bzr-svn/ Is the development version "trunk" or "bzr.dev" ? [13:31] (Am looking for bzr-svn, still.) === bac|away is now known as bac [13:40] support? [13:40] humm no bot then. [13:40] :) [13:40] sorry, i just filed a bug (which may be a dupe). if its a dupe hope one of you lot can pick it :) [13:43] 247270 (fwiw). ineternet connection just let the bug through :| [13:46] jelmer: "doesn't help ...": anything else I can send you? === mw|out is now known as mw [13:46] a_c_m: Hi. :) [13:47] Odd_Bloke: hey, just formulating a massive message asking my question ;) [13:47] a_c_m: Cool. [13:48] I have what i hope is a common situation that i'm looking for a nice solution for - which i hope bzr is. We are a small, but growing drupal development shop, So we depend on CVS updates from drupal.org. We also want to have our own mini versions of the core drupal.org CVS which our projects looks to as thier source e.g. drupal.org --[updates]-->our drupal version--[updates]-- [13:48] >our projects [13:48] is such a thing possible / easy to do? [13:50] hi a_c_m [13:50] hi james_w [13:50] at https://code.edge.launchpad.net/drupal launchpad provides an import of drupal CVS you could base your work on [13:50] you can also see branches other people have made based on that [13:51] what you could do is branch the main copy and make your changes, and then distribute that for your shop to base their work on [13:51] poolie: I think there should be two mails to the list that need approval, could you approve them? [13:51] then every day or few days you can grab the latest from drupal CVS with "bzr merge lp:drupal" [13:52] james_w: exactly! so that when a new version comes out, we update our branch and test it, before pushing it out to the sub projects [13:52] that should work nicely [13:52] james_w: i think we will only ever take releases from the drupal.org upstream (is upstream the right term?), as otherwise it could become a lot of work [13:53] in that case you can just run "bzr merge" when upstream releases. [13:53] I don't know drupal's release strategy, do they release from trunk, or do they make branches? [13:54] james_w: branches... i think as trunk is waaaay ahead of where the stable release are [13:54] hmm, not sure how cscvs deals with branches [13:55] you may want to enquire about launchpad mirroring the stable branches as well for you, as that may suit you more [13:56] james_w: humm... wouldnt it be simpler just to import the drupal.org branch myself? [13:56] james_w: locally? [13:57] olleolleolle: I'm currently a bit wound up, but if you want to grab me later to discuss things here at EP, you're welcome :) [13:57] a_c_m: possibly, I have no experience with importing CVS to bzr, and how painful or not it may be, so I thought that if launchpad could do it for you it may save you some work. [13:58] james_w: heh, fair enough - seems like somthing people might use too, drupal is quite popular ;) do you know who i would need to talk to? === Christop` is now known as ChristopheT` [13:58] LarstiQ: sure [13:58] james_w: but also do you know any good tutorials on setting up that kind of staged upstream system? [13:59] olleolleolle, http://people.samba.org/bzr/jelmer/bzr-svn/0.4 [14:00] a_c_m: there are a couple of people that hang around here, but they are at the wrong end of the world for you at the moment I expect [14:01] k well i will hang about in here for a while, guessing the are US based right? [14:01] a_c_m: there is #launchpad, but I think one of the best ways might be a question on launchpad on the launchpad-bazaar project. [14:01] a_c_m: the best person to ask is actually antipodean, but one of the US guys might know [14:02] james_w: going to do some more reading and a bit of playing now - sink a few hours into it;) [14:02] kgoetz: hi, are you using a proxy by any chance? [14:03] james_w: i *shouldnt* be [14:03] bzr log foo/ --> shows me the initial import of the directory. bzr log $(find foo/) gives me an error. [14:04] james_w: i dont seem to be ($http_proxy and $HTTP_PROXY are both empty) [14:04] so... how do I get a log of all the changes to all the files in a directory? [14:04] "iteration" is not the answer I want to hear [14:06] lamont: I'd think bzr log foo/ would do that. Hmm. [14:06] * beuno has seen this discussion before, but can't remember the outcome [14:06] LarstiQ: that was also my foolish notion [14:07] lamont: so what does it show for you? Just a single log entry that reflects the initial import? [14:07] lamont: there is a long open bug about that [14:08] https://bugs.edge.launchpad.net/bzr/+bug/97715 [14:08] Launchpad bug 97715 in bzr "bzr log DIR should show changes under dir" [Medium,Confirmed] [14:08] markh: yep [14:10] james_w: seems like bzr-fastimport might be of use to me... [14:10] a_c_m: yup === ChristopheT` is now known as ChristopheT [14:13] jelmer: I have this error "bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'lstrip'" when I do "bzr log --line" on a svn co (http://pastebin.com/d7e817d3c) [14:17] beuno: Thanks for the speedy suggestions. :) [14:18] anybody got an idea on why it takes 4 or 5 hours to push a mysql branch to launchpad? (even when it's my 2nd branch). Does launchpad not use a shared repo ? [14:19] hello,In SVN I can do svn:externals on dir props... is there a way to do sth like this in Bazaar repos... [14:19] ? [14:20] hi, I've once again a 'is it a bug or a feature'-question: [14:21] when I do bzr log -r -2.. i get the text of the last two changes [14:22] when I run bzr diff -r -2.. I get the diff from the last commit until now [14:22] Odd_Bloke, glad to help :) [14:22] for me it looks like inconsistency [14:22] jelmer: No decision yet [14:22] Could someone try pulling http://www.datadictionary.nhs.uk/software/dd-publish for me? [14:23] so it looks more like a bug, any opinions? [14:24] thekorn: Not sure I understand what you think is inconsistent, but log is a repository-querying command, while diff can peruse both repository and working tree. [14:24] stewart: no, it does not, there is development right now to make this much quicker [14:24] james_w: that'd be nice. as right now it's unusable for collaboration, 5+hrs is a long time. [14:25] hi thekorn, there is reasoning for this I believe, I'm just trying to dig it out of the depths of my brain. [14:25] hmeland, ok, but this is something I as a user do not know, I expect '-r -2..' to return not confusing results [14:26] james_w, hey, ok, thanks :) [14:26] hmeland: it's not due to the working tree, the effect is visible even with no uncommitted changes [14:26] Ah, I didn't spot that you said "the last" on "diff -r -2..". [14:26] hello,In SVN I can do svn:externals on dir props... is there a way to do sth like this in Bazaar repos...? [14:26] hmeland: make it -r-2..-1 and you get the same discrepancy [14:27] pax: not currently, no [14:28] my usecase is: a contributor tells me he changed something in his last two commits, so I run bzr log -r -2.. to see his messages, [14:29] and after this I would like what he changed, so I intuitively run bzr diff -r -2.. [14:29] I still think the repository-only/repository-and-tree difference is relevant, though. [14:30] thekorn: yeah, I can't remember the reason, sorry. I imagine that if you change this you get some weirdness showing up elsewhere [14:31] Say you commit a change, push it, then decide you want to revert it. You bzr revert, but want to verify that your tree now really doesn't have any differences wrt. how it looke before the erroneous commit. What options should you give to bzr diff? [14:31] though I do think having log not show the start of the range would be reasonable. [14:32] hmeland: "bzr diff -r-2.." isn't it? [14:32] james_w: So "bzr log 1.." shouldn't show the first commit message? [14:32] hmeland: correct [14:33] that's one thing that would be weird at least [14:33] thekorn: you could file a bug, I have a hunch it would be closed, but at least you would get a reason :-) [14:33] :) [14:34] ok, will do [14:34] thanks hmeland and james_w [14:35] james_w: Yes, exactly -- "diff -r -2.." gives you the diff from *just before* the most recent commit until the current tree state. [14:35] atleast it is maybe a documentation issue: both help (bzr help diff and bzr help log) are refering to "help revisionspec" [14:36] and a difference is not mentioned there [14:36] yeah, mention that in the bug [14:37] revisionspec mentions nothing about ranges as far as I can see, and the individual command should probably mention how they interpret the range [14:39] Anyone serve Bazaar repos from IIS? === bigdo1 is now known as therv1 === therv1 is now known as bigdo1 [14:41] revisionspec says that "-2 is the second-to-last commit", and bzr help diff says that "bzr diff -r1..2" is the difference between rev 2 and rev 1. Doesnt that infer that "diff -r-2..1" is the difference between the second-to-last commit and the current tree, i.e. for an unmodified tree the changes introduced by revision -1? [14:41] I think there's something I'm not getting here... :-) [14:42] Sorry, s/-r-2..1/-r-2../ [14:43] hmeland: when you leave off the second revision, it means "the state of the working tree" [14:43] Yeah, hence my "for an unmodified tree" reservation. [14:43] but if you use -1, it means "the most recent revision", so the distinction is whether it includes uncommitted changes [14:43] hmeland: what you said sounds right [14:44] hmeland: If you want the diffs from the past two revisions, try -r-3..-1 instead. (it's off by one) [14:45] yeah, "the difference between the second-to-last revision and now" won't include the change that *caused* the second-to-last revision [14:46] I'm just trying to understand why people think the difference in the amount of revisions included in the reports "bzr log -r -2.." vs "bzr diff -r -2.." is a bug. [14:46] They both appear sane to me. [14:50] I like the way .pack files are named for their md5sum [14:51] Ok ; I'm trying to dumb-serve a repo from IIS ; why am I getting "Expected a boundary" errors [14:51] Expected (q1w2e3r4t5y6u7i8o9p0zaxscdvfbgnhmjklkl) line, got '-- [14:51] It looks really close, anyone know what the problem is? [14:51] awilkins: is there a proxy involved? [14:51] question: how come i'm getting moved files reported as removed and added? [14:52] james_w: If you wget the file, it matches it's MD5 [14:52] more importantly, how will this affect merges [14:52] stewart: did you move them with "bzr mv"? [14:52] james_w: i think so... but may have accidently run "bzr add" on them... [14:52] hmeland: Since log shows 3 revs worth of changes and diff shows 2, it could be considered confusing. [14:52] james_w: There is a proxy, probably [14:52] james_w: (after having bzr mv) [14:52] james_w: I am not privy to the secret machinations of the NHS network provisioning team [14:53] james_w: any way to retro-actively bzr mv (i haven't committed yet) [14:53] stewart: if you used "bzr mv" first then "bzr add" wouldn't have done anything [14:53] stewart: try "bzr mv --after" [14:53] stewart: if that doesn't work then "bzr rm --keep" the new name and then "bzr mv --after" [14:54] awilkins: I'm thinking of https://bugs.edge.launchpad.net/bzr/+bug/198646 [14:54] Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released] [14:54] awilkins: bzr is used in the NHS? :-) [14:54] james_w: Well, the project isn't finished yet, but yeah, I guess it is. [14:55] james_w: I'm going to add it to the Hall of Fame when I get a sign-off on this project [14:55] james_w: seems to be working, thanks! [14:56] awilkins: cool [14:56] james_w: bzr AND bzr-eclipse :-) [14:56] stewart: did you have to "rm"/ [14:56] james_w: yes, did have to "rm --keep" and then mv --after for each one [14:56] stewart: good to know, thanks. [14:57] james_w: Plus bzr-gtk (local branch thereof) [14:57] james_w: We're using my home-built 1.6b2 ATM because it's so much faster than 1.5 [14:57] james_w: But I've been tracking the tip of many things .... [14:59] * CardinalFang waves to guilhembi. [15:00] Hi CardinalFang , but what's a Fang? [15:01] guilhembi, The name is a Monty Python reference. It seemed fitting in #python a few years ago. [15:05] ToyKeeper: I see your point, but I don't think it holds up; for example, I find it entirely reasonable that "bzr log -r1..1" reports one revision, while "bzr diff -r1..1" reports no changes. [15:20] LarstiQ, I am now. [15:22] a_c_m: By the way, if you are trying to use Bazaar + Drupal, they do have conversions available: http://drupal.org/node/45368 [15:24] jam: thanks... but thats just head, which is version 7 atm... were working with version 5, so its not so helpful. But i think bzr does hold the key - i just created a test local repro, added one of our sites and then updated it to a new version of drupal, by hand - without bzr missing a beat (unlike SVN which just wont do it). === abadger19991 is now known as abadger1999 [15:46] james_w: just asked in #launchpad :) [15:58] Gah, this is SOO annoying [15:58] I'm trying to dumb-serve a bzr repo out of IIS. Through a debugging proxy, chained to our main proxy, it works fine [16:00] Heh, ISA works, FreeProxy doesn't [16:01] MS finally does something right [16:01] hmeland: Yeah, I don't claim the diff/log behavior is wrong, but I can see why someone might find it confusing. [16:05] if I do bzr log --gnu ... and I get "no such option gnu" for some people, but it works for me. [16:05] where is the --gnu coming from? [16:05] mtaylor: A plugin that overrides the log options? [16:05] hrm. [16:05] mtaylor: The help should list the option and which plugin it comes from [16:06] :) [16:06] howabout the gnulog plugin [16:36] Something is strange. When I do bzr.dev merge https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/ [16:37] I get: "Nothing to do." [16:37] But when I try: "bzr push https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/" [16:37] it replies with the error: "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified." [16:38] umm, push over https? [16:38] oh, it's svn [16:38] what does "bzr missing https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/" tell you? [16:40] yo guys, does bazaar supports something like in-working-copy-branches from git or namedbanched "ala" mercurial? [16:41] no, but it does support branches without working trees, and a way to switch a working tree to a different branch [16:44] james_w: "bzr missing" tells me that I have 3 extra revisions (basically merges from that repo). So I guess I branch from https://pa-do..., merge in my revisions and pull, right? [16:44] lazy1: so if i have a/ as a bazaar repo, it has two branches 1/ and 2/ , a/ can be switch on 1 and 2, so why isnt that different from "in-working-copy-branches"? [16:44] s/lazy1/luks/ [16:45] s/pull/push/ [16:45] luks: the prolem i got is that mercurial deceived me with the namedbranches :p, i cant delete them, i cant rename them [16:45] ChristopheT: if you have 3 extra revisions then push should not say that have nothing to do [16:45] maybe there's some interaction with svn that I'm not getting though [16:46] kiorky: it looks pretty similar to working-copy-branches, but you do have external branches [16:46] james_w: it is "merge" that says "nothing to do". [16:46] the distinction matters to some people, not others [16:46] ChristopheT: ah, sorry. [16:47] ChristopheT: ok, so you shouldn't be told that they have no common ancestor, again unless there is some bzr-svn subtelty I am missing [16:47] james_w: the use case is integration with svn, i want to have in my repo the svn branch, and features branches [16:47] ChristopheT: but your solution should work [16:48] james_w: can the rbranches be local, i mean: can the branches not be pushed on a central repo ? [16:48] kiorky: absolutely. [16:48] whow != [16:49] features i miss on mercucrial :) [16:49] james_w: now, for the integration with the existing stuff i have. Is there something to do as the mercurial forest extension to organize a bunch of repos [16:50] I'm not familiar with forest [16:50] ok [16:50] let me a moment [16:50] james_w: Overview [16:50] The Forest extension allows operations on trees with nested Mercurial repositories, called forests. Those to some degree correspond to multi-project CVS/Svn/... repositories. [16:51] kiorky: I don't see why you should push branches to the central place in mercurial [16:51] james_w: you have a tree with sub mercurial repos, that you can serve, this solve the partial checl out problem for example [16:51] ah, I got it [16:51] no, bzr doesn't have that yet [16:51] doesn't it depend on the style the developers are using the mercurial? [16:51] neobug: if you make named branches, they are pushed [16:51] oh [16:51] james_w: Ack! "bzr.dev branch https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/" starts downloading the revision bu then tells "bzr: ERROR: The branch https://pa-do.svn.sourceforge.net/svnroot/pa-do/trunk/ has no revision None." [16:52] I probably missed this detail [16:52] ouch [16:52] james_w: .bzr.log: http://pastebin.com/d5fbaed93 [16:53] neobug: :), frustrating isnt it ? [16:54] neobug: do not try the localbranch extension it is quite unusable [16:54] ChristopheT: not sure what's causing that. It's an odd level to get that message from though [16:54] well, I haven't used named branches so it's hard to say :-) [16:55] james_w: so how can you organize large repo? [16:55] james_w: my structure is there for example : http://hg.minitage.org/ [16:56] james_w: Worth to file a bug? [16:56] ChristopheT: probably [16:56] kiorky: you mean how should it be organised without an equivalent to the forest extension? [16:57] james_w: yep [16:57] james_w: i m used to have tree based organization [16:57] james_w: so i dont know how to make in an other way [16:57] kiorky: I'm not sure, unfortunately if you require the forest-like behaviour you are pretty stuck [16:58] you can make each of those in to branches fine, there is just no way to grab the top level and get them all, say. [17:01] james_w: ok, tahts not a problem [17:01] james_w: i just want to organize/have partial checout [17:01] james_w: but then, how can i make a branch of a sub branch? [17:04] you can make separate branches in the same way as you have separate repos in hg, you just can't define the structure like you can with forest [17:04] it has to be done up front though, there's no partial checkout facility either [17:05] I've managed to leave bazaar in a locked state by killing the gcommit process before actually committing. Is there a way to unlock it? [17:06] semslie: bzr break-lock? [17:07] gour: thanks! [17:11] james_w: i will try to get a tree structure this evening [17:12] lifeless: ping [17:15] Oh, that reminds me... I was having gcommit issues I should take a closer look at. [17:16] ... or not. Works fine after pulling updates. [18:10] Is there a transport neutral way to find out whether some path is pointing to a directory or just an ordinary file? [18:11] local transport has _check_mode_and_size, but that's just the local transport === bac is now known as bac|away === bac|away is now known as bac [18:58] One of our team members pushed to our repository, in Launchpad, but he didn't have the latest changes to begin with. When he attempted to push (after he commited his changes, he had 3 commits), the branch warned him that he needed to "merge", so he did this: "bzr merge lp:phpns". Now I want to undo what he did. How? [18:59] alecwh: he pushed after? [18:59] Sorry, he didn't push, he just did a "merge" [18:59] and commit? [18:59] He TRIED pushing [19:00] yes [19:00] 3 commits. [19:00] here is the repo: https://code.launchpad.net/~phpns-team/phpns/head [19:01] hmm, I'm not sure I understand, you're trying to fix that branch, or just the one on this developer's machine? [19:02] we're trying to fix the branch. It looks like we lost several commits from me. [19:02] We just want to "revert" to before he merged. [19:02] so everything will be normal again. [19:03] so he did push after? [19:04] let me check. [19:04] is " kyle's EE in. Ready for packaging (if no more fixes)" the revision that you had as the tip beforehand? [19:04] Yes, I believe so! [19:05] cool, if you have a branch locally you can do this: [19:05] if you run "bzr log -r -1" then you will see your revisions merged in, the number of the top one of these (the indented ones) should be 26.1.4 [19:05] I have a copy of the branch (the one with the merge) on my desktop [19:06] so, if you run "bzr pull --overwrite -r 26.1.4 ." then it will put your copy of the branch back on that revision. [19:06] If you then run "bzr log" you should see it as it was before. [19:07] you can then push that back to lp:phpns. However, it won't let you do that as you have changed history, so you need to pass --overwrite there as well. [19:08] You should check that you have what you want locally before you push though. The situation wouldn't be unfixable, but it's better to catch it early [19:09] once your happy with that I can help you get the other developer's changes merged properly [19:12] LarstiQ: Eh, are you still in the... room? [19:12] No. [19:13] james_w: okay, I just pushed the changes with --overwrite, but it isn't showing up on Launchpad. This is just lag, right? [19:13] it did say "Pushed up to revision 30." [19:13] yeah, I think so [19:13] that worked great then! [19:13] do you understand how the other developer should have merged to avoid this? [19:14] Okay, now, that developer (Kyle) still has those 3 commits we want to put in [19:14] james_w: no, how? [19:15] ok, so with this style of development each developer should keep a mirror of trunk on their machine that they only run "bzr pull" in normally (using a shared repository will make this very cheap for them). [19:16] they then have at least one other branch that they do their work in. You can have loads, or you can just have one, it works the same. === cprov-lunch is now known as cprov [19:16] when you are at a stage where you want to push your work to launchpad you "cd ../trunk; bzr merge ../my-branch" [19:17] this merges in all your changes, you fix up any conflicts and then commit [19:17] okay. [19:17] you can then push directly to launchpad [19:18] the chances of colliding with someone else when doing this are very small, but if it keeps happening then there are ways to avoid it, but it's probably better to keep it simple for nwo [19:18] this means that you only ever have merge commits on the trunk, and my work doesn't "swallow up" your work like just happened [19:19] I can help you to do this for the three commits if you like, as you won't be able to see them in your branch at the moment [19:19] so, assuming the branch is now fixed (merge was removed), I think I'll have HIM clone the branch, and just copy over his "changed" files (because he still has a copy of that merged branch that we fixed), and just commit/push [19:19] there is no need to branch, because it's all tested and fine. [19:20] that would work, but we can preserve history if you would like [19:20] okay, but those 3 commits he made are gone from the LP repo, correct? [19:21] they'll still be in the repo, but won't be visible, and won't be copied in when grabbing the code [19:21] bzr doesn't delete revisions, even if you do something like we just did. It's a small cost. [19:22] I mean it's a small cost that they are there even though they are not needed to have some safety about not losing them. [19:22] okay, can we get those "visible" as concurrent revisions? So, his would be revs 31, 32, 33? [19:23] yes, that's a "rebase" operation. You would need a plugin to do that. [19:23] I can easily tell you how to resurrect them and then merge them so they would just be rev 31, but would show as merged revisions still [19:23] Hm, I think it would be easier with what I said above [19:24] james_w: okay [19:25] ok, so first we need to pull his commits out in to an old branch. [19:25] so, I need to grab the last commit before he made his? [19:25] For this we will need the revision id of the tip when the branch was messed up. we need the revision id as the revisions are no longer present in the history of your branch, and so won't be given revision numbers. [19:26] I just so happen to have the relevant id here: k.p.osborn@gmail.com-20080710061647-5yzdt3ya4lgsmld8 [19:26] so if you run "bzr branch -rrevid:k.p.osborn@gmail.com-20080710061647-5yzdt3ya4lgsmld8 your-branch/ new-branch/ [19:27] okay, great. This will give me the branch before we fixed it? [19:27] then run "bzr log" in "new-branch/" you will see the branch being back to it's broken state [19:27] yes, exactly. [19:28] now you can "cd ../your-branch; bzr merge ../new-branch" [19:28] Branched 29 revision(s). [19:28] once you commit you can examine "bzr log" to see what this looks like [19:29] when you are happy you can again push, and you won't need the --overwrite here, as you didn't modify history, just appended to it. [19:30] what does: M* inc/config.php [19:30] mean? [19:30] the * [19:30]