[01:21] <Peng_> mwhudson: Hi.
[01:21] <mwhudson> Peng_: hi
[01:21] <Peng_> (Actually, I'm totally not here right now.)
[01:21] <mwhudson> i was going to ask something about loggerhead, but i forget wat
[01:21] <Peng_> mwhudson: Anyway, w -- ah.
[01:22] <mwhudson> 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] <igc> morning all
[01:22] <mwhudson> when i emerge from my pile of email
[01:22] <mwhudson> hello igc
[01:22] <Peng_> igc: Good morning. :)
[01:25] <Peng_> 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] <Peng_> If I do sleep for 2 years, please don't deprecate pack-0.92 while I'm gone. :D
[01:29] <igc> so today's focus for me: nested-tree review; benchmark, tweak & announce https://launchpad.net/bzr-historycache
[03:24] <levo> hey, anyone around to help a newbie? I'm having problems with getting rename to work.
[03:26] <levo> I modified and moved some files, but bzr mv complains the destination dir. isn't versioned
[03:26] <levo> 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] <Peng_> levo: Did you rename the dir as well? Have you bzr added it?
[03:27] <Peng_> levo: Hmm, not sure. But you may want "bzr mv --after".
[03:27] <levo> that's what I'm using, I can't find any way to get it to work though :/
[03:27] <Peng_> Oh.
[03:28] <Peng_> 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] <Peng_> Pastebinning the list of commands you ran may help.
[03:29] <levo> OK, thanks Peng, I'm not running the RC yet but I'll try that
[03:30] <bob2> did you ad the destination dir?
[03:30] <bob2> bzr add -N thatdir
[03:30] <bob2> then mv --after
[03:31] <levo> It says the target file is already versioned:
[03:31] <levo> bzr: ERROR: Could not move string.h => string.h: reusable/string.h is already versioned
[03:31] <Peng_> bob2: -N?
[03:32] <bob2> then un-add it
[03:32] <levo> to bzr add? it says no such option
[03:32] <bob2> what?
[03:32] <bob2> pastebin the output of 'bzr status'
[03:33] <levo> bzr add -N says no such option, not sure if that's what you mean though
[03:34] <bob2> pastebin the output of 'bzr status'
[03:34] <levo> http://pastebin.com/d6c2d994b
[03:37] <levo> I basically moved the directories 'test' and 'reusable' out of source up to the top level, sorry its kind of spammy
[03:37] <bob2> yowch
[03:37] <bob2> in future, use bzr mv
[03:37] <bob2> that is easy to recover, you also added a bunch of other files
[03:37] <levo> lol I'm hosed aren't I?
[03:38] <bob2> no
[03:38] <spiv> 1.14rc1 adds "bzr mv --auto" which would probably do a good job here.
[03:38] <spiv> (After unadding the moved files, of course)
[03:39] <bob2> 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] <bob2> or so
[03:40] <lifeless> spiv: whatcya up to today?
[03:40]  * bob2 wonders if he will ever shake ,,
[03:41] <levo> trying to parse all that, I'm on windows :p
[03:41] <bob2> yowch
[03:41] <lifeless> bob2: {{}}
[03:44] <spiv> lifeless: have finally upgraded to Jaunty, happily minimal fallout so far :)
[03:44] <spiv> 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] <Peng_> Stupid question because I'm lazy: Can "merge --uncommitted" work over a remote branch?
[03:45] <spiv> Peng_: off the top of my head, no, because we don't (yet?) support reading non-local working trees.
[03:45] <Peng_> Yeah, I just tried it, and you're right.
[03:51] <lifeless> PathNotChild: Path "/extra" is not a child of path "/extra/"
[03:53] <lifeless> spiv: it smells a little off
[04:01] <levo> thanks for the help everyone, I managed to get it all sorted out
[04:02] <levo> kind of understand why it wasn't working automatically now
[04:08] <levo> 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] <lifeless> I think there is a ui bug
[04:09] <lifeless> but I'm glad you're up and running
[04:10] <levo> thanks! and thanks for bzr, it's awesome
[04:26] <lifeless> spiv: ping
[04:26] <lifeless> spiv: How would you feel if we stopped PathNotChild occuring with foo, foo/
[04:48] <spiv> 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] <spiv> lifeless: I thought it did a bit of path normalisation before checking for PathNotChild?
[05:28] <BasicPRO> blah, bad time for LP to sit down
[05:32] <spm> BasicPRO: which part is sitting down?
[05:32] <BasicPRO> code
[05:34] <spm> wfm. can you give a url or similar?
[05:35] <BasicPRO> http://bazaar.launchpad.net/~tanner/bzr/1.14rc2/files
[05:36] <BasicPRO> click "NEWS"
[05:38] <spm> interesting. readme gives an internal error as well. mwhudson ^^ <==
[05:38]  * mwhudson looks
[05:39] <mwhudson> spm: it's timing out for me, is that what you mean?
[05:39] <BasicPRO> means I broke it? :-(
[05:39] <spm> mwhudson: partially. the NEWS file times out. README gives an informative "Internal Server Error" - nothing else :-(
[05:40] <mwhudson> i wonder if pygments is being insane, or annotate being slow
[05:40] <spm> bouncy time? see if that helps?
[05:41] <mwhudson> won't make a difference for the ISE
[05:44] <spm> mwhudson: I live in hope that it would :-)
[05:44] <mwhudson> um
[05:44] <mwhudson> BasicOSX: i presume "bzr annotate README" works for you?
[05:45] <BasicOSX> yes
[05:46] <mwhudson> hm
[05:50] <mwhudson> BasicOSX: bzr annotate http://bazaar.launchpad.net/~tanner/bzr/1.14rc2/README fails for me
[05:50] <mwhudson> BasicOSX: i don't know what's going wrong, but i plead NMF :)
[05:51] <BasicOSX> does that mean I did something wrong when I setup the branch?
[05:58] <spiv> BasicOSX: it appears you've been hit by bug 354036
[05:58] <BasicOSX> heh
[05:58] <spiv> BasicOSX: did you use your 1.14rc2 branch to push it up? :)
[05:58] <BasicOSX> bzr.dev
[05:58] <spiv> Huh!
[05:59] <spiv> That's a worry :(
[05:59] <BasicOSX> Bazaar (bzr) 1.15dev  r4299
[05:59] <BasicOSX> It would be initial push tho right?
[05:59] <BasicOSX> Not the last one I just did?
[05:59] <spiv> Right.
[05:59] <BasicOSX> that was bzr.dev before patch
[06:00] <spiv> As in, if any pushes had been done with unfixed bzr.dev...
[06:00] <spiv> Ah, phew :)
[06:01] <spiv> Ok that explains it then.  Deleting the branch (or at least deleting the remote .bzr dir) and repushing will fix the problem.
[06:02] <spiv> (I'm not sure that this is the cause of viewing README triggering Internal Server Error, although it could be)
[06:04] <lifeless> I don't think it is
[06:09] <BasicOSX> PQM playing 1.14rc2
[06:10] <lifeless> cool
[06:10] <lifeless> I'm beat; had a fluvax shot yesterday and my arm has been killing me
[06:10] <lifeless> if anyone needs me call my mobile
[06:22] <BasicOSX> grrr, comcast I hate you
[06:23] <mwhudson> spiv, lifeless: it is why viewing README triggers a 50x
[06:23] <mwhudson> at least, the error i got on the command line was the same one i found in the logs
[06:39] <spiv> mwhudson: which error?  I get a "No such file" on the command line.
[06:40] <mwhudson> spiv: maybe BasicOSX has done stuff to the branch already
[06:40] <mwhudson> it ended with
[06:40] <mwhudson>     parent_lines = [parent_cache[parent] for parent in parent_map[key]]
[06:40] <mwhudson> KeyError: ('README-20050309040720-8f368abf9f346b9d', 'abentley@panoramicfeedback.com-20070612162140-vea2zg1sbw6kckic')
[06:42] <spiv> mwhudson: ah ok.  Yes, that does look possibly related.
[08:56] <jelmer> moin
[09:13] <jelmer> looks like all working tree stuff on git indexes is working
[09:13] <jelmer> except for commits
[09:20] <robin_dewd> 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] <igc> me dinner
[09:24] <jelmer> robin_dewd: what didn't work exactly?
[09:24] <jelmer> there have been a lot of changes in the last few days
[09:25] <robin_dewd> i tried a couple of things with it
[09:25] <robin_dewd> one was to clone a git repository from github (I was excited alright ;-)
[09:25] <robin_dewd> other was to branch from a local repo on a near directory
[09:31] <jelmer> rockstar: if you can get it to blow up with the current version, please file bugs :-)
[09:31] <jelmer> I can get it to work on most things right now, I fixed a couple of nasty issues
[09:42] <bignose> how can I remove an un-wanted loom from a branch?
[09:50] <Kinnison> Not sure, the help for "combine-thread" suggests that will, in the future, unloomify a branch
[09:53] <lifeless> bignose: once it has only one thread its ~= to a branch; just export the thread and remove the loom
[09:53] <lifeless> bignose: obviously this could be improved
[09:54] <bignose> no hackery in the branch that can be done?
[09:55] <lifeless> not trivially no
[09:55] <lifeless> this would work:
[09:55] <lifeless> bzr export-thread ../foo
[09:55] <lifeless> rm -rf .bzr/branch
[09:56] <lifeless> mv ../foo/.bzr/branch .bzr
[09:56] <bignose> can I branch from a loomified branch, and specify that the new branch should *not* have a loom?
[09:56] <lifeless> not currently, its a good idea; you can export the top thread though
[09:56] <bignose> okay, that's the chosen workaround then.
[09:56] <bignose> thanks.
[09:57] <bignose> hmm wait, how do I export from one branch to another branch? exporting to a directory just exports a working tree.
[10:03] <bignose> oh, export-thread
[10:03] <bignose> an undocumented command :-(
[10:04] <bignose> actually, a non-existent command (bzr-loom 1.4.0~bzr93-2)
[10:05] <bignose> so, with no "branch without getting a loom" command, and with no "export-thread" command
[10:06] <bignose> how can I get a branch from branch 'foo/' without a loom?
[10:08] <lifeless> bignose: sorry, its just export-loom
[10:08] <lifeless> export-thread has been discussed not done
[10:13] <bignose> hmm. and if I have no threads, export-loom does nothing?
[10:15] <bignose> attempting to create a thread in a loom that has no threads gives an AssertionError
[10:15] <bignose> assert after_thread is None or after_thread in state.get_threads_dict()
[10:25] <lifeless> uhm, having no threads == having no branch - you have no tips at all
[10:25] <lifeless> I'm not sure how you'd even get to that state
[10:34] <bignose> well, 'bzr show-loom' shows no threads, but 'bzr info', 'bzr check' and 'bzr status' all seem happy
[10:34] <bignose> 'bzr log' shows revisions as expected
[10:36] <jelmer> 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] <jelmer> 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] <bignose> same when I branch; the new branch is also showing fine, but has no threads when I 'show-loom'
[10:36] <jelmer> lifless: that influences the decision of Commit() as to what to use?
[10:40] <bignose> 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] <bignose> but apparently I can't remove the loom.
[10:42] <lifeless> jelmer: I want to migrate to just ric
[10:43] <lifeless> jelmer: multiple codepaths indefinitely is not attractive
[10:49] <jelmer> lifeless: Ok
[10:49] <jelmer> lifeless: I'd like a way to say I'd always like ric then :-)
[10:49] <jelmer> lifeless: I already have that for bzr-git
[10:49] <jelmer> and I don't feel like implementing record_entry_contents, too
[10:51] <lifeless> jelmer: there is a comment in commit.py about this
[10:51] <lifeless> jelmer: until its safe in all those cases we can't force it to ric always
[10:51] <lifeless> it will be faster once we can, so its important to aim for that
[10:54] <jelmer> lifeless: hmmok
[10:55] <lifeless> 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] <lifeless> and iter_changes doesn't do excludes at all yet
[10:57] <lifeless> so the fastest way to get ric used only, is to fix these issues in bzr core
[11:01] <bignose> lifeless: okay, a workaround that worked:
[11:01] <bignose> bzr init bzr/ && cd bzr/ && bzr pull ../foo/
[11:01] <bignose> erm, s/init bzr/init bar/
[11:02] <bignose> causes the new branch 'bzr/' to have no loom but have all the revisions from 'foo/' as desired
[11:02] <bignose> argh
[11:02] <bignose> new branch 'bar/' that is.
[11:02] <bignose> damned muscle memory :-)
[11:08] <jelmer> lifeless: hmm
[11:29]  * bignose hopes all his wild assertions about Bazaar looms on the mailing list are actually true
[12:30] <finiteset> how do I checkout an old revision from my project?
[12:33] <lifeless> 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] <finiteset> I have a project using in bzr and I want to check  out an older revision of it  to a different location.
[13:02] <mars> why does the shelve command offer the options "yes", "no", "finish", and "quit"?  Shouldn't that be "yes", "no", "all", "quit"?
[13:03] <mars> ah, nevermind - finish means "done", doesn't it?  And quit actually means "abort"?
[13:52] <ddaa> Hello,
[13:53] <beuno> hi,
[13:53] <ddaa> 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] <ddaa> raised from File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 660, in add_inventory
[13:54] <ddaa> Any idea what that means, and how I can work around or fix this?
[13:54] <ddaa> I have no idea what this "write group" concept is. Is this something new?
[13:56] <ddaa> Mh... I guess I could try adding some repo.start_write_group() and repo.commit_write_group()...
[13:57] <ddaa> Maybe add in a couple of chicken bones.
[14:07] <ddaa> mh... it will probably be quicker to learn hg than to turn bzr-hg into something usable
[14:09] <lifeless> ddaa: jelmer has a bzr-hg branch that is more advanced, I believe
[14:10] <lifeless> ddaa: write groups are broadly transactions, they are the basis of packs
[14:10] <ddaa> lifeless: hello mate
[14:10] <lifeless> :) hi
[14:10] <ddaa> yup, actually, just after asking I started remembering, and used grep powers to find out the relevant methods.
[14:11] <ddaa> 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] <lifeless> catch you later
[14:12] <lifeless> <afk
[16:05] <LeoNerd> 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] <Kinnison> presumably you now have the bzr-gtk notification doobry running
[16:07] <Kinnison> look for "bzr-notify" in your process list
[16:10] <LeoNerd> 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] <Kinnison> I imagine it'll start on desktop start
[16:10] <Kinnison> see /etc/xdg/autostart
[16:11] <Kinnison> there'll be bzr-notify.desktop in there
[16:11] <Kinnison> not sure how you disable it short of rm -f the file
[16:11] <LeoNerd> Ahyes
[16:11]  * Kinnison just got used to it
[16:11] <Kinnison> :-)
[16:11] <LeoNerd> $ sudo mv bzr-notify.desktop bzr-notify.desktop.NOYOUFSCKINGDONT
[16:12] <LeoNerd> Hrm.. shame I can't even  chmod -x  it
[16:12] <awilkins> I saw an article that put forward the idea that .desktop files were the equivalent of Outlook worms for GNOME
[16:13] <LeoNerd> It is annoying that there doesn't seem to be a local policy override thing
[16:14] <Kinnison> No idea if removing it from the session applet would do the trick
[16:14] <Kinnison> sorry
[16:16] <Kamping_Kaiser> why dont you just remove the package?
[16:16] <Kinnison> bzrk is too useful I imagine
[16:16] <Kinnison> Unfortunately bzr-notify is part of bzr-gtk
[16:17] <ddaa> 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] <Kamping_Kaiser> ah
[16:17] <james_w> LeoNerd: cp /etc/xdg/autostart/bzr-notify.desktop ~/.local/share/applications/
[16:18] <james_w> then edit ~/.local/share/applications/bzr-notify.desktop to have "NoDisplay=True"
[16:18] <LeoNerd> Ya.. None of my files have +x on
[16:18] <james_w> "NoDisplay=true" perhaps
[16:18] <LeoNerd> james_w: Ahh.. Hrm.. Can I just set that value in /etc ?
[16:18] <LeoNerd> (go go magic negative-options)
[16:19] <james_w> yep
[16:21] <moquist> Is it possible for me to edit my bzr log messages after commit?
[16:21] <Kinnison> No[*]
[16:21] <moquist> james_w: hey! I was just dusting my bzr bd skillz off the other day and thought of you.
[16:21] <Kinnison> [*: Yes, but not really, erm, urp]
[16:22] <moquist> Kinnison: possible but highly discouraged?
[16:22] <ddaa> 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] <igc> night all - see you next week after I return from leave
[16:23] <ddaa> Of course, that will confuse merge/pull, etc for every branch out there that contains revisions that were changed/rebased.
[16:23] <moquist> 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] <ddaa> moquist: was that understandable, our do you need spelled it out more?
[16:23] <moquist> ddaa: maybe. I'll look into it first.
[16:24] <moquist> I might just inflict yeeps on the world.
[16:24] <ddaa> Here's how I would go about it:
[16:24] <ddaa> 1. inflict "yeep" on the world
[16:25] <moquist> ddaa: heh. Sounds good to me. :-D
[16:25] <ddaa> 2. failing that, for every revision do something like "merge -r2..3 ../orig; commit -m 'nice message'"
[16:25] <james_w> hey moquist
[16:25] <ddaa> when specifying a range to merge, you actually do (essentially) a diff+patch, without referring to the merged revisions in the parents.
[16:26] <ddaa> But it's going to be quite tedious if you have more than a half-dozen revisions.
[16:26] <moquist> ddaa: yeah. not too many more, but maybe 10-15 messages to change.
[16:28]  * Kinnison recommends option 1
[16:28] <Kinnison> with addendum: "Learn not to yeep in future"
[16:28]  * ddaa ruffles Kinnison.
[16:28] <moquist> yeah...that's the real moral of the story.
[16:28] <moquist> thx!
[16:31] <Kinnison> There's some *really* crap commit messages in the world from me
[16:31] <moquist> Kinnison: I pledge never to hold them against you.
[16:31] <Kinnison> So kind :-)
[16:38] <Keybuk> jelmer: so I installed bzr-git
[16:38] <Keybuk> and it doesn't show up in bzr plugins
[16:38] <Keybuk> and thumper said to ask you ;)
[16:39] <jelmer> Keybuk: Did you install the package or from the bzr branch?
[16:39] <jelmer> Keybuk: No warnings from bzr about it not being able to load the plugin ?
[16:40] <Keybuk> jelmer: the bzr branch
[16:40] <Keybuk> there is no package
[16:40] <Keybuk> wing-commander scott% apt-cache search bzr-git
[16:40] <Keybuk> wing-commander scott%
[16:41] <jelmer> Keybuk: It's not in Ubuntu (yet), just experimental for now
[16:41] <jelmer> The bzr branch is probably the best source for it for now anyway, given the rate of changes
[16:42] <jelmer> 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] <Keybuk> it went into /usr/local/lib somewhere
[16:42] <Keybuk> it doesn't work anyway - managed to get bzr to see it and it complained it needed 1.15
[16:44] <jelmer> ah, yes, it unfortunately does at the moment; remote git servers are a bit limited in what they support
[16:45] <jelmer> so I had to patch bzr, and that change won't land until 1.15
[16:47] <Keybuk> ok
[16:47] <Keybuk> oh well
[16:47]  * Kinnison wows
[16:47] <Kinnison> bzr managed to use my link fully just now
[16:47]  * Kinnison gives it the 1MB/s prize
[16:48] <jelmer> Kinnison: :-)
[16:49] <Kinnison> 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] <jelmer> Kinnison: Yeah, development has been going pretty quickly (un)fortunately
[17:07] <jelmer> Kinnison: I suspect it'll have slowed down enough for Koala
[17:08] <awilkins> 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] <awilkins> 1.4 MB/s would fit 10Mbit/s
[17:09]  * awilkins could also be mad
[17:11] <Kinnison> 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] <SamB_irssi> jelmer: how do I specify what user to use for a specific SVN server ?
[18:39] <joaopinto> hello, I am getting the "http does not support mkdir" that is usually related to the missing launchpad-login
[18:41] <joaopinto> 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] <cody-somerville> joaopinto, does it say that when you commit?
[18:45] <cody-somerville> joaopinto, ie. do you have a binded branch/checkout?
[18:45] <joaopinto> cody-somerville, yes, it shows the http branch
[18:46] <cody-somerville> joaopinto, just do bzr bind <bzr+ssh url>
[18:46] <joaopinto> ah
[18:48] <joaopinto> the bind operation does not report an error, but does not help either
[18:48] <joaopinto> Cannot lock LockDir(http://bazaar.launchpad.net/%7Egetdeb-web-developers/getdeb-web/main/.bzr/branch/lock)
[18:49] <SamB_irssi> jelmer: having to use "svn propdel" to get a username into the SVN auth cache isn't ideal!
[18:49] <SamB_irssi> hmm.
[18:49] <SamB_irssi> didn't even work?
[18:50] <joaopinto> cody-somerville, ops, bind did help, tks
[18:51] <cody-somerville> joaopinto, :)
[19:17] <LarstiQ> SamB_irssi: *blink*
[19:32] <stephank> 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] <stephank> My question is, how do I do merges across these three branches?
[19:32] <stephank> 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] <stephank> 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] <LarstiQ> 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] <LarstiQ> stephank: basically by doing `bzr merge stripped; bzr revert; bzr ci -m 'Reject strippage'`
[19:35] <LarstiQ> 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] <LarstiQ> 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] <stephank> LarstiQ: Aha! I'll try that out immediatly. :)
[19:37] <LarstiQ> (for which I don't want the Debian changelog entries that mess up the chronological order in the Ubuntu changelog)
[19:37] <LarstiQ> besides some real packaging differences
[19:39] <stephank> LarstiQ: hmm.. when I revert, it really reverts the merge as well, and the commit is not picking up any changes.
[19:40] <ddaa> stephank: you MUST do "revert ."
[19:40] <ddaa> the final dot is important
[19:40] <ddaa> or "revert $PATH" if you prefer
[19:40] <stephank> ddaa: Aha, ofcourse
[19:41] <LarstiQ> stephank: sorry, what ddaa said
[19:41] <LarstiQ> ddaa: I actually left the . off in my advice, mea culpa.
[19:42] <stephank> LarstiQ: no problem, thanks for the excellent help, and ddaa, this did the trick. :)
[20:26] <fbond> What's the word on merging ancestry with cherry-picks?
[20:33] <jelmer> SamB_irssi: hi
[20:34] <jelmer> SamB_irssi: still there?
[21:33] <SamB_irssi> jelmer: again
[21:33] <SamB_irssi> I am here again
[21:33] <SamB_irssi> jelmer: it's an https URL on sf.net, if that makes any difference
[21:35] <jelmer> SamB_irssi: hi
[21:35] <jelmer> SamB_irssi: Did you see the thread on the bazaar mailing list?
[21:36] <jelmer> SamB_irssi: basically, you need to use svn+https://
[21:37] <SamB_irssi> 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] <SamB_irssi> jelmer: I tried svn+https://
[21:37] <SamB_irssi> it didn't seem to help me get a "username" prompt
[21:37] <SamB_irssi> hmm.
[21:37] <SamB_irssi> maybe my bzr.dev is too old?
[21:38] <jelmer> SamB_irssi: which version of bzr are you running?
[21:38] <jelmer> SamB_irssi: you'd need a fairly recent one
[21:38] <jelmer> SamB_irssi: or bzr.foreign
[21:39] <SamB_irssi> 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] <LarstiQ> SamB_irssi: if there is more text after you scrolled up it says - more -
[21:41] <SamB_irssi> 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] <SamB_irssi> oh, there it is
[21:42] <SamB_irssi> LarstiQ: is there some way to change that to a different color?
[21:43] <LarstiQ> SamB_irssi: euh, I suppose
[21:43] <SamB_irssi> jelmer: ah, with latest bzr.dev it works better
[21:43] <LarstiQ> SamB_irssi: may I recommend the trackbar script to you?
[21:43] <SamB_irssi> now it just looks horrible ;-)
[21:43] <LarstiQ> SamB_irssi: it's white for me
[21:43] <SamB_irssi> LarstiQ: yeah, it was white here too
[21:44] <LarstiQ> SamB_irssi: I think I'm using whatever is default in Debian qua style
[21:44] <SamB_irssi> (the "ugly" refers to bzr-svn's username prompt, btw)
[21:45] <LarstiQ> ah :)
[21:46] <SamB_irssi> 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] <LarstiQ> what a naesty behaviour!
[21:47] <LarstiQ> ok, time for bed if my jokes are that bad
[21:47] <LarstiQ> ciao
[21:47] <SamB_irssi> 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] <SamB_irssi> arg, apparantly it found "naesten" cached???
[21:51] <jelmer> SamB_irssi: can you reproduce this with the latest bzr.foreign and the latest bzr-svn?
[21:52] <SamB_irssi> what's bzr.foreign ???
[21:53] <jelmer> SamB_irssi: http://people.samba.org/bzr/jelmer/bzr/foreign
[21:53] <SamB_irssi> that looks kind of like a dash to me ...
[21:53] <SamB_irssi> oh, wait
[21:53] <jelmer> 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] <SamB_irssi> different url
[21:53]  * SamB_irssi was looking at something from google with a desciptively similar sounding url
[21:54] <SamB_irssi> s/descip/descep
[21:56] <yacoob> is there any way to stop bzr from merging a file that has been deleted in destination branch?
[21:59] <james_w> yacoob: no, but if you revert that path after merging then it will be remembered
[22:00] <SamB_irssi> jelmer: okay, yes, I still have the problem
[22:01] <SamB_irssi> but it might now just be a configuration/cache issue of some kind
[22:01] <jelmer> SamB_irssi: so this is happening while you are pulling?
[22:01] <SamB_irssi> jelmer: I don't believe so
[22:01] <jelmer> SamB_irssi: so it's only while pushing?
[22:01] <jelmer> SamB_irssi: and Bazaar is asking you for a username+password more than once?
[22:02] <SamB_irssi> no credentials show up in ~/.bzr.log for pull
[22:02] <SamB_irssi> oh, actually I don't get any prompts now ...
[22:02] <SamB_irssi> sorry :-)
[22:02] <SamB_irssi> or ... one password prompt
[22:03] <SamB_irssi> for the wrong username, though
[22:04] <SamB_irssi> and I can't figure out where it's getting the username/password from :-(
[22:05] <jelmer> SamB_irssi: It should be getting it from ~/.subversion/auth if you tried to use svn itself on that URL before
[22:10] <SamB_irssi> This is my bzr.log output:
[22:10] <SamB_irssi> http://paste.lisp.org/display/78916
[22:11] <SamB_irssi> but I don't see anything in ~/.subversion/auth ...
[22:15] <jelmer> ah, bzr-svn wasn't prompting yet
[22:15] <jelmer> SamB_irssi: I'm pushing a fix for bzr-svn
[22:16] <SamB_irssi> jelmer: but I'm still puzzled as to where it came up with the "password"
[22:17] <SamB_irssi> jelmer: but I'm still puzzled as to where it came up with the "password"
[22:17] <SamB_irssi> 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] <asabil> hi all
[22:23] <asabil> is there a way to stop the Commit().commit() from using the progress bar ?
[22:24] <james_w> asabil: programatically?
[22:24] <asabil> james_w: yes
[22:24] <james_w> I think you pass in a progress bar
[22:24] <james_w> Dummy or Null or something
[22:26] <asabil> james_w: not for commit ()
[22:26] <james_w> ah
[22:27] <james_w> that sounds like an omission
[22:27] <jelmer> SamB_irssi: Just pushed it, to the 0.6 branch
[22:31] <SamB_irssi> jelmer: I still seem to have the same problem :-(
[22:31] <jelmer> SamB_irssi: It's not prompting you for a username?
[22:31] <SamB_irssi> indeed
[22:32] <SamB_irssi> but I also seem to need to pass --username to svn every time ...
[22:32] <jelmer> SamB_irssi: so it looks like the username is cached in ~/.subversion/auth then
[22:33] <SamB_irssi> I can't see it !
[22:34] <jelmer> SamB_irssi: have you grepped for it?
[22:34] <jelmer> it should be in one of the files in ~/.subversion/auth/svn.username/
[22:34] <asabil> jelmer: can you take a look at this branch: https://code.launchpad.net/~asabil/bzr-rebase/filter-branch ?
[22:35] <SamB_irssi> jelmer: I don't seem to *have* any files there
[22:36] <jelmer> SamB_irssi: I'm not sure where it gets it from then, but if svn is assuming it knows the username then bzr-svn probably would too
[22:36] <jelmer> asabil: sure, what about it?
[22:37] <asabil> jelmer: what do you think about merging it into the rebase plugin ?
[22:37] <asabil> and maybe rename bzr-rebase to bzr-rewrite ?
[22:37] <asabil> with all the history manipulation related commands
[22:38] <yacoob> james_w, doesn't quite work, still get conflicts on next merge.
[22:38] <james_w> yacoob: you did a "revert; commit; merge"?
[22:38] <james_w> and you get the same deleted conflict?
[22:40] <SamB_irssi> jelmer: hmm.
[22:40] <SamB_irssi> jelmer: would be nice if bzr-svn had a way to override that :-(
[22:40] <yacoob> merge from branch a to branch b, revert addition of a file x, commit. Then made a change in file x in branch a. Merge from a to be gives a conflict.
[22:44]  * SamB_irssi tries updating to a more recent subversion package
[22:45] <jelmer> asabil: can you send me a merge request?
[22:45] <asabil> jelmer: to your personal mail box ?
[22:45] <jelmer> asabil: I'm at a conference at the moment, don't have a lot of time to look into it atm
[22:45] <jelmer> asabil: yeah
[22:46] <asabil> jelmer: I can also ask for a merge from launchpad
[22:46] <jelmer> SamB_irssi: You can override it by specifying the username in the url
[22:46] <SamB_irssi> hmm ... it looks like if I hit "enter" at the password prompt for "naesten", vanilla svn asks me for another username
[22:46] <jelmer> asabil: Launchpad's merges don't include merge directives though unfortunately
[22:46] <SamB_irssi> jelmer: that didn't seem to work
[22:46] <asabil> jelmer:  okidoki, I will do then, thanks
[22:46] <SamB_irssi> I think ..
[22:47] <SamB_irssi> subversion doesn't seem to care if I put something before @ in the http url ?
[22:47] <SamB_irssi> er. https ...
[22:49] <yacoob> bug or feature?
[22:52] <jelmer> SamB_irssi: bzr-svn does
[22:52] <jelmer> yacoob: that's intentional
[22:52] <jelmer> yacoob: as bzr doesn't know what to do with changes to a file that's removed
[22:53] <jelmer> yacoob: it doesn't want to throw away those changes that have been made silently
[22:53] <yacoob> so I'd have to deal with this on every subsequent merge...
[22:55] <Peng_> Only if the file was modified.
[22:55] <yacoob> well, yes.
[22:55] <yacoob> no way to work around it, I presume?
[23:05]  * SamB_irssi heads home ... hasn't failed yet with the username@ in the URL, but he's still not happy about having to use that :-(
[23:06]  * SamB_irssi ... and it still might
[23:07] <lifeless> yacoob: you only have to deal with it once for each change; if upstream stop changing it it will stop conflicting
[23:08] <lifeless> yacoob: its arguably a bug to have subsequent changes generate conflicts again; could go either way - may be worth some discussion on the list
[23:09] <yacoob> lifeless, I'm the upstream :) and I keep config files in bzr. Branch a is 'desktop', b - 'laptop'. Some of the stuff is not needed on the laptop, so it would be nice to say once 'no, I don't need this on the laptop'.
[23:16] <lifeless> yacoob: righto; still the analogy holds
[23:16] <lifeless> you'd like the delete to stay deleted
[23:17] <lifeless> even on later changes to the file
[23:17] <yacoob>  very much so. I'll open a bug about that. --flag for this would be okay I think.
[23:24] <yacoob> https://bugs.launchpad.net/bzr/+bug/364336
[23:25] <yacoob> ah :>