[03:23] <blueglasses> I already have a branch called testingbzr. How do I create a new branch to put the real code?
[03:24] <blueglasses> I use launchpad btw
[03:28] <blueglasses> anyone?
[03:32] <spiv> blueglasses: you have a branch locally already?
[03:33] <spiv> blueglasses: if so, just push it to where you want it to be on launchpad, e.g. "bzr push lp:~username/projectname/new-branch"
[03:33] <blueglasses> i dont think so, let me check
[03:33] <spiv> Well, perhaps I'm misunderstanding what you're asking.
[03:34] <spiv> What do you mean by "create a new branch"?  You mean start a new branch from scratch, with no prior history?
[03:34] <blueglasses> locally i have /home/user/python/projectname/files
[03:35] <spiv> And is that directory already versioned in bzr?
[03:35] <blueglasses> i think so
[03:35] <spiv> "bzr info" or "bzr log" or whatever would confirm that if you like.
[03:35] <blueglasses> i'm not a native english speaker sorry for my delay
[03:35] <spiv> That's fine!
[03:36] <spiv> I can only speak one language, so I'm already impressed :)
[03:36] <blueglasses> I'm trying to use bazaar explorer
[03:37] <blueglasses> how do I create a new branch... I might have done something wrong
[03:37] <blueglasses> my project name in lauchpad is "story"
[03:37] <spiv> Ok.  I don't know explorer well, but you should be able to do something like "bzr commit" to make a new commit, and then "bzr push" to publish those changes.
[03:37] <blueglasses> that far i have done already
[03:38] <blueglasses> but I'm commiting to a branch called bzrtesting
[03:38] <spiv> I see, you have lp:~lapisdecor/story/testingbzr already.
[03:39] <spiv> Oh, when you commit the changes are automatically going to lp:~lapisdecor/story/testingbzr ?
[03:39] <blueglasses> yes
[03:40] <blueglasses> and I wanted a new branch to put the real code (when it will come done)
[03:40] <spiv> Ok, you have what we call a 'checkout' rather than a 'branch'.  It's really just a local branch configured to automatically update a remote branch at the same time.
[03:40] <blueglasses> I have to push after commit
[03:40] <blueglasses> to get the stuff there
[03:40] <spiv> Oh, then it's not a checkout, just a branch.
[03:41] <spiv> Which is fine.
[03:41] <blueglasses> actually I just dont like the name 'testingbzr'
[03:41] <spiv> Ok, you can rename that.
[03:42] <blueglasses> i would like to keep it to learn bzr but i would like a new branch to put the real code
[03:42] <spiv> If you go to https://code.launchpad.net/~lapisdecor/story/testingbzr/+edit you can change the name.
[03:43] <spiv> Or you can ignore that old branch on Launchpad and tell bzr explorer to push to a new location with the name you want.
[03:43] <blueglasses> that one sounded better
[03:43] <spiv> (To create a new branch on Launchpad you simply push to it.  There's no need to register it or initialise it first.)
[03:43] <blueglasses> cool
[03:44] <blueglasses> so I can call it main
[03:45] <blueglasses> ok I will try to make some code and then push it to a new branch
[03:46] <blueglasses> thank you so much for the help, still a noob here, but with good heart :-)
[03:46] <blueglasses> time to bed now
[03:46] <spiv> blueglasses: good night
[03:47] <blueglasses> good night
[05:50] <poolie> hi all
[07:09] <GaryvdM> Hi all
[07:14] <vila> hi all !
[07:15] <vila> hi GaryvdM , poolie
[07:15] <vila> poolie: feeling better ? Still here ?
[07:15]  * GaryvdM _o/ @ vila
[07:15] <vila> :)
[07:15] <vila> GaryvdM: I wonder whether you're creative in online glyphs or starting coding in perl :)
[07:16] <GaryvdM> Huh?
[07:17] <vila> _o/ @ sounds like noise, aka perl code from the pov of people unaware about perl conciseness ;)
[07:17] <poolie> hi vila, i am better now
[07:17] <GaryvdM> vila: ah :-)
[07:18] <poolie> it does look like perl, or haskell
[07:18] <vila> cool
[07:18] <GaryvdM> Hi vila
[07:18] <GaryvdM> Hi poolie
[07:21] <poolie> hi gary
[08:56] <spiv> mgz: yep, landing something on trunk sorted out the merge proposals that lp hadn't yet noticed were merged.
[09:13] <jelmer> hey GaryvdM, poolie, vila, spiv
[09:13] <vila> jelmer: hi !
[09:14] <vila> spiv: wanna talk about https://code.edge.launchpad.net/~spiv/bzr/checkout-tags-propagation-603395-2.2/+merge/40406 ? Or should we do that earlier tomorrow ?
[09:15] <vila> jelmer: any feedback about the above ?
[09:19] <jelmer> vila: you mean the checkout tags propagation?
[09:20] <jelmer> Ah, I guess so.
[09:20] <vila> jelmer: yup, the impact of bzr-svn or other foreign plugins in particular, the mp is targeted at lp:bzr/2.2
[09:20]  * jelmer has a quick look
[09:20] <vila> s/impact of/impact on/
[09:23] <jelmer> vila: The way backwards compatibility is handled looks reasonable to me; I can do some testing later today if that would be useful.
[09:23] <vila> jelmer: yes it would and would be appreciated ;)
[10:54] <mandel> Hello, quick question, what does bzr do with illegal chars in filenames on windows, example, on linux I use 'stupid: name' what would happen on windows?
[11:02] <rjek> Excitement!
[13:14] <beuno> hello hello
[13:14] <beuno> any bzr devs around?
[13:14]  * beuno stares at vila 
[13:19] <vila> hooo  beuno !
[13:19] <vila> forgive me I was having a small lunch, just back :)
[13:20] <beuno> hai vila!
[13:20] <beuno> how's it going?
[13:20] <vila> better :)
[13:20] <beuno> I have this horrible bzr traceback: https://pastebin.canonical.com/39793/
[13:20] <beuno> but other than that, good
[13:20] <beuno> better than who?  :)
[13:21] <vila> that, my friend, is very bad (the traceback)
[13:21] <vila> better than me yesterday :)
[13:21] <vila> I was already good yesterday :)
[13:22] <beuno> you been sick?
[13:22] <vila> beuno: what bzr version are you using (packaged ? from sources ?)
[13:22] <vila> beuno: no no, just getting better every day :)
[13:22] <beuno> vila, stock maverick
[13:22] <beuno> no funny business
[13:22] <vila> ok
[13:22] <vila> hmm
[13:23] <vila> bzr info -v
[13:23] <vila> trying to find progressive checks
[13:23] <vila> bzr check (this one could take time)
[13:23] <vila> branching from the revision just before the commit
[13:24] <GaryvdM> Hi beuno - How come not a public traceback pastebin?
[13:24] <lifeless> beuno: fs fail?
[13:24] <lifeless> bzr: ERROR: zlib.error: Error -3 while decompressing data: invalid distance too far back
[13:24] <beuno> lifeless, no visible fs failures that I know of
[13:24] <GaryvdM> Thanks lifeless
[13:24] <beuno> hi GaryvdM, it's a private branch, so was lazy and pasted it in private instead of making sure I wasn't leaking anything  :)
[13:24] <beuno> sorry about that
[13:25] <GaryvdM> beuno: np
[13:25] <vila> beuno: number and size of pack files
[13:25] <beuno> vila, http://paste.ubuntu.com/532994/
[13:26] <vila> beuno: I should have started with: this is gzip telling us that the data is corrupted which is unseen so far except when related to fs failue
[13:26] <vila> failure
[13:26] <beuno> vila, http://paste.ubuntu.com/532995/
[13:26] <beuno> ah
[13:27] <beuno> I have plenty of space
[13:27] <vila> beuno: then start with a backup
[13:28] <beuno> 467 Nov 16 09:25:17 beuno-laptop kernel: [1497398.983861] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,commit=600
[13:28] <vila> beuno: at least the repo (which should be enough)
[13:28] <beuno> 468 Nov 16 09:25:31 beuno-laptop kernel: [1497412.578739] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,commit=0
[13:28] <beuno> that's the only thing I see
[13:28] <lifeless> beuno: it might not be this boot
[13:29] <lifeless> beuno: there are a few options :
[13:29] <lifeless>  - corrupt disk
[13:29] <lifeless>  - memory bit error
[13:29] <lifeless> beuno: md5sum your packs
[13:29] <lifeless> and check the sums match the pack names
[13:29] <vila> we really should have that in core
[13:29]  * beuno checks
[13:32] <beuno> lifeless, they all match
[13:32] <lifeless> oh, my bad
[13:32] <lifeless> its in an index.
[13:32] <beuno> http://paste.ubuntu.com/532998/
[13:32] <lifeless> one of your indices is naffed
[13:33] <beuno> so, these *.six/tix/rix?
[13:41] <lifeless> voidspace: yes
[13:41] <lifeless> bah
[13:41] <lifeless> beuno: yes
[13:47] <vila> lifeless: so 'bzr pack' time ? Or do we use the indices for that ?
[13:58] <beuno> vila, lifeless, so, do I have a way out of this?
[13:59] <vila> beuno: if you did a backup, try 'bzr pack;
[13:59] <vila> beuno: if you did a backup, try 'bzr pack'
[13:59] <beuno> I'll backup now
[14:04] <beuno> vila, packing!
[14:06] <beuno> vila, same tb
[14:07] <vila> wow
[14:07] <beuno> vila, http://paste.ubuntu.com/533014/
[14:08] <vila> ah, during the pack
[14:08] <lifeless> to be expected
[14:08] <lifeless> pack has to read data :)
[14:08] <lifeless> bzr dump-btree can help you find the damaged index
[14:09] <vila> yeah, I expected he could rebould the indices from the packs :-/
[14:09] <vila> s/expected/hoped/
[14:09] <vila> which is what we need
[14:10] <lifeless> no
[14:13] <vila> oh good
[14:13] <beuno> so, run bzr dump-btree?
[14:19] <vila> beuno: yes, starting with the .cix indices as they seem to be the ones causing problem (from the tb)
[14:20] <vila> lifeless: you still haven't elaborate on this 'no'
[14:20] <lifeless> vila: the indices have unique data
[14:21] <vila> urgh, still ?
[14:21] <lifeless> vila: until we fix it
[14:22] <beuno> vila, so run that command against each .cix?
[14:22] <vila> yes
[14:23] <vila> beuno: quick check: you don't have *empty* indices right ?
[14:24] <beuno> vila, let me look
[14:24] <vila> lifeless: but then there is probably no escape for beuno other than recreating its repo from scratch (or almost) ?
[14:24] <lifeless> indeed
[14:24] <beuno> vila, all of them ahve more than zero bytes
[14:24] <beuno> ah
[14:24] <beuno> ok
[14:24] <beuno> that sounds fun
[14:24] <vila> :-/
[14:24] <beuno> I guess I can re-branch from launchpad
[14:25] <lifeless> restore from backup :)
[14:25] <beuno> do you want this bug reported?
[14:25] <beuno> it's a few hundred mb, so not terrible
[14:25] <lifeless> you've had a fs glitch, for sure.
[14:25] <lifeless> its not a sync-crash, or you'd have an empty index.
[14:25] <beuno> okk
[14:25] <lifeless> you've either got a bad memory dimm - in which case rebooting may fix this.
[14:25] <vila> beuno: let see if we can isolate which index is the culprit
[14:25] <beuno> so maybe I need to run fsck
[14:25] <beuno> vila, sure
[14:26] <lifeless> or you've got a bad block which lost data
[14:26]  * beuno nods
[14:26] <beuno> I can try rebooting
[14:26] <beuno> I haven't done that in a few weeks
[14:26] <lifeless> note that if reboot does not fix it, it doesn't mean that the block is bad - a bad dimm that results in a bad write is indistinguishable (except via disk read stats)
[14:27] <beuno> ok, I'll let you know in 2 minutes
[14:30] <beuno> re-packing...
[14:30] <beuno> 3/7
[14:31] <vila> beuno: you've connected from another pc ?
[14:32] <vila> s/'ve/'re/
[14:32] <maxb> IRC proxies ftw :-)
[14:33] <beuno> vila, no, irss + ssd disk
[14:33] <beuno> reboot in 12 seconds
[14:33] <beuno> 4/7
[14:33] <beuno> I think ti's fixed
[14:33] <beuno> because it's way further than before
[14:33] <vila> let's wait
[14:40] <beuno> 6/7
[14:41] <beuno> vila, lifeless, reboot made pack work
[14:42] <beuno> so thank you  :)
[14:42] <vila> beuno: retry commit now
[14:42] <lifeless> beuno: replace your memory.
[14:42] <beuno> vila, commit worked
[14:42] <vila> beuno: I won't feel secure *at all* if I were you :-/
[14:43] <beuno> lifeless, remote hardware diagnosing, this is a new one for me!
[14:43] <beuno> vila, I should be able to replace the ram fairly quickly
[14:43] <beuno> 99% of what I care about is on the interwebs
[14:43] <beuno> so i'll backup the remaining 1% and turn on paranoid mode
[14:43] <vila> ha, I feel better then :)
[14:43] <beuno> thank you much!
[14:49] <jam1> morning all
[14:49] <GaryvdM> Hi jam!
[14:49] <jam> hi GaryvdM
[15:43] <txdv> is there to way to merge 2 commits seperated by other commits?
[15:43] <txdv> i got c1,c2,c3,c4/head, where cX stands for commit with number X and head for the tip or whatever you bzr guys calls
[15:43] <txdv> call*
[15:43] <txdv> i want to somehow put the changes from  c4 into c1
[15:45] <Odd_Bloke> txdv: It doesn't make sense to talk about putting changes from one commit "into" another commit.  What would you expect it to look like?
[15:46] <txdv> well i got a fucking commit nazi in my work force
[15:46] <txdv> and whenever there is an additional empty line added by accident
[15:46] <txdv> he forces me to rewrite the complete history
[15:47] <txdv> So let's just pick a scenario like, i need to remove a simple line in a past commit
[15:47] <txdv> adding just another commit fixing exactly that issue won't help
[15:51] <Odd_Bloke> txdv: Sounds like you want rebase...
[15:52] <dash> or a tire iron
[15:52] <txdv> Odd_Bloke: this scenario doesn't include diverged trees at all
[15:53] <txdv> Or can you explain how to incorporate the changes from c4 into c1 with rebase?
[15:54] <vila> txdv: wow, I feel your pain (I do a a lot of typos and my histories are nothing close to linear)
[15:54] <vila> txdv: so roughly you wan to cherry-pick and may be with luck use a bit of rebase
[15:54] <vila> txdv: so you start with a "clean" branch
[15:55] <vila> txdv: then you cherry-pick 'bzr merge ../dirty -c<1>' 'bzr merge -c<4>'
[15:56] <vila> txdv: -c<4> is a shortcut for -r3..4
[15:56] <vila> txdv: and rebase should do for 2 and 3
[15:57] <vila> txdv: 'bzr revert --forget-merges' if for whatever reason you need to commit changes without tracking where they come from
[15:58] <txdv> awesome
[16:00] <vila> txdv: ... or may be you just do a single big commit with the --forget-merges trick above, after all if "he" doesn't care about history "he" may even prefer that :-/
[16:01] <txdv> that motherfucker is uncommiting shit from trunk all the time because of the history
[16:01] <txdv> even his own commits
[16:01] <vila> right, but let's just try to watch our language here :-D You're welcome to express your pain otherwise ;)
[16:02] <vila> txdv: may be 'bzr merge --interactive' can help you too ?
[16:04] <txdv> ill look into it
[16:04] <txdv> the checkout the cherry picking first
[16:07] <txdv> thanks again
[16:11] <vila> anytime ;)
[16:12] <txdv> this dude is ridicolous
[16:12] <txdv> he forces me to rewrite the history on my branch
[16:12] <txdv> yet he puses right away to the trunk and uncommits it after a while
[16:16] <vila> the uncommit is very damaging if the branch is shared :-/
[16:17] <GaryvdM> txdv: You can turn on append-revisions-only so that he can't uncommit.
[16:18] <txdv> O i already spent 2 hours of debugging stuff because i thought my merge messed up, while he uncomited his bad commit meanwhile
[16:18] <vila> txdv: may be you should start using qlog and its ability to hide lower level commits (have a look at the bzr history)
[16:18] <txdv> GaryvdM: on launchpad too?
[16:19] <GaryvdM> txdv: Yes - easy with the new bzr config command, with out, you need to modify the branch config with sftp
[16:20] <vila> GaryvdM: wow, I didn't thought about using 'bzr config' for that ! Did you try it ? (/me frantically notes to add tests for remote branches)
[16:21] <GaryvdM> vila: no - I just assumed. Will test now.
[16:21] <vila> GaryvdM: I'm just silly, I made sure you can *read* remote configs and then totally forget you can update them too :)
[16:21] <txdv> where can i get this qlog?
[16:21] <vila> txdv: it's part of the qbzr plugin
[16:21] <GaryvdM> txdv: it's part of the qbzr plugin. What os are you using?
[16:21] <vila> txdv: what OS/distro version are you...
[16:21] <vila> damn GaryvdM
[16:22] <vila> :)
[16:22] <txdv> y i already got it installed
[16:22] <txdv> debian i am using: apt-get install qbzr
[16:28] <vila> txdv: less than one minute between 'where can i get' and 'got it installed'...
[16:31] <txdv> i did a 'aptitude search qlog' after you mentioned qlog
[16:31] <txdv> couldn't find it, therefore i thought it was not in the deb repos
[16:32] <vila> still, I'm always amazed by how easy it can be to get the right tools...
[16:32] <txdv> not with windows
[16:32] <txdv> windows is a timewaste
[16:33] <txdv> 2hours in order to install visual studio on a brand new machine
[16:33] <vila> right, you need a good packaging community, that was my point ;)
[16:33] <txdv> actually im not too happy with the unix way of directory structure
[16:33] <txdv> the only thing that you should do in order to install a programm is to unzip it in a directory
[16:33] <txdv> or untar
[16:34] <vila> but they tried that with SunOS and you end up with nightmearish PATH MANPATH LD_LIBRARY_PATH and so on
[16:34] <vila> and that doesn't even start addressing compatibility and dependencies...
[16:35] <dash> OSX did it
[16:35] <dash> sort of kind of.
[16:35] <vila> right, but user-facing apps only
[16:35] <txdv> the problem with linux is the compatibility
[16:35] <vila> yeah, agree, sort of kind of, the .app is very nice, don't get me wrong though
[16:35] <txdv> everything changesi n the system
[16:35] <dash> vila: can't say i'm a fan, really
[16:36] <GaryvdM> Yhea - That's one of the things that bugs me with windows, is adding to PATH, and adding to PATH, and adding to PATH....
[16:36] <txdv> they should automatically check programm\*\bin
[16:36] <txdv> why path?
[16:36] <vila> dash: it's pretty cool to be able to test an app and throw it away without worrying about hidden dependencies though (I know, I know there are exceptions)
[16:37] <txdv> vila: CDE enables one to build and run standalone apps with all dependencies
[16:37] <vila> CDE, you mean the CDE in Solaris or something else ?
[16:38] <vila> but anyway, the problem starts when you want to share libraries
[16:38] <vila> or any other kind of resources
[16:38] <txdv> http://goo.gl/h6IP3
[16:40] <Odd_Bloke> Sounds like a guaranteed way to mean you don't have to write portable code, and a huge resource waste.
[16:40] <Odd_Bloke> N.B. Not portable code is probably bad code.
[16:41] <txdv> if you just want to get shit running on an old machine it is good enough
[16:41] <vila> hehe, right, but I like my machines to be lean and clean ;)
[16:41] <Odd_Bloke> So's Debian. :p
[16:44] <vila> note the 'S' here, I think I'm currently maintaining ~5 physical and ~15 virtual machines and I don't want to *debug* them :)
[16:50] <fullermd> Of course not.  When you need to, you just bug me   :p
[16:50] <vila> hehe, I wish I can do that for all of them ;)
[16:51] <fullermd> Oh, you totally can.  "I found the problem with this one, it's running a weird OS..."
[16:51] <vila> lol, yeah *that* will apply to *all* of them :)
[16:52]  * fullermd wonders if you have the test suite running on Plan 9...
[16:52]  * vila searches for a Plan9.iso
[16:53] <vila> there is one ! :D
[16:53] <fullermd> I wonder if anybody's ever tried using bzr on it.
[16:53] <vila> is there a python there to start with ?
[16:54] <fullermd> No idea.
[16:54] <fullermd> I'd assume it's popular enough (and near enough to POSIX in various ways) that perl and python both exist on it.
[16:55] <fullermd> But I've been wrong before.  Occasionally.  And after I killed all the witnesses, it never REALLY happened...
[18:13] <SimonK> ?
[18:16] <jelmer> hi SimonK
[18:17] <GaryvdM> Hi SimonK
[18:18] <jelmer> hey Gary
[18:21] <GaryvdM> Hi jelmer
[18:21] <GaryvdM> ubot: tell me about bug #647204
[18:23] <GaryvdM> SimonK: Ok - I don'
[18:23] <LeoNerd> bzr: ERROR: Unsupported protocol for url "git://perl5.git.perl.org/perl.git    <==  Did I do something wrong, or is it not supported?
[18:24] <GaryvdM> SimonK: Ok - I don't like it when the bug just goes away, so I'll try reproduce it in older revisions.
[18:24] <GaryvdM> SimonK: Thanks for testing.
[18:25] <maxb> LeoNerd: no, that works
[18:26] <maxb> LeoNerd: oh, and we're thinking thursday in the office here
[18:26] <LeoNerd> Righty.. I'm busy this end Thursday I think.. :/ but never mind...
[18:26] <LeoNerd> maxb: Well, it doesn't work for me.. ;)
[18:26] <maxb> I assume you just don't have bzr-git and/or dulwich installed
[18:26] <LeoNerd> Oh. Duh! I was sure I had installed it :p
[18:26] <LeoNerd> EWRONGMACHINE
[18:27] <maxb> Hmm, what's Wednesday like for you, we are vacillating as usual
[18:27]  * LeoNerd admits user error, returns to lurking in the shadows
[18:27] <LeoNerd> Oh... OK... now dulwich won't install... massive "SyntaxError" complaints
[18:27] <maxb> !
[18:27] <maxb> pastebin?
[18:27] <LeoNerd> http://paste.leonerd.org.uk/?show=1135
[18:28] <maxb> erm, eek
[18:28]  * maxb reads in detail
[18:28] <jelmer> we don't support python 2.3
[18:28] <LeoNerd> OK... So... Why's it trying to run it?
[18:28] <jelmer> I guess we don't have that declared in debian/control
[18:28] <LeoNerd> Anything I can do to fix it?
[18:28] <maxb> Why on earth do you even have python 2.1, 2.2, 2.3 installed on a squeeze machine? :-)
[18:28] <LeoNerd> No idea
[18:29] <LeoNerd> Probably never removed them
[18:29] <jelmer> uninstall python2.3 ?
[18:29] <LeoNerd> OK..
[18:29] <jelmer> I'll fix the package to add >= 2.4
[18:30] <LeoNerd> Riiiighty... Having done that, it's now running nicely smooth.. thanks.
[18:31] <maxb> LeoNerd: :-) ... and Wednesday?
[18:31] <LeoNerd> Probably busy then also...
[18:31] <maxb> k
[18:31] <LeoNerd> Don't worry this week
[18:32] <LeoNerd> Hah... ENOSPC
[18:32] <LeoNerd> guess I'd better grow my home then.. :/
[18:35] <SimonK> GaryvdM: I've got a pending update for BzrExplorer that populates %%selected in tool definitions with what is selected in the working tree browser.  How do you completely cancel a selection in the qbzr working tree browser?
[18:36] <GaryvdM> Um..
[18:41] <GaryvdM> I'm sure it's fine to just do treewidget.selectionModel().clear() -http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qitemselectionmodel.html#clear
[18:41] <SimonK> GaryvdM: Ah but how does the user do it?
[18:42] <GaryvdM> Oh
[18:42]  * GaryvdM goes to look at the mp
[18:45] <GaryvdM> SimonK: If you have 1 item selected, and you ctrl+click on it, then you have no selection.
[18:47] <GaryvdM> SimonK: then you need to use the context menu key on your keyboard, cause when you right click, you get a selected item.
[18:50] <SimonK> GaryvdM: Thanks
[18:52] <SimonK> GaryvdM: While on the subject, should I update it to support %selected in 'shell' tools?
[18:54] <GaryvdM> SimonK: I'm not sure what that is. I've never used the tools utility in bzr-exporer. If it would be usefull to you, then yes I guess.
[18:55] <SimonK> GaryvdM: It's not particularly useful - I just thought it would be more consistent
[20:22] <mtaylor> you know what would be great? if there were a url shortcut which expanded to my username...
[20:22] <mtaylor> so that instead of doing bzr push lp:~my-long-ass-username/drizzle/branchname, I could do: bzr push lp:~/drizzle/branchname or something
[20:27] <GaryvdM> mtaylor: I think jam recently fixed that for lp.
[20:27] <GaryvdM> mtaylor: It previously work for other urls, e.g. sftp://server/~/mybranch
[20:32] <mtaylor> GaryvdM: wow. I llove it when I request something and it just happens :)
[20:34] <poolie> hello
[20:39] <GaryvdM> Hi poolie
[20:40] <GaryvdM> mtaylor: I just checked, it was added in 2.3b1
[20:40] <mtaylor> GaryvdM: excellent. I'm excited to use that when 2.3 lands!
[20:43] <poolie> hi monty
[20:48] <poolie> jam, hi?
[20:49] <poolie> mtaylor: i think you only need 2.3b1 (or now b2?) on the client to use it
[20:49] <poolie> so you're waiting for that in... maverick-updates?
[20:50] <maxb> No, maverick is in 2.2.x
[20:51] <maxb> s/in/on/
[20:54] <poolie> oh of course
[20:54] <poolie> so you'd need to use the ppa, or wait for natty
[20:54] <poolie> it's early :)
[20:59] <poolie> GaryvdM: i think it's quite likely that fixing 483388 would fix 588698
[20:59] <poolie> which i guess is the real test for whether they are a dupe
[21:04] <poolie> and of course it has a good simple reproduction case
[21:07] <poolie> hullo?
[21:08] <fullermd> Shhh.  I'm hunting wabbits.
[21:08] <SimonK> exit
[21:09] <GaryvdM> poolie: I agree (sorry - did not think it was a question.)
[21:09] <txdv> i am the ruler of the worlds
[21:09] <poolie> anyhow, if you want to talk about it more, i'll be around, otherwise just go for it
[21:09] <GaryvdM> Ok
[21:13] <jam> hi poolie
[21:16] <poolie> hi there, shall we have a talk?
[21:16] <jam> poolie: sure
[21:17] <poolie> skype or pots?
[21:18] <jam> poolie: skype is easy
[21:44] <homeasvs> Hi.  I have a local branch that I want to now merge onto an lp branch.  BOth are the same up to revision 23
[21:44] <homeasvs> however, the public branch has a revision 24, while the local branch has 24-30
[21:45] <homeasvs> I am trying to merge all of 24-30 onto 23, but keep the separate commits
[21:45] <homeasvs> I started by doing merge -r 24 my/local/branch
[21:45] <homeasvs> that applies revision 24 of the local branch
[21:45] <homeasvs> when I do commit, it says that I have a pending merge, the same as the one I just tried to merge
[21:46] <dash> homeasvs: you shouldn't have to specify the revision at all
[21:46] <homeasvs> is that normal? How can I commit exactly revision 24 of the local branch onto my public checkout, keeping the commit message?
[21:46] <homeasvs> dash, if I don't specify anything, it just merges all changes at once it seems
[21:46] <homeasvs> dash, 'squashing' the 6 commits into one as it were
[21:46] <homeasvs> unless I'm missing something?
[21:46] <dash> homeasvs: it doesn't squash them, it nests them. :)
[21:46] <homeasvs> how can I convince myself it nests them ?
[21:47] <homeasvs> and how can I mark the one commit that had a conflict as 'this one goes separate, but let all others pass through as separate commits' ?
[21:47] <dash> homeasvs: so 'bzr log' shows the merge commit as a single commit - but 'bzr log -n0' shows the nested subcommits
[21:47] <homeasvs> dash, my local branch is a mistake and I don't want a record of it later
[21:47] <homeasvs> ie i'd prefer to cherrypick all but one revision and commit them as unnested.  is that possible?
[21:48] <dash> anything's possible, i'm sure
[21:48] <homeasvs> heh
[22:01] <maxb> homeasvs: OK, so it sounds like bzr merge -c is what you want
[22:02] <maxb> So, you'd freshly branch the public branch to a new local work area, then you would 'bzr merge -c 24 ../mistake-branch', 'bzr commit'
[22:02] <maxb> and then you would repeat for each revision of mistake you actually wanted to keep
[22:07] <homeasvs> maxb, yeah, tried that, but it still records the fact that it's a merge from some other branch
[22:07] <homeasvs> I bruteforced it by creating 6 diffs, one for each rev, and applying them manually
[22:07] <maxb> oh, I see
[22:08] <maxb> bzr merge -c will only record the merge if you are actually merging the 'next' revision, without skipping any
[22:08] <dash> homeasvs: i believe the 'rewrite' plugin is for these situations
[22:08] <maxb> if you really really do want to throw away that info, 'bzr revert --forget-merges' before committing
[22:09] <maxb> rewrite could have partially applied here, but I don't believe it allows you to drop a revision
[22:16] <mgz> that's not the right answer to the question posed by homeasvs
[22:17] <seiflotfy> is poolie around
[22:17] <poolie> seiflotfy: hi, i am, but i'm on the phone right now
[22:17] <mgz> the right answer is "it's okay branches have different revision 24s, and it's okay that when you merge your revisions 24-30 become part of a new revision 25"
[22:18] <mgz> the log doesn't need to be a line with dvcs, it can have branchy bits.
[22:18] <mgz> going straight to bzr-rewrite with that kind on query is leading people down the wrong path.
[22:18] <homeasvs> mgz, in this particular case I specifically do not want this to show up as a merge from a branch
[22:18] <maxb> That's true, but homeasvs also mentioned omitting one of the revisions from the existing branch
[22:18] <homeasvs> mgz, so I do think that a rewrite would have been the right case here
[22:19] <maxb> homeasvs: Of course, another very relevant question is: Why do you care about it not showing as a merge?
[22:19] <mgz> you need to justify why you need that to be the case
[22:19] <homeasvs> because the branch was wrong ? it was a cleanup of some work I did a long time ago and part of that work I already did publically apparently
[22:20] <homeasvs> not sure why I need to 'justify'  though :)
[22:20] <mgz> if you want to revert a wrong revision that's publicly available, you merge -rN..N-1
[22:20] <mgz> s/justify/explain/ if you like.
[22:21] <mgz> if it's a revision you've not shared yet, uncommit.
[22:22] <homeasvs> uncommit seems to completely lose the work that was in the commit though
[22:24] <GaryvdM> homeasvs: uncommit dose not revert. It goes back to were you were before the commit.
[22:26] <mgz> generally just reverting bad revisons in a seperate commit with a "I screwed up" commit message is what you want when there's enough history to be worth preserving
[22:26] <mgz> either you care about the history, of which your screwup was a possibly-significant-later part, or you don't and may as well just commit the diff as one revision
[22:42] <mgz> am interested what you actually ended up doing homeasvs
[22:43] <homeasvs> mgz, like I said above, just generate a patch for each revision, then apply the ones I wanted by hand
[22:44] <GaryvdM> poolie: ah - ok - after further investigating I see that 588698 and the initial example given in 483388 are in fact different.
[22:47] <poolie> k
[22:49] <mgz> homeasvs: can use uncommit and shelve to do similar thing with marginally less labour for future note.
[22:49] <homeasvs> mgz, will keep that in mind, thanks for the tip
[23:33] <poolie> mgz, hello
[23:33] <poolie> spiv, good morning?
[23:34] <StuartPB> How do I make a new version of a branch where one file doesn't exist in the history?
[23:34] <poolie> StuartPB: you want to pretend it never happened?
[23:35] <poolie> i think bzr-rewrite can do that
[23:39] <StuartPB> how do I use it
[23:39] <StuartPB> is it in the default bzr windows install
[23:40] <spiv> poolie: good morning
[23:51] <mgz> 33 failures... 5 failures...