=== Kissaki is now known as Kissaki^0ff [03:23] hello! [03:24] i rebased my changes against some other stuff, but how can i push it to launchpad? [03:24] is --overwrite safe? [03:26] what does 'safe' mean? :) [03:29] jbalint: you've read all the warnings in git-rebase(1)? [03:31] dash: will it just remove all the revisions after they diverge on the destination branch? [03:31] SamB: well, first i'm not using git, and second, i dont see any wrnings on rebase plugin help [03:32] jbalint: I didn't ask if you were using git! [03:32] the warnings are applicable regardless [03:32] ok, mightve helped to mention that [04:21] jbalint: as long as you are fairly sure that no one else depends on your old chagnes [04:21] then push --overwrite to LP will work fine [04:21] ok, thanks [06:18] How should I link an already-fixed bug with the release it was fixed in? [06:19] "Nominate for release"? I don't want to add any administrative burden, though. [06:19] (Bug #241133 and 1.13, FWIW.) [06:19] Launchpad bug 241133 in bzr "Don't suggest the user specify -Dhpss" [Medium,Fix released] https://launchpad.net/bugs/241133 [06:38] What's the status of nested trees these days? [06:39] if i use "bzr rename foo bar", will "foo" be retroactively named "bar" in all previous versions? [06:39] i mean "bzr mv foo bar" [06:41] Peng_: Set a milestone, I think, but milestones for past releases may be closed. [06:41] pattern: No, just for future ones. Previous revisions are already set in stone, that's why they're previous 8-} [06:44] so what happens when i do a "bzr diff -rX..Y bar" when X is a version in which "bar" was named "foo" ? [06:45] It'll show a rename and any changes to the content you made. [06:46] great [06:47] (now, patch(1) probably won't understand and do the rename if you try and use the diff for that, but...) [06:48] thanks.. i'll keep that in mind [06:49] The only way you can generally make patch(1) do that is have the diff be something like "remove all lines from foo, add [almost] the same lines to bar" [06:49] That's a little less friendly to read, though :p [06:50] pattern: e.g., http://www.pastebin.ca/1451535 for a rev with a rename and adding a line [06:54] fullermd: Ahh, good suggestion. I'll try it. [06:55] thanks, fullermd [06:56] i will consider doing something like that, should i have the need [07:00] fullermd: Ahh, I don't think I can set a milestone, since I'm not a bzr developer. === jamesh_ is now known as jamesh [07:55] hi all [07:56] Good morning! === Kissaki^0ff is now known as Kissaki === Kissaki is now known as Kissaki^0ff [12:38] anybody have experience with doing CVS import via cvsps-import? Is there way to attach tags to branch? === mrevell is now known as mrevell-lunch === Kissaki^0ff is now known as Kissaki === mrevell-lunch is now known as mrevell === Kissaki is now known as Kissaki^0ff === Kissaki^0ff is now known as Kissaki [14:45] hello there, what's the right procedure to upgrade a branch hosted on launchpad? bzr upgrade --format=... && bzr push will do? [14:49] Yep, and I thought a button for doing that from the webui was going to be done/in planning. [14:50] upgrade and push won't change what is on lp [14:50] you need "bzr upgrade --format=... lp:branch" for that [15:06] vila: good morning [15:07] jam: hi John, just tried to ring you but abandoned after the 6/7 or 8th 'still trying' :-) Should I try again ? [15:07] sorry about that [15:07] my wife is on a conference call *all day* [15:07] she got out of traveling to europe [15:07] but then has to sit on the phone for the whole conference [15:08] oh, np then [15:08] you can call my cell phone if you still want to chat [15:08] jam: ok === oubiwann_ is now known as oubiwann === KX_ is now known as KX [15:52] hi [15:53] I'm stuck during a merge, can you perhaps help me out here? In my merge, I have a lot of conflicts. I want to resolve these conflicts by 'reverting' to the version of the "OTHER" branch [15:53] I would be expecting some 'bzr revert --other' switch, but it seems to be unavailable [15:53] in the past, I've used 'bzr revert -rrevid:$REVID $file' for that [15:54] but now I'm using bzr-builddeb to merge to a new upstream version, which makes it hard for me to guess the revid of the "other" branch [15:55] is there some way to learn the revids involved in a merge somehow? [15:55] I expected 'bzr status -v --show-ids' to tell me that, but it doesn't :-( [15:56] this is bzr 1.15, btw [15:59] siretart`: well the ugly hack is "head .bzr/checkout/dirstate" [15:59] which should tell you the revision of OTHER [16:02] ja1: that sounds promising, but I don't quite grok the format of that file :( [16:03] siretart`: line 3 [16:03] should have "2

" [16:03] without spaces for me, but yeah, I see that [16:04] ah, right, so the 2nd id should be the 'other' branch [16:04] thanks! [16:04] well, with a "\0" not a space [16:04] ok === ja1 is now known as jam [16:06] excellent, that works for me [16:07] may I still suggest to add some option '--other' to the the revert command? ;-) [16:07] you can suggest whatever you like :) [16:07] but yeah, some way to reference "the new merge parent" would be useful [16:08] or maybe as a new revision specifier [16:16] james_w: hi there [16:16] james_w: I've just patched bzr-builddeb to contain an switch to ignore using pristine-tar even if it is installed on the system [16:16] hey siretart [16:16] how are you? [16:17] why don't you want to use it? [16:17] james_w: for some reason pristine-tar just hangs indefinitly when called by bzr-builddeb, no idea why [16:17] sek [16:17] ah [16:17] I think that I might have a fix for that [16:17] james_w, hi [16:18] could you fire off an upload of bzr.dev to the PPA? [16:18] hey beuno [16:18] beuno: sure [16:18] james_w, thanks [16:18] how was your vacation? [16:19] good thanks, very relaxing [16:19] seems I misplaced my GPG key somewhere in Spain though, and I can't find the backup today [16:19] re [16:20] james_w: thanks, I'm fine (again, was rather sick last week, but I feel better now) [16:20] trying to upgrade one of my older packages, and wanted to use bzr-builddebs merge capabilities [16:20] 387 James Westby 2009-05-13 [16:20] Don't deadlock when the pristine-tar delta is large. [16:21] james_w: anyway, are you interested in merging my --avoid-pristine-tar switch? [16:21] I stupidly didn't read a big fat warning in the subprocess docs [16:21] aah, that sounds exactly like the problem I'm experiencing [16:21] so I can fix that [16:21] I'm not against the flag, but I'd rather not merge it unless there is a real need for it [16:22] if I can fix bugs instead then that would suit me fine [16:22] ok [16:23] siretart`: it's in lp:bzr-builddeb/2.1 if that suits you [16:23] I should seek an SRU for the couple of bugs that I have fixed [16:24] oh, I'm following lp:~bzr-builddeb-hackers/bzr-builddeb/trunk, is that branch deprecated? [16:24] too late, I've already upgraded without pristine-tar now :-) [16:25] :-) [16:25] it's not deprecated [16:26] it was just still pushing :-) [16:28] I have to admit that I nowadays maintain quite a bounch of packages in git these days, mainly because of the packaging teams I'm active in [16:28] what I miss most in bzr is an interactive rebase, so that I can cleanup and combine unpushed commits [16:30] siretart`, Does the bzr rebase plugin not have interactive mode? [16:30] not in my copy of it [16:31] I don't think it does yet [16:32] I've just pulled lp:bzr-rebase, but it doesn't seem to be there [16:33] bzr: ERROR: Invalid url supplied to transport: "lp:bzr-builddeb/2.1": Project bzr-builddeb has no series called "2.1" [16:33] err, uh? [16:42] uh? [16:42] oh, seems I never created the 2.1 series [16:43] lp:~bzr-builddeb-hackers/bzr-builddeb/2.1 [16:43] or it's in trunk now [16:50] argh @ git [16:50] how good is bzr-git (or git-bzr or whatever)? [16:52] improving rapidly :-) [16:56] do you think it's Good Enough for readonly use? [16:58] I'd say try it. [16:58] If it does not crash, it's good enough for read-only use :) [16:59] It's not like it's going to make you lose any data. [17:00] even if it's buggy or unstable, then you might get corruption errors down the road, that shoud not prevent you from accessing your older commits [17:01] or [17:01] you could drink until the pain is tolerable [17:01] then keep using git :P [17:02] or you could drink and use bzr [17:02] (guess what I picked) [17:02] in this case, that's recreative drinking [17:03] not drinking-to-numb-the-pain [17:03] that leads to drinking-to-forget-that-git-led-you-to-alcoholism [17:03] i didn't say what was in my bzr branch [17:11] james_w: it seems that the trunk branch and 2.1 branch have diverged quite a bit. is 2.1 supposed to be behind or ahead of trunk? [17:11] behind [17:12] it will have a higher revno though [17:12] I merged them today [17:12] oh, I see [17:13] ah [17:13] hm. I'm quite happy with trunk, but it is missing some revisions from 2.1.. hmmmm [17:13] it's a mirrored branch, so if you are going off LP it won't be up to date yet [17:13] oh [17:22] supports bazaar 1.10 server side commit hooks? [18:09] how do I restore a deleted file? [18:10] revert it? [18:11] without reverting all my changes to other files? [18:11] bzr revert filename didn't work, as the file doesn't exist [18:11] cellofellow, bzr revert [18:12] specify a revision [18:12] ok [18:12] bzr revert -r-1 filename [18:13] oh, ok, thanks [18:13] ok, that worked, thanks [18:50] garyvdm: hi :) are you around ? [18:57] Hi RockyRoad [18:58] how are you ? how goes qbzr ? [18:58] I have a little problem again, with lauchpad [18:59] the uncommit succeeded locally, but push does nothing (doesn't revert) [19:00] It's the right branch, because I can see the message "updating branch" on lp page [19:00] https://code.edge.launchpad.net/~m-baert/planet-drupal/planet-6-x [19:01] I'm back on rev 25 in my work directory [19:01] It's still 26 on lp [19:02] Is there something I missed ? or is it because the commit was done yesterday ? [19:02] (Yes I could ask on lp, but you know the context now ;) [19:05] Isn't it generally considered a bad idea to uncommit things which are already pushed to a public repo? [19:05] I think a similar sequence worked yesterday [19:05] maxb: yes [19:05] RockyRoad: maybe you're missing --overwrite? [19:05] RockyRoad: so don't do that, then? [19:06] LarstiQ: good idea I missed it [19:06] maxb: it's a dev branch, not that public [19:07] LarstiQ: THANKS \o/ it worked :_ [19:07] :) [19:08] I will repush it with no code diff, very soon [19:09] better commit message, and after a CVS commit [19:09] and adding a changelog file for cvs [19:10] nothing that should really break users' platforms [19:12] RockyRoad: Sorry - was not watching irc [19:12] RockyRoad: right. The thing is, anyone who was just mirroring your branch now will get a Diverged branches error (if they have the commit you just uncommitted) [19:12] RockyRoad: wether that is a problem is up to you, but it can be nasty [19:13] The other option is to (which maxb is suggesting) is to do a bzr revert -r -2, and bzr commit, bzr push [19:13] garyvdm: np it's solved ... I think .... still learning with LarstiQ, maxb .... and you :) [19:16] LarstiQ: honestly I doubt it can be the case, but I'm interested to know more about this diverged branch issue. Is it that nasty ? [19:19] RockyRoad: it can be overcome relatively easily in the simple case, but it disrupts people's workflow [19:19] RockyRoad: you can try it for yourself, take a branch, make a copy, uncommit, new commit, and pull [19:19] I hit that the other day [19:20] I'd be glad to know them if there are other devs working on it [19:21] LarstiQ: good idea. I'll do it, to see ... and know for later occasions. [19:26] Thanks all :) [19:40] hi guys. i'm looking for the best way to move some source files from one project to another while maintaining information about version history on those files if possible [19:42] superm1: how are both branches related? [19:43] LarstiQ, well so one is a "common" project and the other is a child project. moving a lot of the code from the child project into the common project [19:43] so the branches never have had a common anscestor [19:44] right [19:45] I don't know if it would help, but I just finished something a bit similar [19:45] http://www.rocky-shore.net/misc/bzr-rebuild.html [19:46] sorry I didn't update it yet with the last things garyvdm helped me with yesterday [19:47] yeesh that looks complex [19:48] the key as I understood is to use merge with a revision range [19:48] to make a common ancestor [19:49] so i guess i'll need to look at what revisions i care about in these source files then [19:50] yes find exactly the two history points to connect [19:50] LarstiQ: I'm explaining it with my bzr-noobie language [19:51] you surely know better than me, but it sounds so similar ... [19:51] so let me get this right, i'll manually copy the files into the new tree, and 'bzr add' each of them for "initial checkins", that's my new last history point [19:52] and then something along the lines of bzr merge the revisions from there and earlier that i need to bring history in for? [19:52] superm1: I wouldn't do it that way [19:53] superm1: you can force a common ancestor with -r0.. [19:53] superm1: but maybe by reference nested trees are good enough for you [19:57] superm1: a "bzr push lp:~user/project/branch" copies all at once [19:58] RockyRoad, well i'm doing it all locally so i can easily undo things for now [19:59] LarstiQ, i'll try and read up on reference nested trees then [19:59] so just copy the directory [20:03] hi all [20:36] james_w: if you have a identi.ca account I haven't found it, but: do you know www.philosomatika.com ? [20:44] LarstiQ: I didn't [20:45] thanks === spm_ is now known as spm [22:50] hm no jam? [22:50] hello all anyhow [22:58] hi poolie === GaryvdM_ is now known as GaryvdM_win32 [23:01] hi poolie [23:01] I was just heading out [23:04] np [23:04] i was just going to try to catch up [23:04] i have another call now, but we could talk tomorrow maybe? === psynaptic is now known as someoneelse === someoneelse is now known as psynaptic [23:24] am I supposed to be able to branch from a 1.6 format repository into a brisbane-core repo? [23:24] I have my branch command stuck on "Transferring revisions 0/1509" [23:24] with 100% on one core [23:27] thumper: It's doing a upgrade on the revisions that it's pulling - so it will be slow [23:28] GaryvdM_win32: thanks, I see that it has not got to 100/1509 [23:28] i'm having trouble opening bzr viz getting this message [23:28] ERROR: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExisted: Launch helper returned with unknown return code 0 [23:29] has anyone had this problem? [23:29] limmer: Thats a know bug. Workaround: run bzr viz again [23:29] You have to run it twice every time after you boot your machine. [23:29] GaryvdM_win32, wow, i feel ridiculous [23:30] thanks [23:30] limmer: It's a pleasure. P.S. have you tried qbzr? [23:31] i havent [23:31] It shows you a visualization like bzr viz, and it also allows you to collapse/expand branches [23:31] very cool, i'll have to give it a shot [23:31] Which is useful if you have complex branches. [23:31] Great [23:32] s/qbzr/qlog [23:32] installing now [23:35] GaryvdM_win32, qbzr is awesome! ty for the tip [23:35] cheers [23:35] It's a pleasure [23:44] morning [23:44] hi GaryvdM_win32 [23:45] Hi igc [23:45] bzr info $branch_which_tries_to_stack_on_not_there_branch is a bit confusing [23:51] Grr - while I was a uds, the guy who was sub'ing for me at work infected our work computer with a virus called mabezat which I just cant get rid of [23:54] mwhudson, when you get a chance [23:55] can you tell me what needs to be done to get these to MPs in: [23:55] https://code.edge.launchpad.net/~beuno/loggerhead/serve-config/+merge/6821 [23:55] https://code.edge.launchpad.net/~beuno/loggerhead/deprecate/+merge/6929 === GaryvdM_Windows is now known as GaryvdM