[03:23] <jbalint> hello!
[03:24] <jbalint> i rebased my changes against some other stuff, but how can i push it to launchpad?
[03:24] <jbalint> is --overwrite safe?
[03:26] <dash> what does 'safe' mean? :)
[03:29] <SamB> jbalint: you've read all the warnings in git-rebase(1)?
[03:31] <jbalint> dash: will it just remove all the revisions after they diverge on the destination branch?
[03:31] <jbalint> SamB: well, first i'm not using git, and second, i dont see any wrnings on rebase plugin help
[03:32] <SamB> jbalint: I didn't ask if you were using git!
[03:32] <SamB> the warnings are applicable regardless
[03:32] <jbalint> ok, mightve helped to mention that
[04:21] <thumper> jbalint: as long as you are fairly sure that no one else depends on your old chagnes
[04:21] <thumper> then push --overwrite to LP will work fine
[04:21] <jbalint> ok, thanks
[06:18] <Peng_> How should I link an already-fixed bug with the release it was fixed in?
[06:19] <Peng_> "Nominate for release"? I don't want to add any administrative burden, though.
[06:19] <Peng_> (Bug #241133 and 1.13, FWIW.)
[06:38] <cammoblammo> What's the status of nested trees these days?
[06:39] <pattern> if i use "bzr rename foo bar", will "foo" be retroactively named "bar" in all previous versions?
[06:39] <pattern> i mean "bzr mv foo bar"
[06:41] <fullermd> Peng_: Set a milestone, I think, but milestones for past releases may be closed.
[06:41] <fullermd> pattern: No, just for future ones.  Previous revisions are already set in stone, that's why they're previous  8-}
[06:44] <pattern> 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] <fullermd> It'll show a rename and any changes to the content you made.
[06:46] <pattern> great
[06:47] <fullermd> (now, patch(1) probably won't understand and do the rename if you try and use the diff for that, but...)
[06:48] <pattern> thanks.. i'll keep that in mind
[06:49] <fullermd> 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] <fullermd> That's a little less friendly to read, though   :p
[06:50] <fullermd> pattern: e.g., http://www.pastebin.ca/1451535  for a rev with a rename and adding a line
[06:54] <Peng_> fullermd: Ahh, good suggestion. I'll try it.
[06:55] <pattern> thanks, fullermd
[06:56] <pattern> i will consider doing something like that, should i have the need
[07:00] <Peng_> fullermd: Ahh, I don't think I can set a milestone, since I'm not a bzr developer.
[07:55] <vila> hi all
[07:56] <Peng_> Good morning!
[12:38] <hsn_> anybody have experience with doing CVS import via cvsps-import? Is there way to attach tags to branch?
[14:45] <sidnei> hello there, what's the right procedure to upgrade a branch hosted on launchpad? bzr upgrade --format=... && bzr push will do?
[14:49] <jpds> Yep, and I thought a button for doing that from the webui was going to be done/in planning.
[14:50] <james_w> upgrade and push won't change what is on lp
[14:50] <james_w> you need "bzr upgrade --format=... lp:branch" for that
[15:06] <jam> vila: good morning
[15:07] <vila> jam: hi John, just tried to ring you but abandoned after the 6/7 or 8th 'still trying' :-) Should I try again ?
[15:07] <jam> sorry about that
[15:07] <jam> my wife is on a conference call *all day*
[15:07] <jam> she got out of traveling to europe
[15:07] <jam> but then has to sit on the phone for the whole conference
[15:08] <vila> oh, np then
[15:08] <jam> you can call my cell phone if you still want to chat
[15:08] <vila> jam: ok
[15:52] <siretart`> hi
[15:53] <siretart`> 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] <siretart`> I would be expecting some 'bzr revert --other' switch, but it seems to be unavailable
[15:53] <siretart`> in the past, I've used 'bzr revert -rrevid:$REVID $file' for that
[15:54] <siretart`> 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] <siretart`> is there some way to learn the revids involved in a merge somehow?
[15:55] <siretart`> I expected 'bzr status -v --show-ids' to tell me that, but it doesn't :-(
[15:56] <siretart`> this is bzr 1.15, btw
[15:59] <ja1> siretart`: well the ugly hack is "head .bzr/checkout/dirstate"
[15:59] <ja1> which should tell you the revision of OTHER
[16:02] <siretart`> ja1: that sounds promising, but I don't quite grok the format of that file :(
[16:03] <ja1> siretart`: line 3
[16:03] <ja1> should have "2 <revision-id> <revision-id>"
[16:03] <siretart`> without spaces for me, but yeah, I see that
[16:04] <siretart`> ah, right, so the 2nd id should be the 'other' branch
[16:04] <siretart`> thanks!
[16:04] <ja1> well, with a "\0" not a space
[16:04] <siretart`> ok
[16:06] <siretart`> excellent, that works for me
[16:07] <siretart`> may I still suggest to add some option '--other' to the the revert command? ;-)
[16:07] <jam> you can suggest whatever you like :)
[16:07] <jam> but yeah, some way to reference "the new merge parent" would be useful
[16:08] <siretart`> or maybe as a new revision specifier
[16:16] <siretart`> james_w: hi there
[16:16] <siretart`> 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] <james_w> hey siretart
[16:16] <james_w> how are you?
[16:17] <james_w> why don't you want to use it?
[16:17] <siretart`> james_w: for some reason pristine-tar just hangs indefinitly when called by bzr-builddeb, no idea why
[16:17] <siretart`> sek
[16:17] <james_w> ah
[16:17] <james_w> I think that I might have a fix for that
[16:17] <beuno> james_w, hi
[16:18] <beuno> could you fire off an upload of bzr.dev to the PPA?
[16:18] <james_w> hey beuno
[16:18] <james_w> beuno: sure
[16:18] <beuno> james_w, thanks
[16:18] <beuno> how was your vacation?
[16:19] <james_w> good thanks, very relaxing
[16:19] <james_w> seems I misplaced my GPG key somewhere in Spain though, and I can't find the backup today
[16:19] <siretart`> re
[16:20] <siretart`> james_w: thanks, I'm fine (again, was rather sick last week, but I feel better now)
[16:20] <siretart`> trying to upgrade one of my older packages, and wanted to use bzr-builddebs merge capabilities
[16:20] <james_w>   387 James Westby	2009-05-13
[16:20] <james_w>       Don't deadlock when the pristine-tar delta is large.
[16:21] <siretart`> james_w: anyway, are you interested in merging my --avoid-pristine-tar switch?
[16:21] <james_w> I stupidly didn't read a big fat warning in the subprocess docs
[16:21] <siretart`> aah, that sounds exactly like the problem I'm experiencing
[16:21] <james_w> so I can fix that
[16:21] <james_w> I'm not against the flag, but I'd rather not merge it unless there is a real need for it
[16:22] <james_w> if I can fix bugs instead then that would suit me fine
[16:22] <siretart`> ok
[16:23] <james_w> siretart`: it's in lp:bzr-builddeb/2.1 if that suits you
[16:23] <james_w> I should seek an SRU for the couple of bugs that I have fixed
[16:24] <siretart`> oh, I'm following lp:~bzr-builddeb-hackers/bzr-builddeb/trunk, is that branch deprecated?
[16:24] <siretart`> too late, I've already upgraded without pristine-tar now :-)
[16:25] <james_w> :-)
[16:25] <james_w> it's not deprecated
[16:26] <james_w> it was just still pushing :-)
[16:28] <siretart`> 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] <siretart`> what I miss most in bzr is an interactive rebase, so that I can cleanup and combine unpushed commits
[16:30] <cody-somerville> siretart`, Does the bzr rebase plugin not have interactive mode?
[16:30] <siretart`> not in my copy of it
[16:31] <james_w> I don't think it does yet
[16:32] <siretart`> I've just pulled lp:bzr-rebase, but it doesn't seem to be there
[16:33] <siretart`> bzr: ERROR: Invalid url supplied to transport: "lp:bzr-builddeb/2.1": Project bzr-builddeb has no series called "2.1"
[16:33] <siretart`> err, uh?
[16:42] <james_w> uh?
[16:42] <james_w> oh, seems I never created the 2.1 series
[16:43] <james_w> lp:~bzr-builddeb-hackers/bzr-builddeb/2.1
[16:43] <james_w> or it's in trunk now
[16:50] <Tak> argh @ git
[16:50] <Tak> how good is bzr-git (or git-bzr or whatever)?
[16:52] <james_w> improving rapidly :-)
[16:56] <Tak> do you think it's Good Enough for readonly use?
[16:58] <ddaa> I'd say try it.
[16:58] <ddaa> If it does not crash, it's good enough for read-only use :)
[16:59] <ddaa> It's not like it's going to make you lose any data.
[17:00] <ddaa> 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] <ddaa> or
[17:01] <ddaa> you could drink until the pain is tolerable
[17:01] <ddaa> then keep using git :P
[17:02] <dash> or you could drink and use bzr
[17:02] <dash> (guess what I picked)
[17:02] <ddaa> in this case, that's recreative drinking
[17:03] <ddaa> not drinking-to-numb-the-pain
[17:03] <ddaa> that leads to drinking-to-forget-that-git-led-you-to-alcoholism
[17:03] <dash> i didn't say what was in my bzr branch
[17:11] <siretart`> 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] <james_w> behind
[17:12] <james_w> it will have a higher revno though
[17:12] <james_w> I merged them today
[17:12] <siretart`> oh, I see
[17:13] <james_w> ah
[17:13] <siretart`> hm. I'm quite happy with trunk, but it is missing some revisions from 2.1.. hmmmm
[17:13] <james_w> it's a mirrored branch, so if you are going off LP it won't be up to date yet
[17:13] <siretart`> oh
[17:22] <hsn_> supports bazaar 1.10 server side commit hooks?
[18:09] <cellofellow> how do I restore a deleted file?
[18:10] <LeoNerd> revert it?
[18:11] <cellofellow> without reverting all my changes to other files?
[18:11] <cellofellow> bzr revert filename didn't work, as the file doesn't exist
[18:11] <cody-somerville> cellofellow, bzr revert <file>
[18:12] <cody-somerville> specify a revision
[18:12] <cellofellow> ok
[18:12] <LeoNerd> bzr revert -r-1 filename
[18:13] <cellofellow> oh, ok, thanks
[18:13] <cellofellow> ok, that worked, thanks
[18:50] <RockyRoad> garyvdm: hi :) are you around ?
[18:57] <garyvdm> Hi RockyRoad
[18:58] <RockyRoad> how are you ? how goes qbzr ?
[18:58] <RockyRoad> I have a little problem again, with lauchpad
[18:59] <RockyRoad> the uncommit succeeded locally, but push does nothing (doesn't revert)
[19:00] <RockyRoad> It's the right branch, because I can see the message "updating branch" on lp page
[19:00] <RockyRoad> https://code.edge.launchpad.net/~m-baert/planet-drupal/planet-6-x
[19:01] <RockyRoad> I'm back on rev 25 in my work directory
[19:01] <RockyRoad> It's still 26 on lp
[19:02] <RockyRoad> Is there something I missed ? or is it because the commit was done yesterday ?
[19:02] <RockyRoad> (Yes I could ask on lp, but you know the context now ;)
[19:05] <maxb> Isn't it generally considered a bad idea to uncommit things which are already pushed to a public repo?
[19:05] <RockyRoad> I think a similar sequence worked yesterday
[19:05] <LarstiQ> maxb: yes
[19:05] <LarstiQ> RockyRoad: maybe you're missing --overwrite?
[19:05] <maxb> RockyRoad: so don't do that, then?
[19:06] <RockyRoad> LarstiQ: good idea I missed it
[19:06] <RockyRoad> maxb: it's a dev branch, not that public
[19:07] <RockyRoad> LarstiQ: THANKS \o/ it worked :_
[19:07] <RockyRoad> :)
[19:08] <RockyRoad> I will repush it with no code diff, very soon
[19:09] <RockyRoad> better commit message, and after a CVS commit
[19:09] <RockyRoad> and adding a changelog file for cvs
[19:10] <RockyRoad> nothing that should really break users' platforms
[19:12] <garyvdm> RockyRoad: Sorry - was not watching irc
[19:12] <LarstiQ> 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] <LarstiQ> RockyRoad: wether that is a problem is up to you, but it can be nasty
[19:13] <garyvdm> The other option is to (which maxb is suggesting) is to do a bzr revert -r -2, and bzr commit, bzr push
[19:13] <RockyRoad> garyvdm: np it's solved ... I think .... still learning with LarstiQ, maxb .... and you :)
[19:16] <RockyRoad> 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] <LarstiQ> RockyRoad: it can be overcome relatively easily in the simple case, but it disrupts people's workflow
[19:19] <LarstiQ> RockyRoad: you can try it for yourself, take a branch, make a copy, uncommit, new commit, and pull
[19:19] <Tak> I hit that the other day
[19:20] <RockyRoad> I'd be glad to know them if there are other devs working on it
[19:21] <RockyRoad> LarstiQ: good idea. I'll do it, to see ... and know for later occasions.
[19:26] <RockyRoad> Thanks all :)
[19:40] <superm1> 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] <LarstiQ> superm1: how are both branches related?
[19:43] <superm1> 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] <superm1> so the branches never have had a common anscestor
[19:44] <LarstiQ> right
[19:45] <RockyRoad> I don't know if it would help, but I just finished something a bit similar
[19:45] <RockyRoad> http://www.rocky-shore.net/misc/bzr-rebuild.html
[19:46] <RockyRoad> sorry I didn't update it yet with the last things garyvdm helped me with yesterday
[19:47] <superm1> yeesh that looks complex
[19:48] <RockyRoad> the key as I understood is to use merge with a revision range
[19:48] <RockyRoad> to make a common ancestor
[19:49] <superm1> so i guess i'll need to look at what revisions i care about in these source files then
[19:50] <RockyRoad> yes find exactly the two history points to connect
[19:50] <RockyRoad> LarstiQ: I'm explaining it with my bzr-noobie language
[19:51] <RockyRoad> you surely know better than me, but it sounds so similar ...
[19:51] <superm1> 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] <superm1> 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] <LarstiQ> superm1: I wouldn't do it that way
[19:53] <LarstiQ> superm1: you can force a common ancestor with -r0..
[19:53] <LarstiQ> superm1: but maybe by reference nested trees are good enough for you
[19:57] <RockyRoad> superm1: a "bzr push lp:~user/project/branch" copies all  at once
[19:58] <superm1> RockyRoad, well i'm doing it all locally so i can easily undo things for now
[19:59] <superm1> LarstiQ, i'll try and read up on reference nested trees then
[19:59] <RockyRoad> so just copy the directory
[20:03] <asabil> hi all
[20:36] <LarstiQ> james_w: if you have a identi.ca account I haven't found it, but: do you know www.philosomatika.com ?
[20:44] <james_w> LarstiQ: I didn't
[20:45] <james_w> thanks
[22:50] <poolie> hm no jam?
[22:50] <poolie> hello all anyhow
[22:58] <garyvdm> hi poolie
[23:01] <jam> hi poolie
[23:01] <jam> I was just heading out
[23:04] <poolie> np
[23:04] <poolie> i was just going to try to catch up
[23:04] <poolie> i have another call now, but we could talk tomorrow maybe?
[23:24] <thumper> am I supposed to be able to branch from a 1.6 format repository into a brisbane-core repo?
[23:24] <thumper> I have my branch command stuck on "Transferring revisions 0/1509"
[23:24] <thumper> with 100% on one core
[23:27] <GaryvdM_win32> thumper: It's doing a upgrade on the revisions that it's pulling - so it will be slow
[23:28] <thumper> GaryvdM_win32: thanks, I see that it has not got to 100/1509
[23:28] <limmer> i'm having trouble opening bzr viz getting this message
[23:28] <limmer> ERROR: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExisted: Launch helper returned with unknown return code 0
[23:29] <limmer> has anyone had this problem?
[23:29] <GaryvdM_win32> limmer: Thats a know bug. Workaround: run bzr viz again
[23:29] <GaryvdM_win32> You have to run it twice every time after you boot your machine.
[23:29] <limmer> GaryvdM_win32, wow, i feel ridiculous
[23:30] <limmer> thanks
[23:30] <GaryvdM_win32> limmer: It's a pleasure. P.S. have you tried qbzr?
[23:31] <limmer> i havent
[23:31] <GaryvdM_win32> It shows you a visualization like bzr viz, and it also allows you to collapse/expand branches
[23:31] <limmer> very cool, i'll have to give it a shot
[23:31] <GaryvdM_win32> Which is useful if you have complex branches.
[23:31] <GaryvdM_win32> Great
[23:32] <GaryvdM_win32> s/qbzr/qlog
[23:32] <limmer> installing now
[23:35] <limmer> GaryvdM_win32, qbzr is awesome! ty for the tip
[23:35] <limmer> cheers
[23:35] <GaryvdM_win32> It's a pleasure
[23:44] <igc> morning
[23:44] <igc> hi GaryvdM_win32
[23:45] <GaryvdM_win32> Hi igc
[23:45] <mwhudson> bzr info $branch_which_tries_to_stack_on_not_there_branch is a bit confusing
[23:51] <GaryvdM_win32> 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] <beuno> mwhudson, when you get a chance
[23:55] <beuno> can you tell me what needs to be done to get these to MPs in:
[23:55] <beuno> https://code.edge.launchpad.net/~beuno/loggerhead/serve-config/+merge/6821
[23:55] <beuno> https://code.edge.launchpad.net/~beuno/loggerhead/deprecate/+merge/6929