[00:16] <achiang> hello, i'm reading the man page for bzr merge and find it a little confusing. let's say i have r1, r2, and r3. i want to revert r2, obviously keep r1, and am ambivalent about r3 (it can stay, i don't care). do i want bzr revert -r r2, or do i actually want merge . -r r2..r3 ?
[00:19] <spiv> achiang: "revert" is a command to revert the working copy back to the a checked in version.
[00:20] <spiv> achiang: to undo a committed change you need merge
[00:20] <achiang> spiv: oh hm. sorry, i am using git terminology; i should have studied the bzr man page a little more
[00:20] <spiv> achiang: specifically, to undo the changes in r2
[00:20] <spiv> achiang: you'd do "bzr merge . -r 2..1"
[00:21] <spiv> achiang: note the backward revision range, because you want to reverse the change :)
[00:21] <achiang> spiv: hm, what happens to r3 in that case?
[00:22] <spiv> Nothing.
[00:22] <spiv> It's a cherrypick.
[00:23] <achiang> ok. i'll try that
[00:23] <spiv> It doesn't add a pending merge to the working copy, it is like a more convenient and robust version of generating a diff of that revision and applying it backwards.
[00:28] <achiang> ok, i just did that, and here is some sample output: http://pastebin.ubuntu.com/540859/
[00:28] <achiang> why does the merge message tell me that debian/changelog was modified, but bzr status does not?
[00:29] <fullermd> You missed the '.' in the merge command line.  You want to 'merge' from the local branch, not the parent.
[00:30] <achiang> ugh
[00:30] <fullermd> (it MAY be the same rev of course, if both branches are up-to-date identical)
[00:31] <fullermd> The merge message probably means whatever that rev range is made a change to the chanelog, but the end result was the same as what you already have.
[00:31] <achiang> oh, ok. i can buy that explanation
[00:32] <achiang> thanks spiv and fullermd
[00:33] <achiang> btw, i know you must hate comparisons to git, but this is one operation i find to be much more conceptually straightforward in git. i just did a quick google of 'svn revert' and realize bzr has similar behavior, but perhaps our man page could be improved?
[00:34] <maxb> achiang: Educate us, how does this work in git? :-)
[00:34] <achiang> specifically, in the 'bzr merge' page, the line that says, "To merge the changes introduced by 82, without previous changes:"; might be nicer to say, "To drop the changes introduced by 82..."
[00:35] <achiang> maxb: git revert <revspec>
[00:35] <fullermd> maxb: 'git revert X' ~= 'bzr merge -rX..last:X . ; bzr ci'
[00:35] <maxb> hmm
[00:35] <achiang> maxb: git reset is the equivalent of bzr revert
[00:35] <fullermd> git reset is sometimes bzr reset, and sometimes uncommit, and sometimes pull --overwrite.
[00:35] <achiang> and again, i know the primary use case is probably svn users, so i'm not trying to point fingers or anything...
[00:36] <achiang> but i did try to read the merge man page after someone pointed me at it, and i don't think i would have figured out how to actually drop my change without asking
[00:36] <fullermd> achiang: That example line isn't talking about reversing changes, it's talking about a cherrypick merge.
[00:36] <achiang> hm, perhaps i'm just especially dense. :-/
[00:37] <fullermd> It's about "get the changes from just rev 82 of the other branch", not "reverse rev 82 of this branch"
[00:37] <spiv> There have been some small tweaks to the merge help text in trunk.
[00:37] <achiang> perhaps an example for "reversing changes" would be helpful then?
[00:38] <fullermd> The 'revert' help actually mentions using merge for reversing stuff.
[00:38] <achiang> fullermd: i dunno... i read that help and scratched my head for a while before asking here.
[00:39] <fullermd> Second paragraph of the description.  At least in 2.2 and .dev; I don't have anything earlier right at hand, but I don't think it's all that new.
[00:39] <achiang> right, i'm saying i stared at that 2nd paragraph and it didn't make any sense to me.
[00:40] <achiang> and it's backwards from what spiv just advised me on
[00:40] <achiang> modulo the fact that i forgot to include "." (my own fault)
[00:40] <fullermd> No, it's the same, it's just using negative revnos rather than positive.
[00:41] <achiang> wow.
[00:41] <achiang> i had no clue
[00:42] <spiv> I wonder if that example would be clearer if it didn't use negative revnos (even though saying "undo the 2nd last commit" is probably a pretty common use case).
[00:43] <fullermd> I think of it as a good example of the meta- of the online help that makes me grumpy  :p
[00:44] <fullermd> It's sorta quick-ref, except when it's sorta comprehensive-ref, except when it's sorta command-centric-tutorial, except when it's sorta general-tutorial, except when it's sorta buncha-examples, except...
[00:44] <achiang> i mean, you could even keep the negative revnos, but just change the wording
[00:45] <achiang> "For example, "merge . --revision -2..-3" will remove the changes introduced by second to last commit (-2), without affecting the changes introduced by the last commit (-1)"
[00:45] <achiang> or something similar
[00:45] <fullermd> We should use the word 'reverse' there.  'remove' implies the rev is gone, which isn't the case, and 'revert' creates confusion with the revert command.
[00:46] <spiv> achiang: i.e. just be explicit about the meaning of -2 and -1?  Seems reasonable to me.
[00:46] <fullermd> Or we could just add a 'reverse' command.  That would be a nice thin layer on merge...
[00:46] <achiang> spiv: yes. i didn't realize those were negative revnos -- i just thought it was some weird convention passed to --revision
[00:48] <spiv> achiang, fullermd: those tweaks sound good to me.  I'll make them now.
[00:49] <achiang> spiv: thanks!
[00:49] <spiv> fullermd: hmm, actually, I'm ambivalent about the using "reverse"
[00:49] <fullermd> I'd half suggest using '-r' instead of '--revision' too.  On the one hand, being explicit and spelt-out is nice, but on the other, who ever actually types --revision?
[00:49] <maxb> vila: 2.3b4 now uploaded to bzr-beta-ppa/maverick. I have a feeling it's going to fail the testsuite though, based on local experimentation
[00:50] <spiv> fullermd: I think it may be as harmful as it is helpful to have yet another term for that added to the text.  Not sure.
[00:51] <fullermd> Well, I don't necessarily mean a formal Term, just the choice of verb.  You could call it "constructing the complement", but I'm not sure that would be helpful either  ;)
[00:54] <spiv> fullermd: sure.  My concern is basically that we should try to use as few different words for the same thing as possible, to avoid confusing new users that don't know all the nuances yet.
[00:57] <fullermd> Oh, yes.  But I think using 'remove' or 'revert' or the like is worse, because it implies incorrect things.  You're not _removing_ anything, you're creating a new thing on top that's an undo.
[00:58] <fullermd> But I'm half feverish at the moment, so I could be talking in Chinchilla or something for all I know...
[00:58] <achiang> there you go... "to undo..."
[01:06] <spiv> achiang, fullermd: https://code.launchpad.net/~spiv/bzr/tweak-revert-help/+merge/43036
[03:36] <sqwishy> When people make pushes to my branch, file permissions seem to get modified under the .bzr directory so that files are owned by whoever made the push. Is that normal or is my configuration wonky?
[06:43] <jmarsden> I just encountered a bzr crash, I reported it as bug #687266.  Anything else I can usefully do, or can anyone advise how to work around this? Running bzr 2.1.1-1 on Ubuntu 10.04.1
[06:48] <spiv> jmarsden: install the bzr-loom plugin
[06:49] <spiv> The error ought to be clearer, and say something like "Unrecognised branch format: 'Bazaar-NG Loom branch format 6\n'
[06:49] <spiv> " though.
[06:49] <jmarsden> spiv: OK, will do, but why is a plugin needed just to branch something from LP?  Is this a new requirement?
[06:51] <jmarsden> Seems to have worked, thanks.  I'll update the bug report with this workaround.
[06:51] <spiv> jmarsden: that branch has been created in the loom format
[06:52] <spiv> So you'd have to ask the branch owner why they chose to do that.  (Although it is a pretty common plugin, I like it!)
[06:52] <spiv> It's not a general requirement for branching from Launchpad.
[06:52] <spiv> Just for branches in that format :)
[06:52] <jmarsden> Ah, OK.  Good :)
[06:52] <spiv> Kind of like how you can't branch from an SVN branch without the bzr-svn plugin ;)
[06:53] <spiv> (Although of course LP doesn't host SVN natively)
[06:53] <jmarsden> Well, sure... but crashing because the plugin is not there does not seem like reasonable error handling (or reasonable UI)
[06:54] <spiv> Agreed, and I just updated the bug to say so :)
[06:55] <jmarsden> I should have refreshed my lp page before adding a comment :)  OK, thanks.
[07:20] <vila> grr why did libssl requires a reboot when upgraded oh why ?
[07:56] <vila> mgz: You're reading above my shoulder again... Thanks for fixing the last remaining failures on OSX-10.5 :D
[08:02] <vila> maxb: thanks for updating the beta ppa ! I don't get what you meant by 'fail the testsuite' though ?
[09:34] <vila> fullermd: ping
[09:35] <vila> sheesh, is he *sleeping* ? :D
[09:36] <fullermd> No, just sick.
[09:38] <jelmer> g'morning vila, fullermd!
[09:38] <vila> jelmer: hey !
[09:38] <vila> fullermd: oooh, may be you should... sleep then ? ;)
[09:39] <fullermd> I'd love too.  I've tried on and off for the last 18 hours   :|
[09:42] <vila> urgh, bad bad bad
[09:46] <vila> booo for lp going offline ! Yeah for timely notices on my last page refresh !!!
[09:48] <jelmer> :)
[09:55] <maxb> vila: 2.3b4 is in PPA for maverick I'll do the other series today. it surprised me by passing tests
[09:55] <vila> maxb: great !
[09:55] <maxb> bash_completion tests must be being upset by my local environment
[09:55] <vila> maxb: But I still don't get why you're surprised... haaaa
[09:56] <vila> maxb: I almost never see them fail on babune, so yeah, you may want to investigate locally
[09:57] <maxb> on the plus side, the ppa is now running all tests, not just --no-plugins
[09:58] <vila> maxb: wow, that's... a very good news :)
[10:10] <vila> http://babune.ladeuil.net:24842/job/selftest-osx-10.5/ BLUE !
[10:10] <vila> mgz: kudos !
[11:25] <mgz> yeay, a blue mac. now, why is 10.6 weird...
[11:26] <spiv> A blue mac?  Aren't those like 15 years old? :P
[11:26] <fullermd> That's why it took so long to get through the tests   :p
[11:26] <vila> mgz: so, the doc_generate ones are due to a version too recent (I think)
[11:27] <vila> the bzr_connect_to_bzr_ssh, well, I've stopped complaining about this test :(
[11:27] <mgz> the bp.launchpad ones also look like some kind of installation issue
[11:28] <vila> yeah probably, I should look into it and update the osx-installers requirements if that's the case
[11:28] <mgz> so, six failures from setup things, and one from ssh hating us.
[11:29] <vila> in the later case, it may well be an out of date paramiko (which is weird since we embed a patched one in the osx installer, but may be we don't patch the installed one)
[11:30] <vila> which in turn would mean *I* patched the 10.5 installed one... I just love untracked admin tweaks...
[11:30] <fullermd> You should get some kinda version control system to keep track of that stuff.
[11:31] <vila> good idea !
[11:31] <vila> The admins need to be lectured to use it though, which is the hardest part ;)
[11:32] <fullermd> So mass executions it is, then.  I'll warm up my lawnmower.
[11:34] <vila> weird, it seems launchpadlib is installed on 10.6 but not 10.5, so failing to import it on 10.5 masks the lazr.uri import error :)
[11:36] <mgz> that sounds fine, not having it means some things don't run.
[11:36] <mgz> but... launchpadlib should depend on lazr shouldn't it?
[11:37] <vila> hrm, no I think the problem is that 10.5 has apython-2.6 installed on top of the system provided 2.5 and the later is used to build installers but the former is used to run the tests
[11:37] <vila> that's *wrong*
[11:37] <fullermd> It's not wrong, it's *agile*!
[11:38] <vila> it should use the system-provided one or we're not tested what we should be testing %-)
[11:38] <vila> s/tested/testing/
[11:39] <vila> damn admins again
[11:40] <vila> mgz: launchpadlib shouldn't assume that it has been correctly packaged
[11:41] <mgz> hmmp...
[11:47] <vila> hmm, I kind of require that babune slaves have bzr installed (if only for bootstrapping), so this issue is naughty: the launchpadlib shipped in the osx installers lacks lazr.uri (all of lazr in fact), so making the tests succeed requires: a valid setup, requiring a valid launchpadlib packaged in the installed bzr...
[11:49] <mgz> hm. can you not unselect launchpadlib on install?
[11:49] <mgz> something to work out with the mac installers at any rate
[11:50] <vila> sounds like the fastest workaround, and I should discuss with doxxx why it included an incomplete launchpadlib there (which also requires a bunch of other stuff including simplejson, httplib2, oauth and whatnot)
[11:51] <vila> lunch time here, bbl
[11:52] <mgz> and I needed to leave ten mins ago.
[12:53] <echo-area> I'm not sure this: Does bzrtools add color support for bzr shelve?
[12:53] <echo-area> For I see colorful diffs after I installed bzrtools yesterday.
[13:40] <vila> mgz: even simpler is to make the tests check for the required module: https://code.launchpad.net/~vila/bzr/687315-lazr-uri/+merge/43079
[14:22] <vila> mgz: the ssh error on 10.6 is probably the paramiko bug involving ipv6 (it seems there is *no* way to disable v6 on lo0...)
[14:23] <vila> mgz: so the alternative is to carry spiv's patch for paramiko in the OSX installers...
[14:50] <mgz> I'm not convinced about the launchpadlib dependency thing, it's a deliberate pain to install because of that, if the mac installers work around and break it somehow, I think it's their bug.
[14:51] <mgz> However, carrying a patched paramiko I thought they did already, and will become increasingly nessersary.
[14:53] <vila> mgz: who is 'their' ?
[14:54] <mgz> the mac installer.
[14:54] <vila> mgz: yes, paramiko was patched but for the rng warning, not the ipv6 family (bug #579530)
[14:54] <vila> mgz: and the fix would be ?
[14:54] <mgz> okay, that one should just be added to the bundle as well.
[14:54] <vila> mgz: carrying more dependencies that are useless there ?
[14:54] <mgz> ^personally, I'd remove launchpadlib, the windows installers don't include it because it's a pain in the bum.
[14:54] <vila> mgz: I'm adding the paramiko patch right now
[14:55] <mgz> people who want to use lp-propose can install seperately.
[14:55] <mgz> otherwise, the dependencies need to be correctly bundled.
[14:56] <vila> mgz: are you sure it's only for lp-propose ?
[14:57] <mgz> and perhaps a couple of other neat little launchpad plugins commands one of the ABs added.
[14:57] <mgz> aaron?
[14:58] <mgz> you certainly don't need it to do basic lp interactions.
[15:00] <vila> rhaaa doxxx where are you ? :D
[15:00] <vila> and garyvdm... :-/
[16:14] <hazmat> is there any way to have bzr pipeline commands execute a hook prior to moving to the prev/next pipe, i'd like to cleanup cached pyc files, as they cause spurious conflicts when stepping through the pipeline
[16:25] <maxb> hazmat: erm, why would you have .pyc files under version control? Or do I misunderstand what you mean by conflict?
[16:26] <hazmat> maxb, there not under version control, but if i have them in a directory added in one pipe, and switch to one where the directory doesn't exist, bzr complains that it can remove the directories because their not empty (due to the pyc files), and i have manually resolve the conflict
[16:26] <hazmat> s/there/their
[16:26] <maxb> ah, I see
[16:27] <exarkun> hazmat: s/their/they're/ first ;)
[16:27] <hazmat> exarkun, indeed :-)
[16:27] <exarkun> I think I've had a similar problem with looms.  I haven't used pipelines yet.
[16:28] <maxb> Hmm, so really you need a pre_merge hook
[16:29] <maxb> I think the only thing you could do *right now* would be to wrap the switch-pipe command.
[16:30] <maxb> A more general solution would be to put a pre_merge hook into bzr core, and then hook that
[16:36] <hazmat> maxb, thanks, i think for now, i'll just hook,  PipelineManager.store_uncommitted to cleanup pyc files, its not elegant but it should solve the problem for me. a pre-merge hook looks like it would nicely as well.
[16:38] <rjek> Hi.  Is there web-based branch viewer like Loggerhead or bzrweb that won't make me miserable trying to read Python backtraces while trying to work out why they don't work?
[16:40] <Meths> launchpad does well at hiding traces and just telling you it doesn't work when it doesn't work. ;P
[16:40] <vila> hazmat: you want to try bzr.transform.orphan_policy=move
[16:41] <vila> hazmat: this requires bzr-2.3b2
[16:42] <hazmat> vila, interesting that would work as well
[16:43] <vila> hazmat: .pyc files are the primary target...
[16:53] <achiang> hello, i have a question regarding bzr bound branches -- i can't actually tell if i want one or not. i'm trying to work with the desktop team's libgtk2.0 branch, so what i've done so far is: bzr branch lp:~desktop-team/gtk/ubuntu ; bzr branch -r <lucid revspec> ubuntu lucid
[16:53] <achiang> that 2nd step created a bound branch for me (which i didn't realize until later)
[16:53] <achiang> ok, so i go into lucid, make a trivial change to debian/changelog, and then try a debcommit
[16:54] <achiang> now it complains about it being a bound branch
[16:54] <achiang> i go to the wiki and read about bound branches
[16:54] <achiang> and i can see that i can unbind my lucid branch
[16:54] <achiang> but... honestly, i don't know what the right thing to do here is
[16:55] <achiang> the idea is that i want to backport commits from the upstream 'ubuntu' branch back to this new 'lucid' branch that i created
[16:55] <vila> achiang: the second step didn't create a bound branch, you probably did something else to get it bound
[16:56] <vila> achiang: just 'bzr unbind' it until you need it to be bound
[16:56] <achiang> vila: oops, you're right -- i did a bzr checkout, not bzr branch
[16:56] <vila> achiang: *if* you ever need it to be bound
[16:57] <vila> achiang: ha, then 'bzr help reconfigure', I think you want 'bzr reconfigure --tree'
[16:58] <achiang> i'm just going to use the bzr branch command
[16:58] <vila> achiang: and 'bzr info' before/after to better understand where you are
[16:58] <vila> oh, if you can restart, then that's better
[16:58] <achiang> yes, like i said, i'm just playing around right now and have only made a single trivial change
[17:00] <achiang> vila: thanks for the help
[17:00] <vila> achiang: happy to help (TM)
[18:55] <knittl> why is log on a subdirectory slow as hell?
[19:56] <jubei__> is there a way to use a specific ssh key that is not ~/.ssh/id_dsa with bazaar ?
[19:58] <bob2> yes, configure it in ~/.ssh/config
[21:13] <rjek> Hi.  Is there web-based branch viewer like Loggerhead or bzrweb that won't make me miserable trying to read Python backtraces while trying to work out why they don't work?
[21:14] <rjek> bzrweb works to the extent that it can list the branches correctly, but then I get a meaningless backtrace from it when you try to visit a branch through it.
[21:14] <rjek> And loggerhead appears to have no documentation for setting it up at all, but you do get a meaningless (to me) backtrace if you try to run the enticingly-named "setup.py"
[21:49] <mgz> okay, so bzrlib.osutils.normalizepath is: ancient, undocumented, untested, and cruft-ridden
[21:50] <mgz> I'd love to just delete it, but this needs to land on all version 2.0 and up.
[23:02] <al`> hi all
[23:02] <al`> I seem to be unable to use plugins reliably
[23:03] <al`> or, at least, I cannot make work fast-import at all
[23:03] <al`> error is: "bzr: ERROR: Unable to import library "fastimport": No module named fastimport"
[23:05] <al`> however, ${PYTHONPATH}/bzrlib/plugins definitively contains a directory named "fastimport"
[23:07] <mgz> and `bzr plugins` lists it?
[23:08] <spiv> al`: I think the bzr-fastimport plugin relies on a python library called 'fastimport'
[23:08] <spiv> al`: so that may be what it is complaining about.
[23:09] <al`> yes
[23:09] <al`> modular crap
[23:10] <al`> of course, FreeBSD does not package this thing
[23:10] <al`> so I'll have to build it locally
[23:11] <maxb> I don't think it contains any compiled code, so the build should be trivial
[23:11] <al`> still
[23:11] <maxb> still?
[23:12] <al`> I should not have to get 15k different module to do what I'm doing
[23:12] <al`> that should be all shipped with bazaar, with minimal external dependency
[23:12] <al`> hopefully this will be my only contact with bazaar, ie. once this work, I'm going back to git
[23:15] <spiv> I wonder what al` is doing.
[23:17] <maxb> My guess is installing bzr & bzr-fastimport for a single operation, and getting unjustly annoyed about it
[23:17] <maxb> erm, wtf, in the topic: "http://irclogs.ubuntu.copingeling aboutm/"
[23:26] <knittl> does bzr use hardlinks when creating a local clone?
[23:49] <spiv> knittl: not by default, you can hardlink the files in the tree by passing the --hardlink option though
[23:53] <spiv> If you want to save space, you probably want to use a shared repository.  And if you want to save time, a shared repository is probably the best answer there too.  We've found that hardlinking the files in the working tree (which has to check each file to see if it has been modified) tends to be slower than just extracting the files directly out of the repository.
[23:55] <spiv> Shared repository + hardlinked working trees is the maximum space saving though, assuming you want to have multiple working trees on disk simultaneously, rather than one tree that you switch between your different branches.