[19:14] <Noldorin> hey folks
[19:14] <Noldorin> jelmer
[21:27] <alansaul> Hey guys, I've got a problem, I pushed a branch onto my main trunk repo, overwriting the entire revision history of the trunk
[21:27] <alansaul> How can I get this back? My trunk is now has the same revision history as my branch! Bzr push doesnt seem to be incremental!
[21:31] <alansaul> Anyone any ideas?
[21:37] <alansaul> :( I don't want to develop anymore incase I can get it back somehow!
[21:37] <alansaul> seems really flakey if there is no way to get it back!
[21:42] <beuno> alansaul, hi
[21:42] <beuno> you did push --overwrite?
[21:42] <alansaul> beuno: Hey :)
[21:43] <alansaul> Ermm, no, unless that is the default
[21:43] <beuno> it isn't
[21:43] <alansaul> I had a branch say x
[21:43] <alansaul> of trunk
[21:43] <alansaul> made lots of changes
[21:43] <beuno> so you went from revision 120 to revision 2
[21:43] <beuno> something like that, yes?
[21:43] <alansaul> merged trunk into x to make sure there was no conflicts
[21:43] <alansaul> and then did bzr push x serverrepo/trunk
[21:43] <alansaul> beuno: yeah
[21:43] <beuno> right
[21:43] <beuno> so here's what happenes
[21:44] <beuno> *happened
[21:44] <beuno> trunk was at revno 120 (lets pretend that's the revno)
[21:44] <alansaul> yep
[21:44] <beuno> your local branch was at revno 10
[21:44] <alansaul> yep
[21:44] <beuno> you merged in trunk, so you got revision 11
[21:44] <beuno> and pushed that
[21:44] <alansaul> yep
[21:44] <beuno> which made trunk 11
[21:44] <alansaul> yep
[21:44] <beuno> in order to prevent that in the future
[21:44] <beuno> what you do is have a mirror of trunk locally
[21:45] <beuno> and merge your branch into trunk
[21:45] <beuno> and not the other way around
[21:45] <beuno> and then push that
[21:45] <alansaul> beuno: Yeah i realise that now :)
[21:45] <beuno> there's also a config value that will prevent revisions to be removed
[21:45] <beuno> so
[21:45] <alansaul> or merge trunk into x, then x into trunk
[21:45] <alansaul> then push
[21:45] <beuno> if you do a "bzr uncommit" on trunk, I think that'll bring it back to the previous state
[21:45] <alansaul> oooo
[21:46] <alansaul> hmmm its asking if I want to remove the revision 11
[21:46] <beuno> yes
[21:47] <alansaul> hmmm, my local trunk isnt up to date with my server trunk
[21:47] <alansaul> should i update first yeah?
[21:47] <beuno> sure, get them both in the same state
[21:47] <alansaul> (just don't wanna mess this up to some sort of irreversable state!)
[21:47] <beuno> right
[21:47] <beuno> I'd back up everything
[21:47] <beuno> just in case  :)
[21:47] <alansaul> hmmm
[21:48] <beuno> just copy over the folders
[21:49] <alansaul> okay so make a copy of my local trunk and branches just somewhere else locally?
[21:49] <beuno> yes
[21:50] <alansaul> okie
[21:50] <alansaul> okay whilst its copying, ill ask a few questions :P
[21:50] <alansaul> so uncommit will remove commit 11? and will go back to 120?
[21:50] <fullermd> I'm not sure uncommit is really what you want...
[21:50] <alansaul> Oop... holding
[21:51] <beuno> fullermd, no?  unless he has a previous copy of trunk, un-mangled, not sure how else to get there
[21:51] <fullermd> You can just make one.
[21:51] <fullermd> uncommit would just back you up to the rev before you merged trunk.
[21:52] <fullermd> Poke at log to find the previous head rev, make a new branch from that, push (--overwrite) over trunk, then go back to the question of merging in the local branch.
[21:52] <alansaul> I want to bring the trunk back to how it was before it was pushed ontop of
[21:53] <fullermd> (previous _trunk_ head rev that is)
[21:53] <alansaul> fullermd: Hmm think you lost me there
[21:53] <fullermd> (sorry, I'm in the middle of some stuff ATM...   don't have time for details for a bit  :|  )
[21:54] <alansaul> Aww
[21:54] <alansaul> my bzr log has branch nick: trunk up to 18 then branch-x from 18 to 24
[21:54] <alansaul> But my trunk was on commit 48 or something before i pushed ontop of it
[21:55] <fullermd> Important thing is: Don't Panic.  As long as push didn't require --overwrite, you've never lost anything.  It's just been rearranged.
[21:56] <alansaul> Hmm, well that sounds promising! I just cant find anywhere in any logs which have a revno of 48
[21:57] <fullermd> 'll have time in 15 or 20 minutes or something if nobody else elaborates before then.
[21:58] <alansaul> fullermd: Sweet, I can wait
[21:58] <alansaul> fullermd: Thanks :)
[21:59] <fullermd> If you're bored 'till then, reading http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevNumbering and http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevHandling may help you understand what's happening.
[22:17] <alansaul> Working on it :)
[22:18]  * jelmer waves
[22:18] <thomi|work> Hi - does anyone have any more information on bug #820805 ? I have run into this issue on a workmate's laptop and can't seem to work around it with any of the fixes mentioned in the bug report.
[22:29] <alansaul> fullermd: Okay read them :) Let me know when your back :)
[22:34] <jelmer> thomi|work: mgz has done some research into those bugs
[22:34] <jelmer> thomi|work: he posted a summary to the list a week or so ago
[22:35] <wgz> I've got a patch for pageant to send as well, the pain is I'm struggling to test it
[22:36] <wgz> as much as I dislike unix permissions, windows security things are far more painful.
[22:40] <thomi|work> wgz: I don't suppose you have a replacement .exe I could test for you?
[22:40] <thomi|work> I gotta skip out for lunch, but If there's anything I can do to help I'll give it a go.
[22:45] <wgz> I do, it's 32 bit though.
[22:47] <wgz> thomi|work: http://float.endofinternet.org/temp/pageant_dbg.zip
[22:48] <wgz> it's built with the debug stuff enabled so pops up a console with info
[22:48] <wgz> if you need a 64 bit version I'll look at cross compiling, but can also cc you on the patch (their list doesn't seem to be public)
[22:54] <Noldorin> hi poolie
[22:55] <poolie> hi Noldorin
[22:56] <fullermd> alansaul:  OK, yeah, that was sorta like 15 or 20 minutes...
[22:56] <alansaul> fullermd: Lol thats cool thanks for coming back :)
[22:57] <Noldorin> poolie, saw your response to my bug (suggestion) about download types, etc. happy to talk about it here if you like
[22:57] <alansaul> I have to go reasonably soon though!
[22:57] <fullermd> So, did that reading illuminate anything for you?
[22:57] <alansaul> so I need to find the revid that relates to revno 48 and revert back to that?
[22:57] <alansaul> its still there somewhere
[22:58] <fullermd> Yah.  Or the new revno, even.
[22:58] <fullermd> Look at `bzr log -n0`.  Your latest rev is the one that merged trunk, right?
[22:58] <fullermd> So the old head of trunk would be the first indented rev under that.  It'll have a dotted revno of some sort.
[22:59] <alansaul> naw the last one isnt the merge
[23:00] <alansaul> I have a revno: 16.2.1 [merge] though
[23:00] <alansaul> but its a few revisions behind, im on revision 24
[23:00] <alansaul> If I can get this trunk back to the state before though, I can merge in the changes i made in the branch properly
[23:01] <fullermd> Well, wherever it was.  You merged in trunk, before pushing over it.
[23:01] <fullermd> I'm presuming you haven't done anything on trunk since (nor anybody else); in that case things get messier.
[23:01] <alansaul> I don't think so no
[23:01] <fullermd> So whichever your 'merge in trunk' rev is, the first rev indented under that is the rev that was at the time the head of trunk.
[23:02] <alansaul> my branch x is basically a more up to date version than the trunk, but i just want to merge it into the trunk without losing all the revision history the trunk had
[23:02] <fullermd> Mmm.  Well, let's glance back a moment.  It's not lost, it's just not on the mainline (so log won't show it unless you use -n0).  Does that matter?
[23:02] <alansaul> I think I want to revert back to revno: 16.2.1 [merge]
[23:04] <fullermd> Only thing that gives me pause there is that that revno implies that it was only a single rev merged (e.g., trunk had only grown one new thing).  Is that right?
[23:06] <alansaul> Ummm im not sure what you mean?
[23:06] <alansaul> There is a further indented bit
[23:07] <alansaul> revno: 16.1.29
[23:07] <fullermd> Mmm.  Is this something you can share?
[23:07] <alansaul> My revno: 16.2.1 [merge] has a commit comment of Merged data model with trunk, only one failing test (due to users not being implemented yet)
[23:09] <fullermd> i.e., a public branch I can clone and look at?  Or a log you can substantially pastebin?
[23:44] <jelmer> hmm, I think I got carried away by the awesomeness of HPSS there for a second..
[23:44]  * jelmer goes back to spiv's branch
[23:44] <jelmer> (I'm not sure what made my inexplicably scared of the HPSS subsystem earlier, but it's really nice once you get used to it)
[23:44] <jelmer> s/my/me/
[23:45] <wgz> yeah, going a bit overboard jelmer :)
[23:45] <wgz> one complaint, adding more things that bz2 on the fly is kinda ugh
[23:46] <jelmer> wgz: what would you like to do instead?
[23:46] <wgz> practically, or ideally? :)
[23:47] <wgz> I'd like to see numbers for size/performance vs zlib
[23:47] <jelmer> both :)
[23:47] <wgz> ideally, sendfile.
[23:48] <jelmer> wgz: sendfile doesn't seem ideal bandwidth-wise
[23:50] <jelmer> wgz: you have a point bout zlib vs bz2 though
[23:50] <jelmer> *about
[23:50] <poolie> hi all
[23:51] <poolie> jelmer, i like seeing all those patches
[23:51] <poolie> you should run it under Judge :)
[23:51] <poolie> you might need to patch it to add some more options, like for the number of times
[23:51] <poolie> to run the test
[23:51] <poolie> i really hope to go back to memory consumption soon
[23:51] <poolie> i did some fun lp hacks on the weekend though
[23:51] <wgz> at least for initial branching, I've measured smaller transfer, and smaller resource usage with dumb transports over smart ones, because of the recompression/overhead
[23:52] <wgz> being able to pick out just the latest changes is something where smart and recompress does do better than splatting bytes, but wanting to get a whole repo isn't uncommon either
[23:53] <jelmer> hi poolie
[23:53] <jelmer> poolie: Yeah, I should give that a try, at least for some of the methods where performance is relevant.
[23:54] <jelmer> wgz: at least for the things I've tried adding smart methods had a significant impact. I haven't compared with zlib though
[23:54] <spiv> jelmer: :)
[23:56] <poolie> hi spiv
[23:56] <jelmer> poolie: btw, thanks for being so persistent in trying to separate launchpad-buildd from its big siamese twin :)
[23:56] <jelmer> hey spiv
[23:56] <poolie> it's kinda funny
[23:56] <poolie> just when you think it's deleted it rises back up like a zombie
[23:57] <poolie> do you guys really like the subunit test output?
[23:57] <poolie> i'm not finding it very easy to deal with
[23:57] <wgz> it makes a massive difference for anything doing operations on a remote repo
[23:57] <jelmer> poolie: :)
[23:57] <poolie> eg subunit crashed filtering this failure
[23:58] <jelmer> poolie: I think the old subunit stuff was kinda nice to read. The new bits (with mime encoding) are harder to read, but alright after applying a filter. Also, testrepository ftw :)
[23:58] <wgz> but for mirroring the data it can be suprisingly poor
[23:59] <wgz> poolie: not much. are we talking pqm or in general?
[23:59] <wgz> it has definite robustness issues.