=== mnepton is now known as mneptok === _nyuszika7h_ is now known as nyuszika7h === LeoNerd is now known as LeoNerdF === Noldorin__ is now known as Noldorin [19:14] hey folks [19:14] jelmer [21:27] 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] 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] Anyone any ideas? [21:37] :( I don't want to develop anymore incase I can get it back somehow! [21:37] seems really flakey if there is no way to get it back! [21:42] alansaul, hi [21:42] you did push --overwrite? [21:42] beuno: Hey :) [21:43] Ermm, no, unless that is the default [21:43] it isn't [21:43] I had a branch say x [21:43] of trunk [21:43] made lots of changes [21:43] so you went from revision 120 to revision 2 [21:43] something like that, yes? [21:43] merged trunk into x to make sure there was no conflicts [21:43] and then did bzr push x serverrepo/trunk [21:43] beuno: yeah [21:43] right [21:43] so here's what happenes [21:44] *happened [21:44] trunk was at revno 120 (lets pretend that's the revno) [21:44] yep [21:44] your local branch was at revno 10 [21:44] yep [21:44] you merged in trunk, so you got revision 11 [21:44] and pushed that [21:44] yep [21:44] which made trunk 11 [21:44] yep [21:44] in order to prevent that in the future [21:44] what you do is have a mirror of trunk locally [21:45] and merge your branch into trunk [21:45] and not the other way around [21:45] and then push that [21:45] beuno: Yeah i realise that now :) [21:45] there's also a config value that will prevent revisions to be removed [21:45] so [21:45] or merge trunk into x, then x into trunk [21:45] then push [21:45] if you do a "bzr uncommit" on trunk, I think that'll bring it back to the previous state [21:45] oooo [21:46] hmmm its asking if I want to remove the revision 11 [21:46] yes [21:47] hmmm, my local trunk isnt up to date with my server trunk [21:47] should i update first yeah? [21:47] sure, get them both in the same state [21:47] (just don't wanna mess this up to some sort of irreversable state!) [21:47] right [21:47] I'd back up everything [21:47] just in case :) [21:47] hmmm [21:48] just copy over the folders [21:49] okay so make a copy of my local trunk and branches just somewhere else locally? [21:49] yes [21:50] okie [21:50] okay whilst its copying, ill ask a few questions :P [21:50] so uncommit will remove commit 11? and will go back to 120? [21:50] I'm not sure uncommit is really what you want... [21:50] Oop... holding [21:51] fullermd, no? unless he has a previous copy of trunk, un-mangled, not sure how else to get there [21:51] You can just make one. [21:51] uncommit would just back you up to the rev before you merged trunk. [21:52] 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] I want to bring the trunk back to how it was before it was pushed ontop of [21:53] (previous _trunk_ head rev that is) [21:53] fullermd: Hmm think you lost me there [21:53] (sorry, I'm in the middle of some stuff ATM... don't have time for details for a bit :| ) [21:54] Aww [21:54] my bzr log has branch nick: trunk up to 18 then branch-x from 18 to 24 [21:54] But my trunk was on commit 48 or something before i pushed ontop of it [21:55] 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] Hmm, well that sounds promising! I just cant find anywhere in any logs which have a revno of 48 [21:57] 'll have time in 15 or 20 minutes or something if nobody else elaborates before then. [21:58] fullermd: Sweet, I can wait [21:58] fullermd: Thanks :) [21:59] 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] Working on it :) [22:18] * jelmer waves [22:18] 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:18] Launchpad bug 820805 in Bazaar "access denied on Pageant .pag file" [Undecided,Confirmed] https://launchpad.net/bugs/820805 [22:29] fullermd: Okay read them :) Let me know when your back :) [22:34] thomi|work: mgz has done some research into those bugs [22:34] thomi|work: he posted a summary to the list a week or so ago [22:35] I've got a patch for pageant to send as well, the pain is I'm struggling to test it [22:36] as much as I dislike unix permissions, windows security things are far more painful. [22:40] wgz: I don't suppose you have a replacement .exe I could test for you? [22:40] I gotta skip out for lunch, but If there's anything I can do to help I'll give it a go. [22:45] I do, it's 32 bit though. [22:47] thomi|work: http://float.endofinternet.org/temp/pageant_dbg.zip [22:48] it's built with the debug stuff enabled so pops up a console with info [22:48] 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] hi poolie [22:55] hi Noldorin [22:56] alansaul: OK, yeah, that was sorta like 15 or 20 minutes... [22:56] fullermd: Lol thats cool thanks for coming back :) [22:57] poolie, saw your response to my bug (suggestion) about download types, etc. happy to talk about it here if you like [22:57] I have to go reasonably soon though! [22:57] So, did that reading illuminate anything for you? [22:57] so I need to find the revid that relates to revno 48 and revert back to that? [22:57] its still there somewhere [22:58] Yah. Or the new revno, even. [22:58] Look at `bzr log -n0`. Your latest rev is the one that merged trunk, right? [22:58] 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] naw the last one isnt the merge [23:00] I have a revno: 16.2.1 [merge] though [23:00] but its a few revisions behind, im on revision 24 [23:00] 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] Well, wherever it was. You merged in trunk, before pushing over it. [23:01] I'm presuming you haven't done anything on trunk since (nor anybody else); in that case things get messier. [23:01] I don't think so no [23:01] 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] 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] 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] I think I want to revert back to revno: 16.2.1 [merge] [23:04] 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] Ummm im not sure what you mean? [23:06] There is a further indented bit [23:07] revno: 16.1.29 [23:07] Mmm. Is this something you can share? [23:07] 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] i.e., a public branch I can clone and look at? Or a log you can substantially pastebin? [23:44] 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] (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] s/my/me/ [23:45] yeah, going a bit overboard jelmer :) [23:45] one complaint, adding more things that bz2 on the fly is kinda ugh [23:46] wgz: what would you like to do instead? [23:46] practically, or ideally? :) [23:47] I'd like to see numbers for size/performance vs zlib [23:47] both :) [23:47] ideally, sendfile. [23:48] wgz: sendfile doesn't seem ideal bandwidth-wise [23:50] wgz: you have a point bout zlib vs bz2 though [23:50] *about [23:50] hi all [23:51] jelmer, i like seeing all those patches [23:51] you should run it under Judge :) [23:51] you might need to patch it to add some more options, like for the number of times [23:51] to run the test [23:51] i really hope to go back to memory consumption soon [23:51] i did some fun lp hacks on the weekend though [23:51] 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] 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] hi poolie [23:53] poolie: Yeah, I should give that a try, at least for some of the methods where performance is relevant. [23:54] 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] jelmer: :) [23:56] hi spiv [23:56] poolie: btw, thanks for being so persistent in trying to separate launchpad-buildd from its big siamese twin :) [23:56] hey spiv [23:56] it's kinda funny [23:56] just when you think it's deleted it rises back up like a zombie [23:57] do you guys really like the subunit test output? [23:57] i'm not finding it very easy to deal with [23:57] it makes a massive difference for anything doing operations on a remote repo [23:57] poolie: :) [23:57] eg subunit crashed filtering this failure [23:58] 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] but for mirroring the data it can be suprisingly poor [23:59] poolie: not much. are we talking pqm or in general? [23:59] it has definite robustness issues.