| === matsubara is now known as matsubara-afk | ||
| lifeless | vila: could you pqm-submit the env-variable branch for me? I've let my pqm-submit setup bitrot... | 03:23 |
|---|---|---|
| vila | lifeless: done | 06:16 |
| === mmrazik is now known as mmrazik|otp | ||
| === mmrazik|otp is now known as mmrazik | ||
| === _rvba is now known as rvba | ||
| === mmrazik is now known as mmrazik|lunch | ||
| lduros | hi, for some reason I can never find in the docs the part that talks about what OTHER, THIS, BASE, and diff files represent when there's a conflict | 10:17 |
| lduros | can anyone point me towards the documentation for this? | 10:17 |
| lduros | Thanks, | 10:17 |
| lduros | hmm I guess this works: http://doc.bazaar.canonical.com/beta/en/user-guide/resolving_conflicts.html | 10:17 |
| lduros | not so much | 10:17 |
| lduros | haha | 10:17 |
| bob2 | OTHER is the other branch | 10:19 |
| bob2 | THIS is your branch | 10:19 |
| bob2 | BASE is their common ancestor | 10:19 |
| bob2 | it's a regular diff3 thing | 10:19 |
| lduros | bob2: so OTHER is the branch that I tried to merge into the current branch, right? | 10:19 |
| lduros | i did: bzr merge upstream | 10:19 |
| lduros | so OTHER is upstream, yeh ok | 10:20 |
| mgz | just about still morning! | 10:21 |
| lduros | bob2: thanks much | 10:21 |
| lduros | so when I see <<<<<<< TREE what does it mean? | 10:23 |
| bob2 | that you shouldn't use bound branches | 10:24 |
| lduros | huh? | 10:25 |
| lduros | they are not bound | 10:25 |
| bob2 | did you have uncomited changes? | 10:28 |
| lduros | no | 10:28 |
| lduros | everything was fine before I did the merge | 10:28 |
| lduros | no uncommited changes | 10:28 |
| lduros | ah well, I just got rid of that :-) | 10:28 |
| bob2 | er | 10:28 |
| bob2 | of course you need to resolve the conflict | 10:28 |
| lduros | right | 10:28 |
| lduros | bob2: I have a lot of conflicts to resolve. I'm merging an upstream branch that's Firefox 15.0.1 into my 'IceCat' branch. So from one version to the other there are thousands of changes, and about 80 conflicts | 10:30 |
| lduros | so far bzr works really well for this purpose though | 10:31 |
| lduros | helps catch changes that you don't want applied etc, ... | 10:31 |
| fullermd | Pretty sure 'tree' is just the normal name for the local side. | 10:33 |
| mgrandi_ | its still confusing on what file you actually edit to resolve the conflicts, or i can never figure it out | 10:33 |
| lduros | hmm ok | 10:33 |
| mgrandi_ | in combination with random diff programs | 10:33 |
| lduros | mgrandi_: yeh, it can get confusing, especially when you have myriads changes | 10:34 |
| lduros | I guess it's part of the fun though! :-) | 10:34 |
| mgrandi_ | in tortoisesvn, their diff program just has a middle thing where you say 'use these changes' | 10:34 |
| mgrandi_ | can't seem to get that =/ | 10:35 |
| lduros | hmm cool | 10:35 |
| mgz | mgrandi_: if you use a mergetool, several provide a similar interface | 10:51 |
| mgz | but the rule for manually resolving conflicts in a plain text editor is you just use the actual file, not any of the ones with extensions | 10:51 |
| lduros | mgz: you mean, you just "modify" the actual file? Or you only "look" at the actual file? | 11:02 |
| fullermd | Modify. The .WHATEVER files aren't versioned or anything, they're just droppings bzr leaves to help you if you want to use them. Only the file itself matters. | 11:03 |
| lduros | right | 11:06 |
| === mmrazik|lunch is now known as mmrazik | ||
| === matsubara-afk is now known as matsubara | ||
| === mmrazik is now known as mmrazik|otp | ||
| === Guest32361 is now known as slank | ||
| === slank is now known as Guest2828 | ||
| === mmrazik|otp is now known as mmrazik | ||
| mgriffin | is there a way with an LP project to see what size each revision was? | 15:23 |
| mgz | what do you mean by size exactly? | 15:23 |
| mgriffin | i was looking at a project and it has a 140M .pack file | 15:24 |
| mgriffin | Thought might be similar to something like https://answers.launchpad.net/bzr/+question/194724 | 15:25 |
| mgz | so, I have the start of a plugin for diagnosing bloated revisions | 15:26 |
| mgz | but it's not polished or real world exercised yet | 15:27 |
| mgriffin | no problem. there isn't a way in LP i guess then to see what size a bzr branch lp:foo will result in? | 15:28 |
| mgz | but feel free to try it on a local branch | 15:28 |
| mgz | get lp:~gz/+junk/bzr-repobloat and run `bzr find-bloat` | 15:28 |
| mgriffin | alright, will do. | 15:29 |
| fullermd | It wouldn't be too hard to just get the size of the pack files and add 'em up. Won't necessarily tell you how big your local branch would be, but it's probably within a factor of 2, at least on branches with reasonably long history. | 15:30 |
| mgz | right, if you just want to know repo size sftp into launchpad and ls I guess | 15:31 |
| fullermd | So there's at least one advantage to LP having no shared repo support ;p | 15:31 |
| === slank is now known as Guest55818 | ||
| mgz | fullermd: oh, but stacking | 15:36 |
| mgz | that could make the adding up complicated in a hurry | 15:36 |
| fullermd | That's what stacking is for, isn't it? | 15:37 |
| mgz | complicating things? yes. | 15:38 |
| fullermd | Prexactly. | 15:38 |
| mgriffin | so just put bzr-repobloat/ (includes a setup.py) in .bazaar/plugins/ cd .bazaar/plugins/bzr-repobloat/ and run python setup.py build_ext -i then bzr plugins? | 15:41 |
| mgriffin | i seem to have missed some step | 15:42 |
| fullermd | Just call it repobloat | 15:42 |
| mgriffin | also didnt have any luck connecting to code.launchpad.net with ftp client | 15:42 |
| mgriffin | :/ | 15:42 |
| fullermd | sftp, not ftp | 15:43 |
| * fullermd sharpens an extra dagger to plunge into the black burning heart of FTP. | 15:43 | |
| mgriffin | i thought sftp required auth. | 15:43 |
| mgriffin | thanks. | 15:43 |
| fullermd | Oh, yes. But FTP would too, if LP supported it. | 15:44 |
| fullermd | Unauth'd, I guess you could grab the pack names file over HTTP then do a bunch of HEAD's to get sizes. | 15:44 |
| mgz | lp admits http/sftp/bzr+ssh only | 15:45 |
| mgriffin | very noobish questions, thanks for the help anyway (i was putting the branch in plugins dir because i have no idea what i am doing, the plugin is listed now) | 15:47 |
| fullermd | Putting it in there is the right thing. 's just a quirk of bzr (rather, python) and lp that you have to rename it along the way. | 15:48 |
| mgz | mgriffin: did you get any output running that? if not, you probably want to poke the (currently magical private) variable _TOO_BIG in repobloat/commands.py | 16:01 |
| === matsubara is now known as matsubara-lunch | ||
| === Guest75974 is now known as dpb___ | ||
| mgriffin | mgz: actually i was getting a python traceback and kinda moved on | 17:20 |
| mgz | mgriffin: fair enough | 17:21 |
| mgriffin | i was just curious why lp:percona-xtrabackup/1.6 was 8.4M and lp:percona-xtrabackup/2.0 was 172M | 17:22 |
| mgriffin | http://privatepaste.com/649985e3c9 | 17:23 |
| mgz | that does sound like the sort of thing the plugin was aimed at (find bad rev, nuke it, and make repo a reasonable size again) | 17:25 |
| fullermd | Well, 2.0 - 1.6 is 0.4. 172:8.4 is a factor of ~20.4. There are 2 branches, with a difference of 0.4, thus we get 20.4. Makes perfect sense ;p | 17:25 |
| mgz | mgriffin: upgrading your bzr from 2.1.1 to something modern would fix that error | 17:25 |
| mgz | I can probably support older versions easily enough though, that's a simple module rename that's failing | 17:26 |
| bjp_ | i have a branch with a revision on 9/22 and one on 9/25, when i do 'bzr revno -rdate:2012-09-24' i get Requested revision: 'date:2012-09-24' does not exist in branch | 17:26 |
| bjp_ | shouldn't it grab the 9/25 one? | 17:26 |
| fullermd | Oh, that leads down the rathole of "look how touchy date: is"... | 17:28 |
| mgz | bjp_: it should really | 17:28 |
| bjp_ | :( | 17:29 |
| bjp_ | is it a bug in the version i'm using? 2.5.1 | 17:29 |
| mgz | poke fullermd more, I need to run :) | 17:29 |
| fullermd | It's probably a bug in the sense that "this really should work". I'm not sure it's a bug in the sense of "code not doing what it's expected to do", or in the sense of "regression from previous state". | 17:30 |
| fullermd | date: has always been pretty finicky about how it gets interpreted. | 17:30 |
| fullermd | (which, to be sure, shouldn't be read as praise or justification or claims that it _should_ be. Just always has, and nobody's ever buckled down to define and fix all the edge cases) | 17:33 |
| === matsubara-lunch is now known as matsubara | ||
| bjp_ | seems like a pretty strait forward case imo :) | 17:35 |
| bjp_ | according to bzr help anyway | 17:35 |
| fullermd | Famous last words 8-} | 17:35 |
| mgriffin | 2.1.1 is what ships with RHEL6 :/ | 17:36 |
| bjp_ | "Matches the first entry after a given date" :) | 17:37 |
| fullermd | mgriffin: Well, RHEL6 2010-11-10, for bzr 2.1.1 from 2010-03-24 isn't entirely insensible (though 2.1.3 was out before then, and there's another 2.1 release after that). Still, a long time ago in bzr terms... | 17:39 |
| === yofel_ is now known as yofel | ||
| ScottK | jelmer: Looks like some bzr packages are in need of love in Quantal: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20120922-quantal.html#bzr | 22:04 |
| jelmer | ScottK: Andrew S-B was looking into those | 22:07 |
| ScottK | OK. Wanted to make sure someone bzr'ish was aware. | 22:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!