[01:21] mwhudson: Hi. [01:21] Peng_: hi [01:21] (Actually, I'm totally not here right now.) [01:21] i was going to ask something about loggerhead, but i forget wat [01:21] mwhudson: Anyway, w -- ah. [01:22] i was probably just going to tell you to merge your branches, but i see they have merge proposals so i'll comment there i guess :) [01:22] morning all [01:22] when i emerge from my pile of email [01:22] hello igc [01:22] igc: Good morning. :) [01:25] Well, if you remember what it was, I should be back in maybe 30 minutes. Or maybe 1-2 years; I'm a bit tired. :D [01:25] If I do sleep for 2 years, please don't deprecate pack-0.92 while I'm gone. :D [01:29] so today's focus for me: nested-tree review; benchmark, tweak & announce https://launchpad.net/bzr-historycache === TheMuso_ is now known as TheMuso [03:24] hey, anyone around to help a newbie? I'm having problems with getting rename to work. [03:26] I modified and moved some files, but bzr mv complains the destination dir. isn't versioned [03:26] or if I add the destination dir, it complains the source isn't versioned, but it's marked as removed in bzr status [03:26] levo: Did you rename the dir as well? Have you bzr added it? [03:27] levo: Hmm, not sure. But you may want "bzr mv --after". [03:27] that's what I'm using, I can't find any way to get it to work though :/ [03:27] Oh. [03:28] My only other suggestion is that a newer version of bzr might be better, but I really don't know. Sorry. [03:28] * Peng_ hopes someone else is here. [03:28] Pastebinning the list of commands you ran may help. [03:29] OK, thanks Peng, I'm not running the RC yet but I'll try that [03:30] did you ad the destination dir? [03:30] bzr add -N thatdir [03:30] then mv --after [03:31] It says the target file is already versioned: [03:31] bzr: ERROR: Could not move string.h => string.h: reusable/string.h is already versioned [03:31] bob2: -N? [03:32] then un-add it [03:32] to bzr add? it says no such option [03:32] what? [03:32] pastebin the output of 'bzr status' [03:33] bzr add -N says no such option, not sure if that's what you mean though [03:34] pastebin the output of 'bzr status' [03:34] http://pastebin.com/d6c2d994b [03:37] I basically moved the directories 'test' and 'reusable' out of source up to the top level, sorry its kind of spammy [03:37] yowch [03:37] in future, use bzr mv [03:37] that is easy to recover, you also added a bunch of other files [03:37] lol I'm hosed aren't I? [03:38] no [03:38] 1.14rc1 adds "bzr mv --auto" which would probably do a good job here. [03:38] (After unadding the moved files, of course) [03:39] mv reusable/threading/ ,,f ; for thing in resuable/* ; do bzr rm --keep $thing ; bzr mv --after rc/$thing $thing ; done ; mv ,,f reusable/threading [03:39] or so [03:40] spiv: whatcya up to today? [03:40] * bob2 wonders if he will ever shake ,, [03:41] trying to parse all that, I'm on windows :p [03:41] yowch [03:41] bob2: {{}} [03:44] lifeless: have finally upgraded to Jaunty, happily minimal fallout so far :) [03:44] lifeless: am about to embark on lunch, but would love a review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090417141519.GA9721%40steerpike.home.puzzling.org%3E [03:44] Stupid question because I'm lazy: Can "merge --uncommitted" work over a remote branch? [03:45] Peng_: off the top of my head, no, because we don't (yet?) support reading non-local working trees. [03:45] Yeah, I just tried it, and you're right. [03:51] PathNotChild: Path "/extra" is not a child of path "/extra/" [03:53] spiv: it smells a little off [04:01] thanks for the help everyone, I managed to get it all sorted out [04:02] kind of understand why it wasn't working automatically now [04:08] kind of a confusing diagnostic to say that the source isn't versioned, although I don't know what it should say instead since I don't understand exactly why it couldn't be moved in terms of the internal mechanics [04:09] I think there is a ui bug [04:09] but I'm glad you're up and running [04:10] thanks! and thanks for bzr, it's awesome [04:26] spiv: ping [04:26] spiv: How would you feel if we stopped PathNotChild occuring with foo, foo/ [04:48] lifeless: so long as there's no risk of foobar being accidentally allowed, I suppose it's ok. I'm a little surprised it's not already accepted come to think of it. [04:48] lifeless: I thought it did a bit of path normalisation before checking for PathNotChild? === abentley1 is now known as abentley === abentley1 is now known as abentley [05:28] blah, bad time for LP to sit down [05:32] BasicPRO: which part is sitting down? [05:32] code [05:34] wfm. can you give a url or similar? [05:35] http://bazaar.launchpad.net/~tanner/bzr/1.14rc2/files [05:36] click "NEWS" [05:38] interesting. readme gives an internal error as well. mwhudson ^^ <== [05:38] * mwhudson looks [05:39] spm: it's timing out for me, is that what you mean? [05:39] means I broke it? :-( === BasicPRO is now known as BasicOSX [05:39] mwhudson: partially. the NEWS file times out. README gives an informative "Internal Server Error" - nothing else :-( [05:40] i wonder if pygments is being insane, or annotate being slow [05:40] bouncy time? see if that helps? [05:41] won't make a difference for the ISE [05:44] mwhudson: I live in hope that it would :-) [05:44] um [05:44] BasicOSX: i presume "bzr annotate README" works for you? [05:45] yes [05:46] hm [05:50] BasicOSX: bzr annotate http://bazaar.launchpad.net/~tanner/bzr/1.14rc2/README fails for me [05:50] BasicOSX: i don't know what's going wrong, but i plead NMF :) [05:51] does that mean I did something wrong when I setup the branch? [05:58] BasicOSX: it appears you've been hit by bug 354036 [05:58] Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] https://launchpad.net/bugs/354036 [05:58] heh [05:58] BasicOSX: did you use your 1.14rc2 branch to push it up? :) [05:58] bzr.dev [05:58] Huh! [05:59] That's a worry :( [05:59] Bazaar (bzr) 1.15dev r4299 [05:59] It would be initial push tho right? [05:59] Not the last one I just did? [05:59] Right. [05:59] that was bzr.dev before patch [06:00] As in, if any pushes had been done with unfixed bzr.dev... [06:00] Ah, phew :) [06:01] Ok that explains it then. Deleting the branch (or at least deleting the remote .bzr dir) and repushing will fix the problem. [06:02] (I'm not sure that this is the cause of viewing README triggering Internal Server Error, although it could be) [06:04] I don't think it is [06:09] PQM playing 1.14rc2 [06:10] cool [06:10] I'm beat; had a fluvax shot yesterday and my arm has been killing me [06:10] if anyone needs me call my mobile [06:22] grrr, comcast I hate you [06:23] spiv, lifeless: it is why viewing README triggers a 50x [06:23] at least, the error i got on the command line was the same one i found in the logs [06:39] mwhudson: which error? I get a "No such file" on the command line. [06:40] spiv: maybe BasicOSX has done stuff to the branch already [06:40] it ended with [06:40] parent_lines = [parent_cache[parent] for parent in parent_map[key]] [06:40] KeyError: ('README-20050309040720-8f368abf9f346b9d', 'abentley@panoramicfeedback.com-20070612162140-vea2zg1sbw6kckic') [06:42] mwhudson: ah ok. Yes, that does look possibly related. [08:56] moin [09:13] looks like all working tree stuff on git indexes is working [09:13] except for commits === BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.14rc2 released 20 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [09:20] cool. :-) I got your dulwich and bzr-git stuff from trunks I think and even updated bazaar to trunk as well (1.15dev) and was not able to make much with it at this point [09:20] me dinner [09:24] robin_dewd: what didn't work exactly? [09:24] there have been a lot of changes in the last few days [09:25] i tried a couple of things with it [09:25] one was to clone a git repository from github (I was excited alright ;-) [09:25] other was to branch from a local repo on a near directory [09:31] rockstar: if you can get it to blow up with the current version, please file bugs :-) [09:31] I can get it to work on most things right now, I fixed a couple of nasty issues [09:42] how can I remove an un-wanted loom from a branch? [09:50] Not sure, the help for "combine-thread" suggests that will, in the future, unloomify a branch [09:53] bignose: once it has only one thread its ~= to a branch; just export the thread and remove the loom [09:53] bignose: obviously this could be improved [09:54] no hackery in the branch that can be done? [09:55] not trivially no [09:55] this would work: [09:55] bzr export-thread ../foo [09:55] rm -rf .bzr/branch [09:56] mv ../foo/.bzr/branch .bzr [09:56] can I branch from a loomified branch, and specify that the new branch should *not* have a loom? [09:56] not currently, its a good idea; you can export the top thread though [09:56] okay, that's the chosen workaround then. [09:56] thanks. [09:57] hmm wait, how do I export from one branch to another branch? exporting to a directory just exports a working tree. [10:03] oh, export-thread [10:03] an undocumented command :-( [10:04] actually, a non-existent command (bzr-loom 1.4.0~bzr93-2) [10:05] so, with no "branch without getting a loom" command, and with no "export-thread" command [10:06] how can I get a branch from branch 'foo/' without a loom? [10:08] bignose: sorry, its just export-loom [10:08] export-thread has been discussed not done [10:13] hmm. and if I have no threads, export-loom does nothing? [10:15] attempting to create a thread in a loom that has no threads gives an AssertionError [10:15] assert after_thread is None or after_thread in state.get_threads_dict() [10:25] uhm, having no threads == having no branch - you have no tips at all [10:25] I'm not sure how you'd even get to that state [10:34] well, 'bzr show-loom' shows no threads, but 'bzr info', 'bzr check' and 'bzr status' all seem happy [10:34] 'bzr log' shows revisions as expected [10:36] lifeless: so, it would be nice if it would be possible to support just record_iter_changes() or record_entry_contents() in CommitBuilder implementations [10:36] lifeless: does it sound sensible to e.g. add a "supports_record_iter_changes" and a "supports_record_entry" contents variable to CommitBuilder [10:36] same when I branch; the new branch is also showing fine, but has no threads when I 'show-loom' [10:36] lifless: that influences the decision of Commit() as to what to use? [10:40] so, I'm stuck on this branch; if the loom is broken, I don't know what else might break and I don't want to continue relying on this branch [10:40] but apparently I can't remove the loom. [10:42] jelmer: I want to migrate to just ric [10:43] jelmer: multiple codepaths indefinitely is not attractive [10:49] lifeless: Ok [10:49] lifeless: I'd like a way to say I'd always like ric then :-) [10:49] lifeless: I already have that for bzr-git [10:49] and I don't feel like implementing record_entry_contents, too [10:51] jelmer: there is a comment in commit.py about this [10:51] jelmer: until its safe in all those cases we can't force it to ric always [10:51] it will be faster once we can, so its important to aim for that === Bambi_BOFH is now known as Kamping_Kaiser [10:54] lifeless: hmmok [10:55] jelmer: in particular you can't have a iter_changes on your trees that is actually both correct-for-status and correct-for-commit when new directories are added and specific files is selected [10:57] and iter_changes doesn't do excludes at all yet [10:57] so the fastest way to get ric used only, is to fix these issues in bzr core [11:01] lifeless: okay, a workaround that worked: [11:01] bzr init bzr/ && cd bzr/ && bzr pull ../foo/ [11:01] erm, s/init bzr/init bar/ [11:02] causes the new branch 'bzr/' to have no loom but have all the revisions from 'foo/' as desired [11:02] argh [11:02] new branch 'bar/' that is. [11:02] damned muscle memory :-) [11:08] lifeless: hmm [11:29] * bignose hopes all his wild assertions about Bazaar looms on the mailing list are actually true [12:30] how do I checkout an old revision from my project? [12:33] if you have a tree you're in, bzr revert -r X, or if you want a new tree, bzr branch -r X sourcebranch / bzr checkout -r X sourcebranch [12:35] I have a project using in bzr and I want to check out an older revision of it to a different location. [13:02] why does the shelve command offer the options "yes", "no", "finish", and "quit"? Shouldn't that be "yes", "no", "all", "quit"? [13:03] ah, nevermind - finish means "done", doesn't it? And quit actually means "abort"? [13:52] Hello, [13:53] hi, [13:53] When trying to use bzr-hg, "bzr pull ../hg-branch" fail with a "AssertionError: KnitPackRepository('file:///home/david/Documents/Akamao/akamao.bzr/.bzr/repository/') not in write group" [13:53] raised from File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 660, in add_inventory [13:54] Any idea what that means, and how I can work around or fix this? [13:54] I have no idea what this "write group" concept is. Is this something new? [13:56] Mh... I guess I could try adding some repo.start_write_group() and repo.commit_write_group()... [13:57] Maybe add in a couple of chicken bones. [14:07] mh... it will probably be quicker to learn hg than to turn bzr-hg into something usable [14:09] ddaa: jelmer has a bzr-hg branch that is more advanced, I believe [14:10] ddaa: write groups are broadly transactions, they are the basis of packs [14:10] lifeless: hello mate [14:10] :) hi [14:10] yup, actually, just after asking I started remembering, and used grep powers to find out the relevant methods. [14:11] I patched the write-group thing, but now I have an error where the branch head revision cannot be found in the repo. [14:12] * ddaa is using launchpad's trunk, is going to check whether jelmer has an active personal branch. [14:12] catch you later [14:12] How do I stop this fscking annoying popup window that says there's a new revision, every time I commit to a branch? It seems to have started recently, since a debian update... [16:07] presumably you now have the bzr-gtk notification doobry running [16:07] look for "bzr-notify" in your process list [16:10] Ahyes. There it is. Just kill it? Or will something start it up again? [16:10] * ddaa is kinda puzzled at how mercurial requires one to edit the ~/.hgrc in a trivial way to enable bundled extensions. [16:10] I imagine it'll start on desktop start [16:10] see /etc/xdg/autostart [16:11] there'll be bzr-notify.desktop in there [16:11] not sure how you disable it short of rm -f the file [16:11] Ahyes [16:11] * Kinnison just got used to it [16:11] :-) [16:11] $ sudo mv bzr-notify.desktop bzr-notify.desktop.NOYOUFSCKINGDONT [16:12] Hrm.. shame I can't even chmod -x it [16:12] I saw an article that put forward the idea that .desktop files were the equivalent of Outlook worms for GNOME [16:13] It is annoying that there doesn't seem to be a local policy override thing [16:14] No idea if removing it from the session applet would do the trick [16:14] sorry [16:16] why dont you just remove the package? [16:16] bzrk is too useful I imagine [16:16] Unfortunately bzr-notify is part of bzr-gtk [16:17] awilkins: it's not nearly as bad it sounds. The problem basically is that the rest of the system assumes that not setting the execute permission on a file will prevent it from being executed accidentally, but .desktop files can be executed by nautilus regardless of the execute permission. [16:17] ah [16:17] LeoNerd: cp /etc/xdg/autostart/bzr-notify.desktop ~/.local/share/applications/ [16:18] then edit ~/.local/share/applications/bzr-notify.desktop to have "NoDisplay=True" [16:18] Ya.. None of my files have +x on [16:18] "NoDisplay=true" perhaps [16:18] james_w: Ahh.. Hrm.. Can I just set that value in /etc ? [16:18] (go go magic negative-options) [16:19] yep [16:21] Is it possible for me to edit my bzr log messages after commit? [16:21] No[*] [16:21] james_w: hey! I was just dusting my bzr bd skillz off the other day and thought of you. [16:21] [*: Yes, but not really, erm, urp] [16:22] Kinnison: possible but highly discouraged? [16:22] moquist: [*] you can get a similar effect using uncommit, and rebase if you want to change a commit message that is before other commits you do not want to change. [16:22] night all - see you next week after I return from leave [16:23] Of course, that will confuse merge/pull, etc for every branch out there that contains revisions that were changed/rebased. [16:23] ddaa: Hmm. I have lots of messages that say (e.g.) "yeep" b/c I was just making tiny changes in my own repo...but now I want to publish this, and I figure the rest of the world won't find "yeep" very helpful. [16:23] moquist: was that understandable, our do you need spelled it out more? [16:23] ddaa: maybe. I'll look into it first. [16:24] I might just inflict yeeps on the world. [16:24] Here's how I would go about it: [16:24] 1. inflict "yeep" on the world [16:25] ddaa: heh. Sounds good to me. :-D [16:25] 2. failing that, for every revision do something like "merge -r2..3 ../orig; commit -m 'nice message'" [16:25] hey moquist [16:25] when specifying a range to merge, you actually do (essentially) a diff+patch, without referring to the merged revisions in the parents. [16:26] But it's going to be quite tedious if you have more than a half-dozen revisions. [16:26] ddaa: yeah. not too many more, but maybe 10-15 messages to change. [16:28] * Kinnison recommends option 1 [16:28] with addendum: "Learn not to yeep in future" [16:28] * ddaa ruffles Kinnison. [16:28] yeah...that's the real moral of the story. [16:28] thx! [16:31] There's some *really* crap commit messages in the world from me [16:31] Kinnison: I pledge never to hold them against you. [16:31] So kind :-) [16:38] jelmer: so I installed bzr-git [16:38] and it doesn't show up in bzr plugins [16:38] and thumper said to ask you ;) [16:39] Keybuk: Did you install the package or from the bzr branch? [16:39] Keybuk: No warnings from bzr about it not being able to load the plugin ? [16:40] jelmer: the bzr branch [16:40] there is no package [16:40] wing-commander scott% apt-cache search bzr-git [16:40] wing-commander scott% [16:41] Keybuk: It's not in Ubuntu (yet), just experimental for now [16:41] The bzr branch is probably the best source for it for now anyway, given the rate of changes [16:42] Keybuk: So you have it in ~/.bazaar/plugins/git, are there any warnings about it not being able to load in ~/.bzr.log? [16:42] it went into /usr/local/lib somewhere [16:42] it doesn't work anyway - managed to get bzr to see it and it complained it needed 1.15 === thekorn_ is now known as thekorn [16:44] ah, yes, it unfortunately does at the moment; remote git servers are a bit limited in what they support [16:45] so I had to patch bzr, and that change won't land until 1.15 [16:47] ok [16:47] oh well [16:47] * Kinnison wows [16:47] bzr managed to use my link fully just now [16:47] * Kinnison gives it the 1MB/s prize [16:48] Kinnison: :-) [16:49] hah, now it's lying, claiming 1.4MB/s which is faster than my link goes, while actually doing bugger all network traffic [16:50] * Kinnison takes the prize back and gives bzr a wooden spoon [16:57] * Kinnison pouts -- python-dulwich is too old in intrepid [17:06] Kinnison: Yeah, development has been going pretty quickly (un)fortunately [17:07] Kinnison: I suspect it'll have slowed down enough for Koala [17:08] Kinnison: Is is possible your 2MBit/s connection has just been upgraded to 10Mbit/s - your ISP is doing that. I only noticed when things went _pchow_. [17:08] 1.4 MB/s would fit 10Mbit/s [17:09] * awilkins could also be mad [17:11] awilkins: Erm, the only thing I'm waiting for is my 10Mbit/s service to be upgraded to 20Mbit/s [17:11] * Kinnison is on business-grade cable [17:28] * SamB_irssi attempts to push to SVN using bzr-svn ... [17:37] jelmer: how do I specify what user to use for a specific SVN server ? === bob2 is now known as Guest28542 [18:39] hello, I am getting the "http does not support mkdir" that is usually related to the missing launchpad-login [18:41] I need to commit some changes, and it's always trying to use the http method, how to I change it to bzr+ssh ? [18:45] joaopinto, does it say that when you commit? [18:45] joaopinto, ie. do you have a binded branch/checkout? [18:45] cody-somerville, yes, it shows the http branch [18:46] joaopinto, just do bzr bind [18:46] ah [18:48] the bind operation does not report an error, but does not help either [18:48] Cannot lock LockDir(http://bazaar.launchpad.net/%7Egetdeb-web-developers/getdeb-web/main/.bzr/branch/lock) [18:49] jelmer: having to use "svn propdel" to get a username into the SVN auth cache isn't ideal! [18:49] hmm. [18:49] didn't even work? [18:50] cody-somerville, ops, bind did help, tks [18:51] joaopinto, :) [19:17] SamB_irssi: *blink* [19:32] I have a project I started working on in a bazaar tree. Now I'd like to reuse large parts of this application for another customer. I stripped down the application to remove functionality specific to my first customer, and now have a bazaar branch with a minimal functional version of the application. Now I'm about to branch that again so I can start work for the new customer. [19:32] My question is, how do I do merges across these three branches? [19:32] If I merge changes from the shared branch back into my original branch for customer 'A', I'd lose all the functionality because it take in the commits where I stripped everything down. [19:33] Basically, I want to move to a /\ shape, but at the moment only have the bottom left node of that graph. [19:33] * LarstiQ nods [19:34] stephank: I haven't tested it out to that level, but what you should be able to do is merge your stripped branch into A, and then reject all the changes. [19:35] stephank: basically by doing `bzr merge stripped; bzr revert; bzr ci -m 'Reject strippage'` [19:35] stephank: afaics that should from then on allow you to merge changes without having to deal with the huge diff of removed functionality each time. [19:36] stephank: I do something similar like this (but only two branches) for merging the Debian unstable packaging of bzr-svn into the Ubuntu bzr-svn ppa packages [19:36] LarstiQ: Aha! I'll try that out immediatly. :) [19:37] (for which I don't want the Debian changelog entries that mess up the chronological order in the Ubuntu changelog) [19:37] besides some real packaging differences [19:39] LarstiQ: hmm.. when I revert, it really reverts the merge as well, and the commit is not picking up any changes. [19:40] stephank: you MUST do "revert ." [19:40] the final dot is important [19:40] or "revert $PATH" if you prefer [19:40] ddaa: Aha, ofcourse [19:41] stephank: sorry, what ddaa said [19:41] ddaa: I actually left the . off in my advice, mea culpa. [19:42] LarstiQ: no problem, thanks for the excellent help, and ddaa, this did the trick. :) [20:26] What's the word on merging ancestry with cherry-picks? [20:33] SamB_irssi: hi [20:34] SamB_irssi: still there? === thunderstruck is now known as gnomefreak === thunderstruck is now known as gnomefreak [21:33] jelmer: again [21:33] I am here again [21:33] jelmer: it's an https URL on sf.net, if that makes any difference [21:35] SamB_irssi: hi [21:35] SamB_irssi: Did you see the thread on the bazaar mailing list? [21:36] SamB_irssi: basically, you need to use svn+https:// [21:37] jelmer: on a completely different subject, are you going to vote for http://bundlebuggy.aaronbentley.com/project/bzr/request/%3CE1LupWj-0005Cp-WD%40hydrogen%3E ? [21:37] jelmer: I tried svn+https:// [21:37] it didn't seem to help me get a "username" prompt [21:37] hmm. [21:37] maybe my bzr.dev is too old? [21:38] SamB_irssi: which version of bzr are you running? [21:38] SamB_irssi: you'd need a fairly recent one [21:38] SamB_irssi: or bzr.foreign [21:39] fwiw, svn+https:// failed in the same exact way, not in a different way -- it asked me for the password for "naesten" [21:39] * SamB_irssi wonders if there is a way to make irssi warn you that you are scrolled up [21:40] SamB_irssi: if there is more text after you scrolled up it says - more - [21:41] LarstiQ: where does that show up? [21:41] * SamB_irssi waits for someone to say something so he can see where it shows up [21:41] oh, there it is [21:42] LarstiQ: is there some way to change that to a different color? [21:43] SamB_irssi: euh, I suppose [21:43] jelmer: ah, with latest bzr.dev it works better [21:43] SamB_irssi: may I recommend the trackbar script to you? [21:43] now it just looks horrible ;-) [21:43] SamB_irssi: it's white for me [21:43] LarstiQ: yeah, it was white here too [21:44] SamB_irssi: I think I'm using whatever is default in Debian qua style [21:44] (the "ugly" refers to bzr-svn's username prompt, btw) [21:45] ah :) [21:46] jelmer: uh-oh ... it's asking me first for a username, then for a password ... but now it's asking me for a password for naesten again! [21:47] what a naesty behaviour! [21:47] ok, time for bed if my jokes are that bad [21:47] ciao [21:47] that is, first it asks for a username and I say "sbronson" ... then it asks for a password for sbronson ... then it asks for a password for naesten! [21:48] * SamB_irssi puts back the svn+ [21:50] arg, apparantly it found "naesten" cached??? [21:51] SamB_irssi: can you reproduce this with the latest bzr.foreign and the latest bzr-svn? [21:52] what's bzr.foreign ??? [21:53] SamB_irssi: http://people.samba.org/bzr/jelmer/bzr/foreign [21:53] that looks kind of like a dash to me ... [21:53] oh, wait [21:53] contains a few pending patches for bzr.dev and a workaround for the fact that bzr.dev asks for passwords more often than necessary [21:53] different url [21:53] * SamB_irssi was looking at something from google with a desciptively similar sounding url [21:54] s/descip/descep [21:56] is there any way to stop bzr from merging a file that has been deleted in destination branch? [21:59] yacoob: no, but if you revert that path after merging then it will be remembered [22:00] jelmer: okay, yes, I still have the problem [22:01] but it might now just be a configuration/cache issue of some kind [22:01] SamB_irssi: so this is happening while you are pulling? [22:01] jelmer: I don't believe so [22:01] SamB_irssi: so it's only while pushing? [22:01] SamB_irssi: and Bazaar is asking you for a username+password more than once? [22:02] no credentials show up in ~/.bzr.log for pull [22:02] oh, actually I don't get any prompts now ... [22:02] sorry :-) [22:02] or ... one password prompt [22:03] for the wrong username, though [22:04] and I can't figure out where it's getting the username/password from :-( [22:05] SamB_irssi: It should be getting it from ~/.subversion/auth if you tried to use svn itself on that URL before [22:10] This is my bzr.log output: [22:10] http://paste.lisp.org/display/78916 [22:11] but I don't see anything in ~/.subversion/auth ... [22:15] ah, bzr-svn wasn't prompting yet [22:15] SamB_irssi: I'm pushing a fix for bzr-svn [22:16] jelmer: but I'm still puzzled as to where it came up with the "password" [22:17] jelmer: but I'm still puzzled as to where it came up with the "password" [22:17] EWIN [22:17] * SamB_irssi meant to re-do a bzr pull ... [22:18] * SamB_irssi wonders when/where jelmer is pushing it [22:23] hi all [22:23] is there a way to stop the Commit().commit() from using the progress bar ? [22:24] asabil: programatically? [22:24] james_w: yes [22:24] I think you pass in a progress bar [22:24] Dummy or Null or something [22:26] james_w: not for commit () [22:26] ah [22:27]