| johnf | jelmer: ping | 00:06 |
|---|---|---|
| poolie | SmileyChris: when do you want that shown? | 00:40 |
| poolie | only when you ask for it? | 00:40 |
| poolie | or on every commit? | 00:40 |
| SmileyChris | poolie: I found how the equivalent shows up in "git status" useful | 00:40 |
| poolie | i can see how that would be useful | 00:41 |
| poolie | robert was asking for status to also tell you what branch you're working on | 00:41 |
| Peng_ | Git keeps every branch on-hand, but bzr doesn't, so it isn't really possible.. | 00:42 |
| fullermd | Sure it's possible. It's just really painful. | 00:43 |
| SmileyChris | yeah, thinking about it I realise it's a bit different, git has the remote origin branch stored locally in it's repo | 00:44 |
| poolie | well... | 00:45 |
| poolie | in at least some cases we could easily do it | 00:45 |
| SmileyChris | if the parent was local | 00:45 |
| zsquareplusc | something tag like that points at the revision i pushed/pulled last could be useful. so you find out by looking at your local history if you did offline work | 00:47 |
| zsquareplusc | hm, something like that could be hacked as plugin? pre-push hook: remove tag, then in post-push hook: add tag, move tag in post-pull and merge | 00:51 |
| zsquareplusc | there could even be multiple such tags, one for each location one used in the past to push to | 00:53 |
| spiv | Good morning. | 01:00 |
| poolie | hello spiv | 01:01 |
| spiv | poolie: I've got good progress on bug 429747 I think. | 01:04 |
| ubottu | Launchpad bug 429747 in bzr "errors during cleanup mask underlying errors" [High,Confirmed] https://launchpad.net/bugs/429747 | 01:04 |
| spiv | I think I have a reasonable interface and implementation for the higher-order-function suggested in the bug, and I'm just fleshing out the tests and experimenting with how it works in actual code. | 01:05 |
| spiv | There are a couple of variations, like "convenient way to run N cleanups so that they all run even if some fail", which commit at least ideally wants. | 01:07 |
| spiv | I have some code for those too, but there's also a simple "run_cleanup" function that just runs a function and logs/reports any error without letting it propagate. | 01:08 |
| spiv | poolie: still planning on coming up today? | 01:10 |
| poolie | spiv, hi | 01:12 |
| poolie | on phone atm, still basically planning | 01:12 |
| poolie | depending on weather | 01:12 |
| spiv | Yeah, it's a bit unpleasant. Fascinating though... | 01:14 |
| jkakar | lifeless: There? | 01:15 |
| spm | spiv: with any luck the rain we've copped overnight and is still happening should settle it all down for you. big mud puddles everywhere but an improvement. | 01:19 |
| spiv | spm: yeah, looking forward to that. | 01:19 |
| spiv | spm: in the meantime, I've been admiring http://www.flickr.com/photos/plasticbag/galleries/72157622310168099/ | 01:19 |
| spm | wow! we got nothing like that. dusty, but wow. | 01:20 |
| lifeless | jkakar: phone call | 01:25 |
| jkakar | lifeless: Ah, okay. | 01:25 |
| jkakar | spiv: Amazing photos! | 01:27 |
| thumper | lifeless, poolie: just an FYI, but upgrading stacked branches works now (just tested on staging) | 01:41 |
| thumper | for Launchpad anyway | 01:41 |
| ub3rst4r | Hi | 01:45 |
| ub3rst4r | does anyone know if tortoisebzr and tortoisesvn can be installed on the same system? | 01:45 |
| SamB_XP_ | ub3rst4r: is there any reason it wouldn't be possible ? | 01:46 |
| ub3rst4r | i dunno | 01:46 |
| igc | ub3rst4r: I believe they can be | 01:54 |
| lifeless | jkakar: hi | 02:07 |
| jkakar | lifeless: Heya! | 02:07 |
| jkakar | lifeless: I'd like to use cmd_alias in Commandant, ideally making it automatically available to any Commandant-based program. | 02:07 |
| jkakar | lifeless: I've implemented a prototype and got it working. | 02:07 |
| jkakar | lifeless: There's a couple of warts though: | 02:08 |
| jkakar | 1. It prints 'bzr' in it's output. I've dealt with this in the help text produced by Command.get_help_text by using text.replace("bzr", "my-program"). This trick isn't really possible with the cmd_alias command. | 02:09 |
| jkakar | 2. I have to monkey patch the bzrlib.config.config_filename to return the patch to my program's configuration file, instead of ~/.bazaar/bazaar.conf. | 02:09 |
| jkakar | lifeless: So, I'm thinking about making the change in Bazaar to make this easier. | 02:10 |
| jkakar | I think these are: 1. Add a set_config_filename function to bzrlib.config. | 02:10 |
| lifeless | if I can tempt you with doing a little more | 02:11 |
| jkakar | 2. Add get_program_name and set_program_name functions (probably to bzrlib.__init__) which default to 'bzr'. Change places that use 'bzr' to use the function. | 02:11 |
| lifeless | we'd like /etc/bazaar/*.conf to work (bazaar/locations/..) | 02:11 |
| jkakar | 3. Make %(program-name)s work in docstrings. | 02:11 |
| lifeless | this would seeem to conflict with just set_config_filename | 02:11 |
| jkakar | lifeless: Yeah, it feels like what I'm proposing is good for me, but not necessarily clean for Bazaar. | 02:12 |
| jkakar | lifeless: That's why I wanted to chat you up, to figure out what the right thing to do is. I'm happy to be tempted to do more than I originally intended. :) | 02:12 |
| lifeless | jkakar: so I think if you got /etc/bazaar/* working, and then added something that works for you, we'd both be happy | 02:13 |
| lifeless | for get/set program name. | 02:13 |
| * fullermd is very worried about implementations of /etc/bazaar/* | 02:13 | |
| lifeless | that's fine, I wouldn't add it to __init__ though | 02:13 |
| lifeless | commands for now please | 02:14 |
| jkakar | lifeless: Ah, so for /etc/bazaar/* you want something like a set_config_path? | 02:14 |
| jkakar | lifeless: commands sounds like a good place for that, yeah. | 02:14 |
| lifeless | and 3 seems kindof obvious | 02:14 |
| jkakar | Cool. | 02:14 |
| lifeless | fullermd: in what regard? | 02:14 |
| lifeless | jkakar: for substitions, uhm, there should be a method on Command | 02:15 |
| lifeless | or something like that, so it can be locally controlled yada yada yada | 02:15 |
| lifeless | either to do, or to look up the thing being substituted | 02:15 |
| lifeless | we have 2 primary use cases today: manpage generation, and online help | 02:16 |
| jkakar | lifeless: Yeah, I was thinking about something like adding a check for a get_substituted_variables function on command, and then passing the dict of default + command variables to Command.get_help_text. | 02:16 |
| fullermd | Well, in a sentence, because it brings up a lot of problems in our config structure, which means either (a) a very long process of working them out, or (b) an implementation that explicitly disavows doing that, and probably makes it worse in the long run. | 02:16 |
| lifeless | fullermd: what sort of problems - I'm completely at a loss here | 02:16 |
| jkakar | lifeless: I'll have to figure out how manpages are generated to make sure the substitution logic lands in the right places. | 02:17 |
| lifeless | jkakar: see make docs | 02:17 |
| jkakar | lifeless: Ta. | 02:17 |
| fullermd | It relates to the issue of "branch.conf parameters that should be propogated by branch vs shouldn't", which we unsatisfactorally sidestep at the moment. | 02:17 |
| fullermd | Some things we'd want to hard-override per system, some we'd want to default. Mechanism, blah blah. | 02:18 |
| fullermd | (and the unrelated issue of "/etc? No, it should be..." of course) | 02:18 |
| lifeless | fullermd: will you be unhappy if jkakar puts a patch forward that makes /etc/bazaar/bazaar.conf & locations.conf work ? | 02:20 |
| * fullermd shrugs. | 02:21 | |
| fullermd | I don't get a vote in such things anyway. | 02:21 |
| fullermd | I'm just rather pessimistic today, and it feels lose-lose to me. | 02:21 |
| fullermd | If the discussion doesn't come up, we've added another layer of pre-existing conditions we have to somehow not screw up when we DO add such capabilities. | 02:21 |
| fullermd | If it does, I'm sure it will get to a useful conclusion almost as fast as per-branch rules. | 02:22 |
| lifeless | fullermd: so per branch rules stuck because the folk needed in such a discussion where backlogged way above eyeballs with performance | 02:23 |
| lifeless | fullermd: and its non trivial. | 02:23 |
| lifeless | fullermd: If you agree that system wide configuration is useful [do you?] | 02:24 |
| fullermd | I know. I don't claim it's because of malice or indifference, but it still bogs down. | 02:24 |
| poolie | i think we certainly want system-wide config | 02:25 |
| poolie | we can always say 'we suggest you don't set X system-wide' | 02:25 |
| lifeless | yup | 02:26 |
| lifeless | jkakar: so - we have a go ;) | 02:26 |
| poolie | jkakar: can i suggest that rather than setting these things individually there should be some kind of ConfigFactory | 02:26 |
| fullermd | Absolutely. We very much need many levels of configuration beyond "OK, tell all your users to manually edit this file to add these lines" | 02:26 |
| poolie | and you replace that wholesale to make it think it's called something other than bzr | 02:26 |
| jkakar | poolie: Sounds like a plan. | 02:42 |
| jkakar | lifeless: Yep, I'll start on it tonight. :) | 02:43 |
| poolie | lifeless: do you know off hand how to ask apt whether a set of packages would be installable, short of installing it? | 02:52 |
| lifeless | nope, sorry | 02:52 |
| lifeless | theres a graph resolver thingy | 02:52 |
| poolie | justinstall --dry-run? | 02:52 |
| lifeless | oh | 02:52 |
| lifeless | I thought you meant pyapt :) | 02:52 |
| lifeless | thingywhatsit | 02:53 |
| jkakar | apt-get -u install foo? | 02:53 |
| lifeless | apt-get -s install foo | 02:53 |
| poolie | mm | 02:53 |
| poolie | https://bugs.edge.launchpad.net/ubuntu/+source/devscripts/+bug/434987 | 02:53 |
| ubottu | Launchpad bug 434987 in devscripts "chdist fails with "E: Internal Error, Could not perform immediate configuration (2) on libattr1"" [Undecided,New] | 02:53 |
| jkakar | Ah, -s it is indeed. I'm used to using -u with upgrade and dist-upgrade so thought it might work with install (it doesn't). | 02:54 |
| poolie | -u shows what will be upgraded | 02:55 |
| poolie | lifeless: http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090903.pdf <-- a bit interesting | 03:00 |
| lifeless | images...pdf :P | 03:00 |
| lifeless | [reading] | 03:01 |
| lifeless | this explains why they did the C code blocks work :P | 03:03 |
| Meths | I needed to use non bzr diff and patch. The patch is only changing a few lines in the files but bzr diff shows that bzr wants to change the whole file for those changed. Can I do anything about this? | 03:06 |
| davidstrauss | Meths: you may be dealing with some EOL issues | 03:08 |
| lifeless | Meths: are you on windows? | 03:08 |
| Meths | yeah | 03:08 |
| lifeless | patch has probably changed the line ending on the file | 03:08 |
| lifeless | you could see if it has an option to control that, and if it does bzr revert then apply the patch again with that option | 03:08 |
| Peng_ | Diff and patch? Like, GNU diff and patch? | 03:08 |
| Meths | ah, so a dos2unix should get a normal diff, I'll go try now, thanks. | 03:09 |
| Meths | Peng_: yep | 03:09 |
| Peng_ | What are you doing? Why not use 'bzr merge' or a revision bundle or somesuch? | 03:09 |
| Meths | Sweet, dos2unix fixed them up nicely, shoulda known | 03:11 |
| thumper | :( | 03:29 |
| thumper | a crash | 03:29 |
| Peng_ | What crashed? | 03:30 |
| thumper | bzr | 03:30 |
| * thumper is filing a bug | 03:31 | |
| Peng_ | Ah. | 03:31 |
| thumper | https://bugs.edge.launchpad.net/bzr/+bug/435000 | 03:33 |
| ubottu | Launchpad bug 435000 in bzr "bzr crashed on commit after removing a directory of files" [Undecided,New] | 03:33 |
| Peng_ | Nice bug number. | 03:34 |
| thumper | I've made a local branch | 03:37 |
| thumper | and I've just committed to it | 03:37 |
| thumper | but I want to push the branch as of one revision ago to LP | 03:37 |
| thumper | is there an easy way to do this? | 03:37 |
| Peng_ | bzr push -r 123 | 03:37 |
| Peng_ | Well, -2 | 03:37 |
| * igc lunch | 03:37 | |
| * thumper tries | 03:38 | |
| spm | spiv: more dust photo's, tho .. I dunno. 'shopped maybe? http://www.militaryphotos.net/forums/showthread.php?t=165656 | 03:47 |
| spiv | spm: nah, I used to live near there. That was a regular sight ;) | 03:49 |
| * spm thinks for a suitable response. can't, so just sniggers. | 03:50 | |
| poolie1 | hello all | 05:23 |
| lifeless | hai | 05:25 |
| lifeless | versioning yourself now? | 05:25 |
| Peng_ | poolie1.1.1.1.1.1 | 05:25 |
| Peng_ | :D | 05:25 |
| poolie1 | is irc bug | 05:26 |
| Peng_ | No, it would be like poolie1.1.1.1.1397.1. | 05:26 |
| Peng_ | Anyway, I'm done now. | 05:26 |
| === poolie1 is now known as poolie | ||
| poolie | lifeless: any particular reason for bug 435026? | 06:01 |
| ubottu | Launchpad bug 435026 in bzr "bzrlib.ui docstring references factories not in the module" [Wishlist,Confirmed] https://launchpad.net/bugs/435026 | 06:01 |
| spiv | Hmm, I think clearing test._log_contents in more cases (e.g. not applicable, known failure) significantly cuts the test suite's memory consumption... | 06:04 |
| Peng_ | How significantly? | 06:05 |
| spiv | it's only at 59M after 1500 tests, and growing very slowly. | 06:05 |
| spiv | Give me a few minutes and I'll have a decent direct comparison. | 06:06 |
| lifeless | poolie: yes, fixing a deprecation warning you added ;) | 06:06 |
| lifeless | poolie: in conflictchecker, its cron is annoying everyone watching it ;) | 06:07 |
| poolie | ? | 06:07 |
| poolie | which one? | 06:07 |
| lifeless | poolie: direct construction of ProgressBar | 06:07 |
| poolie | and what checks the docstring? | 06:07 |
| lifeless | programmers | 06:07 |
| lifeless | I read pydoc to find out what I should be using | 06:08 |
| lifeless | and had forgotten that things were in submodules, so when I added ui_factory=bzrlib.ui.TextUIFactory() - well it failed ;) | 06:08 |
| poolie | i'll fix that bug if you're not immediately going to | 06:08 |
| lifeless | poolie: please | 06:09 |
| lifeless | poolie: its not major, but having observed it I just wanted to capture it | 06:09 |
| poolie | sure | 06:09 |
| poolie | i just wondered if you were running an api doc tool or something | 06:09 |
| lifeless | no, interesting idea though | 06:10 |
| spiv | Hmm, or maybe it's making less difference than I thought. I thought I was seeing much worse memory consumption yesterday though... hmm. | 06:13 |
| Peng_ | ~1514 tests == VmPeak of about 205 MB for me. | 06:13 |
| spiv | Peng_: I'm running the "(?i)commit" subset, for no particular reason. | 06:14 |
| spiv | And on 32-bit. | 06:14 |
| Peng_ | I was running no particular subset, on 32-bit. | 06:14 |
| spiv | I'm not sure VmPeak is very useful, I think Python tends to allocate lots more address space than it actually uses. | 06:15 |
| Peng_ | VmPeak is interesting because everything else is the current value, not the peak value. | 06:16 |
| Peng_ | VmRSS: 85584 kB | 06:16 |
| spiv | I tend to look at VmHWM. I wouldn't mind an authorative link for exactly what the different fields in -Dmemory mean... | 06:17 |
| spiv | I know *roughly*, but details tend to matter. | 06:17 |
| Peng_ | I have no idea what VmHWM is. | 06:17 |
| spiv | Peng_: man proc claims "Peak resident set size ("high water mark")" | 06:19 |
| Peng_ | Oh, cool! | 06:19 |
| Peng_ | That sounds perfect! | 06:19 |
| Peng_ | spiv++ | 06:19 |
| poolie | lifeless: http://pastebin.ubuntu.com/276214/ - pre-review welcome | 06:26 |
| lifeless | what am I looking at? | 06:27 |
| RenatoSilva | is there how to query bzr status of a file? | 06:29 |
| lifeless | bzr st file | 06:29 |
| RenatoSilva | I'm doing a rebase but when I commit the change list shows "missing some_file.OTHER" | 06:30 |
| poolie | lifeless: the whole file is new, it's an attempt at interface testing of uifactory | 06:30 |
| lifeless | poolie: ok | 06:30 |
| poolie | i think it's uncontroversial | 06:30 |
| poolie | but that's why i'm asking | 06:30 |
| lifeless | poolie: I just needed some context :) | 06:31 |
| poolie | there's a comment explaining the point, but we also talked about this a while ago | 06:31 |
| RenatoSilva | a conflict occurred in rebase, so I solved it manually and bzr resolve filename, but now when I commit filename.OTHER shows as missing | 06:32 |
| lifeless | poolie: I'd be very strongly inclined to use injection rather than subclassing here. | 06:32 |
| RenatoSilva | is this normal? I don't want that artificial info on the history | 06:32 |
| lifeless | RenatoSilva: I don't really know, few folk in the bzr community use rebase. | 06:33 |
| poolie | if the files were added on separate branches that you're now rebasing together | 06:33 |
| RenatoSilva | lifeless: it seems very interesting! | 06:33 |
| poolie | it's reasonable that you'd end up with | 06:33 |
| poolie | that kind of conflict and it's not necessarily a problem | 06:33 |
| poolie | lifeless: tell me why? just because we're generally doing that? | 06:34 |
| RenatoSilva | poolie: I'm not asking about the conflict itself, which was solved | 06:34 |
| poolie | i was originally going to do that but the problem i ran into is that the resource i want to inject includes some code that makes assertions about what happened | 06:34 |
| RenatoSilva | poolie: I'm asking about the artificial "missing xxx.OTHER" when committing | 06:34 |
| poolie | and that code can most conveniently be written within a subclass of TestCase | 06:35 |
| lifeless | poolie: I think it would fit and scale better | 06:35 |
| poolie | to use scenarios? | 06:36 |
| lifeless | poolie: yes | 06:36 |
| poolie | mm | 06:36 |
| lifeless | poolie: possibly in combination with resources, or something the encapsulates the setup of the fixture | 06:36 |
| poolie | how would you handle having assertion-making code be parameterised? | 06:36 |
| lifeless | s/the/that/ | 06:36 |
| RenatoSilva | lifeless: I just achieved a clearer, natural history, as described in http://pastie.org/625271 | 06:37 |
| RenatoSilva | lifeless: a guy from #git said that it may work for small feature branches, but not for long-lived | 06:37 |
| lifeless | so | 06:38 |
| lifeless | your conflict is probably a name conflict | 06:38 |
| lifeless | xxx.OTHER means rebase is trying to readd a file already on the other side | 06:39 |
| lifeless | this could be a bug in rebase | 06:39 |
| lifeless | or in how you're using it. | 06:39 |
| RenatoSilva | lifeless: weird! I uncommitted, then committed again and the xx.OTHER is not reported anymore | 06:39 |
| lifeless | thats because the pointer to it was removed on the first commit | 06:39 |
| RenatoSilva | so it's a bug right | 06:40 |
| lifeless | you may find you get a delete+add when you merge to the other branch | 06:40 |
| lifeless | and that your history of that file is disconnected | 06:40 |
| lifeless | RenatoSilva: no, it may be you using rebase when you shouldn't :). Or it may be a bug. I don't know. | 06:40 |
| RenatoSilva | lifeless: bzr resolve --all maybe does not clean .OTHER files | 06:41 |
| lifeless | poolie: well, when I look at your code, you have 'create a resource' code, 'execute the test' code, and 'check the resource' code. | 06:41 |
| lifeless | RenatoSilva: the file was deleted, but your tree still wanted it. | 06:41 |
| lifeless | RenatoSilva: because it was part of the conflict | 06:41 |
| RenatoSilva | lifeless: conflicts on a merge are displayed as BASE and THIS, in rebase it is BASE and OTHER, maybe bzr resolve does not know OTHER | 06:42 |
| lifeless | RenatoSilva: conflicts within a file are BASE+THIS+OTHER, conflicts about *names* show up differently. | 06:42 |
| lifeless | RenatoSilva: but I'm having to guess because I don't know what happened | 06:42 |
| RenatoSilva | lifeless: well, I think bzr resolve --all should have deleted all info about those files | 06:43 |
| jkakar | Woot, Command.get_help_text is using the program name from a centrally registered ProgramInfo instance! | 06:48 |
| poolie | spiv: https://bugs.edge.launchpad.net/bzr/+bug/435048 | 06:51 |
| ubottu | Launchpad bug 435048 in bzr "many get_parent_map calls during walk to common revisions" [Medium,Confirmed] | 06:51 |
| spiv | poolie: thanks | 06:52 |
| lifeless | is that new or old ? :) | 06:52 |
| spiv | lifeless: the bug? Dunno, that's why I asked him to file it ;) | 06:53 |
| RenatoSilva | lifeless: http://yfrog.com/0ximagemxap | 06:53 |
| RenatoSilva | lifeless: better resolution: http://img33.yfrog.com/img33/5295/imagemxa.png | 06:53 |
| lifeless | RenatoSilva: yes, I understand what you're doing | 06:55 |
| lifeless | RenatoSilva: that doesn't mean I know what happened | 06:55 |
| lifeless | RenatoSilva: you need to look at the per file graphes | 06:55 |
| lifeless | I will also note that you're publishing these branches as you develop, so rebase really isn't a good choice. | 06:56 |
| RenatoSilva | lifeless: for solving the .OTHER issue? I think it's ok now | 06:56 |
| lifeless | RenatoSilva: Until you've checked the per file graph in both branches after merging back, you can't know. | 06:56 |
| RenatoSilva | lifeless: confusing | 06:57 |
| lifeless | RenatoSilva: how so? | 06:58 |
| RenatoSilva | publishing these branches as you develop, so rebase really isn't a good choice. ----> I don't know how would that rebase affect another derived branches, I think that it would make merge easier. I don't know... | 07:01 |
| RenatoSilva | maybe I need to get more experienced | 07:02 |
| RenatoSilva | try it and see....but as you say that rebase is bad, maybe I'll keep the former approach (update merges) | 07:04 |
| RenatoSilva | the wonderful thing of that rebase is that it's just liked I branched trunk today, and I could bzr push (not merge) to trunk now | 07:05 |
| * RenatoSilva flips a coin for pushing userprefs or userprefs.rebase | 07:06 | |
| lifeless | RenatoSilva: rebase _breaks_ the ability to pull or merge the old branch | 07:07 |
| lifeless | RenatoSilva: it breaks the links in history | 07:07 |
| lifeless | RenatoSilva: in the git world, rebase is used for private branches, not for ones shown to the world | 07:07 |
| RenatoSilva | well, I can't understand it atm, hope to do in the future as I get more used to it... | 07:11 |
| RenatoSilva | thank you anyway! | 07:11 |
| vila | hi all | 07:13 |
| lifeless | hi | 07:13 |
| lifeless | http://paste.ubuntu.com/271990/ have you reproduced at all? | 07:13 |
| vila | lifeless: actually, yes, just this morning on gentoo, but it's still... random | 07:15 |
| lifeless | vila: open a bug please | 07:15 |
| lifeless | was it ext4 again? | 07:15 |
| vila | lifeless: err, let me check, I think the last time was on karmic no ? | 07:16 |
| vila | no ext4 on my gentoo VM | 07:16 |
| vila | lifeless: so tmpfs or ext3 | 07:17 |
| jkakar | lifeless: I think I've done the basic things necessary to have customizable program information (name and version right now) and substitution in help text generated from docstrings. | 07:39 |
| jkakar | lifeless: I'm going to start a second branch, based on this first one, to update bzrlib.builtins, since I've only touched bzrlib.commands so far. | 07:40 |
| jkakar | lifeless: Should I create a merge proposal for the first branch now, or would you prefer them together? | 07:40 |
| vila | lifeless: bug #435065 | 07:51 |
| ubottu | Launchpad bug 435065 in bzr "Random test_hammer_hashcache failure" [Medium,Confirmed] https://launchpad.net/bugs/435065 | 07:51 |
| vila | lifeless: I'll comment to add the new occurrences if ever | 07:52 |
| AfC2 | at first I thought that said "test hammer headache failure" which I would think would be an easy test to pass; apply hammer to head, and assert(). | 07:52 |
| === AfC2 is now known as AfC | ||
| === vila is now known as vila-dentist | ||
| vila-dentist | AfC: :D | 07:55 |
| lifeless | vila-dentist: thanks | 07:58 |
| jkakar | Are there tests for the bzrlib.builtins module? | 08:10 |
| jkakar | Ah ha, bzrlib/tests/commands. | 08:11 |
| lifeless | jkakar: not really | 08:18 |
| lifeless | jkakar: they are ... odd | 08:18 |
| lifeless | jkakar: bzrlib/tests/blackbox/test_foo is our current preferred place | 08:18 |
| jkakar | lifeless: Yeah. | 08:35 |
| jkakar | lifeless: I'd like to write a test that basically goes through each builtin command and calls Command.get_help_text() on it, to make sure that the interpolation works properly. | 08:35 |
| jkakar | I don't want to misspell %(program-name)s and not find out until it's too late. | 08:37 |
| lifeless | jkakar: don't | 08:38 |
| jkakar | lifeless: Heh, okay. | 08:38 |
| lifeless | jkakar: I think thats essentially a CPU time waste | 08:38 |
| lifeless | because, the code is in command.py | 08:39 |
| jkakar | lifeless: Yeah, I can see that. On the other hand, I do want to make sure users don't get a broken experience. | 08:39 |
| lifeless | so we should have a test there | 08:39 |
| === weigon_ is now known as jan | ||
| lifeless | if a particular command wants to vary, it should be able to | 08:39 |
| === jan is now known as weigon | ||
| lifeless | I don't think that e.g. 'cmd_push' should show up as anything other than 'bzr push' in its help | 08:39 |
| jkakar | There's a test for the generic logic, just not each actual docstring for each builtin command. | 08:39 |
| jkakar | lifeless: Oh, hmm. | 08:39 |
| jkakar | lifeless: I've gone and replaced all the 'bzr' instances in the help text with %(program-name)s. | 08:40 |
| lifeless | there are commands that are general and reusable | 08:40 |
| lifeless | such as alias, where it makes sense | 08:40 |
| jkakar | lifeless: Maybe I should only do it for commands that are obviously reusable? | 08:40 |
| lifeless | jkakar: I think you should do it for the ones you want to reuse, so we can evaluate if it makes sense etc | 08:41 |
| lifeless | cmd_help :) | 08:41 |
| lifeless | I don't see that branding the front end for 'cmd_serve' makes a lot of sense though. | 08:41 |
| jkakar | lifeless: Also cmd_version. | 08:41 |
| lifeless | the text is easier to read for program authors as 'bzr this' | 08:42 |
| lifeless | and 'bzr that' | 08:42 |
| jkakar | lifeless: Okay, I guess I'll revert the changes that aren't necessary. | 08:42 |
| jkakar | lifeless: It is, yeah. | 08:42 |
| lifeless | so we should only pay the price of having it have subst vars when there is a benefit | 08:42 |
| jkakar | lifeless: Right now it always tries to. | 08:42 |
| lifeless | [a benefit we want :P] | 08:42 |
| === vila-dentist is now known as vila | ||
| lifeless | jkakar: the cost to calculate them is low, I'm fine with the program always translating | 08:42 |
| jkakar | lifeless: Okay, cool. | 08:43 |
| lifeless | jkakar: cmd_version seems surprising to me, I would have expected --version to be what you advertise/want folk to see | 08:43 |
| jkakar | lifeless: I was just looking at it and it's not as trivial to replace as I'd hoped. | 08:46 |
| jkakar | lifeless: I have a cmd_version in commandant.builtins that prints the program name and version and has a --short option. | 08:47 |
| jkakar | lifeless: I was hoping to remove it and use the version in bzrlib, but it's not obvious just now how to do that nicely. | 08:47 |
| lifeless | I have two thoughts here | 08:49 |
| lifeless | one is that --version != 'frontend version'. I wish bzr didn't have a 'version' command. | 08:50 |
| lifeless | the second is that you can probably write an appropriately hookable thing, but its such a shallow thing I'd rather we encouraged people to do what bzr does | 08:50 |
| lifeless | and include all sorts of useful things there | 08:51 |
| lifeless | by not giving the a fork | 08:51 |
| lifeless | the second is kindofweakandarguable | 08:51 |
| jkakar | Yeah, makes sense. | 08:53 |
| jkakar | Being able to install a custom bzrlib.version.show_version would be the trick I guess. | 08:54 |
| lifeless | fullermd: hey | 09:04 |
| lifeless | fullermd: you still around? | 09:04 |
| === mrevell-dinner is now known as mrevell | ||
| bialix | hello bzr | 09:16 |
| AfC | Where do you say in Launchpad what version of Ubuntu you're running when reporting a bug? | 09:19 |
| beuno | AfC, in the comment? :) | 09:19 |
| beuno | otherwise, you file the bug against the package in the specific series | 09:20 |
| lifeless | AfC: ubuntu-bug will do that for you | 09:20 |
| lifeless | beuno: garh no | 09:20 |
| AfC | lifeless: what's that? | 09:20 |
| lifeless | AfC: are you filing a bug upstream on e.g. bzr, or on something in ubuntu itself? | 09:20 |
| AfC | beuno: really? You mean their bug tracker devoted to bugs about a Linux distro doesn't have concrete metadata for which distro version something is being reported about? | 09:21 |
| AfC | lifeless: ubuntu | 09:21 |
| lifeless | AfC: then you should run, on your machine 'ubuntu-bug PACKAGE' | 09:22 |
| lifeless | AfC: and thats all :> | 09:22 |
| AfC | oh | 09:22 |
| beuno | AfC, correct. Primarily because it's not ubuntu-specific | 09:22 |
| AfC | [well, in this case not sure what package, but I guessed] | 09:22 |
| AfC | beuno: well that's stupid. | 09:22 |
| AfC | beuno: because it may not be Ubuntu specific, but it's surely Ubuntu central! | 09:22 |
| lifeless | AfC: the feature of tracking versions <->packages is called 'infestation'. We had it, but not polished, so it was removed to avoid the massive scaling problems it engendered. | 09:22 |
| lifeless | beuno: I think you should have some coffee; or some sleep. | 09:23 |
| AfC | lifeless: sure | 09:23 |
| * igc dinner | 09:23 | |
| beuno | lifeless, I've had both! | 09:23 |
| AfC | lifeless: but I mean, you'd think it'd be important for me to concretely be able to say | 09:23 |
| lifeless | beuno: because you're suggesting things the ubuntu bugs team would be quite unhappy with! | 09:23 |
| AfC | "THIS IS A RELEASE CRITICAL BUG IN KARMIC". You know, just FYI. Trying to help. Hello? Anyone? | 09:23 |
| lifeless | AfC: so by definition we can only have RC bugs with unreleased code ;) | 09:24 |
| beuno | lifeless, I don't think I'm suggesting anything at all. I'm stating how things work! | 09:24 |
| lifeless | AfC: a floating bug is presumed to be in karmic | 09:24 |
| lifeless | beuno: only ubuntu-bugs & teams with similar privileges can open series bugs; other folk have to nominate. | 09:24 |
| AfC | lifeless: well, sure. I'm taking the definition from what it meant in Debian terms ~ 10 years ago. I'm sure things have involved. | 09:24 |
| AfC | evolved* | 09:24 |
| lifeless | beuno: and its used to track planned work, not present-in | 09:25 |
| lifeless | beuno: in Ubuntu's usage of launchpad today. | 09:25 |
| AfC | anyway, it just seems kinda important to be able to indicate I'm actually using Karmic so that maybe this report is timely, etc | 09:25 |
| AfC | oh well | 09:25 |
| AfC | they'll see it some time in 2012. | 09:25 |
| lifeless | AfC: the vast bulk of reports are from $current | 09:26 |
| lifeless | end users rarely file bugs compared to contributors | 09:26 |
| AfC | lifeless: so am I running $current or $current + 1? | 09:26 |
| lifeless | (and by running karmic you're a contributor) | 09:26 |
| AfC | lifeless: yeah, not for long | 09:27 |
| lifeless | in my lingo you're running $current | 09:27 |
| * AfC can't wait to not be a contributor anymore. This is hell | 09:27 | |
| AfC | Yesterday it was "crash the system on logout". | 09:27 |
| AfC | I mean, sure, that's one way to shut down, but not quite what I had in mind :) | 09:27 |
| jnz_ | Hi, where's the plugins directory? it isn't ~/.bazaar/plugins? | 09:27 |
| AfC | jnz_: yes | 09:28 |
| jnz_ | it isn't there :\\\ | 09:28 |
| beuno | jnz_, you can create it | 09:28 |
| AfC | lifeless: and, of course, "try to use 3G card a 2nd time makes CPU spin to 100%, no workie for you" is not exactly fun either. Especially when it was working fine 4 days ago. | 09:29 |
| jnz_ | ok, and what about this: Unable to load plugin 'filters'. filters I don't know what kind of plugin it is. | 09:29 |
| AfC | Sorry, I'll stop venting now. Just been a really frustrating few days. Not really what I was expecting. | 09:29 |
| ronny | how do i add the actual root to a MemoryTree on a fresh branch | 09:30 |
| AfC | jnz_: does the command | 09:31 |
| AfC | $ bzr plugins | 09:31 |
| AfC | jnz_: give you sane looking output? | 09:31 |
| ronny | here is some random stuff i tried, im a bit puzzled http://paste.pocoo.org/show/141082/ | 09:31 |
| jnz_ | yes AfC, but I don't see filters | 09:32 |
| ronny | bzr is v2.0rc2 | 09:33 |
| lifeless | jnz_: run the failing command with -Derror | 09:33 |
| lifeless | jnz_: that will give a backtrace | 09:33 |
| lifeless | ronny: look in the bzr test suite for MemoryTree, you can see example usage | 09:33 |
| lifeless | ronny: note that when you drop the lock on a MemoryTree it resets to no-changes | 09:34 |
| lifeless | AfC: well, to be fair we haven't hit Beta yet. its a shame its rough though | 09:34 |
| ronny | hmm, now i have to check, why i loose the lock | 09:35 |
| lvh | If I use a different repo format than the launchpad mirror, pulls will b ereally slow, right? | 09:36 |
| lvh | eh, I mean branch (someone is trying to get a copy of an existing branch on lp) | 09:36 |
| ronny | lifeless: thnaks for the hint with the lock, didnt think that one would have an issue | 09:36 |
| lvh | (basically he wants git clone) | 09:36 |
| lifeless | lvh: if the format is different, some degree of transformation will be needed | 09:37 |
| lifeless | lvh: just doing 'bzr branch lp:foo /tmp/foo' will preserve the format | 09:37 |
| jnz_ | the command is ok, then the problem is the bzr plugin for eclipse | 09:37 |
| lvh | lifeless: yeah, but hes' going to make a lot of branches off of that, so I started with bzr init-repo | 09:37 |
| lvh | lifeless: not sure if that changes anything | 09:38 |
| lifeless | if the thing you're branching from isn't in the default format, init-repo would have a different format | 09:39 |
| lvh | right | 09:39 |
| lvh | would you notice that in the form of ridiculously slow bzr branching? (eg, 10kb/s while 'Finding revisions') | 09:39 |
| lvh | i thought that transformation happened afterwards | 09:40 |
| lvh | current repo format: Packs 6 rich-root (uses btree indexes, requires bzr 1.9) | 09:40 |
| AfC | lifeless: _really_? I thought alpha [that you warned me away from] was only the first month / six. Damn. My mistake. I really should have been running Intrepid after all. | 09:40 |
| lvh | I'm not entirely sure about what he's using, but if I use bzr init-repo I get 2a | 09:41 |
| lifeless | lvh: right, and yes | 09:41 |
| jkakar | lifeless: Woot, it's ready: https://code.edge.launchpad.net/~jkakar/bzr/custom-project-name/+merge/12267 | 09:41 |
| jkakar | And now it's time for bed. G'night and thanks for the help! | 09:41 |
| lifeless | gnight | 09:42 |
| lvh | lifeless: so I should tell him to get rid of the current repo dir, and just use bzr init-repo --1.6.1-rich-root twisted | 09:42 |
| lvh | jkakar: bye :-) | 09:42 |
| lvh | err, --1.9-rich-root | 09:42 |
| lifeless | lvh: yes | 09:43 |
| lifeless | or be very very patient | 09:43 |
| AfC | lvh: you kinda want to avoid cross format all the time. It's really ok to use one or the other [assuming you're not in a corner case that the newer format (and the code that leverages it) requires]; if you use an older one then all upgrade in concert you'll be ok | 09:43 |
| lifeless | lvh: I believe the twisted wiki page documents this already | 09:43 |
| lvh | lifeless: ah, yeah, I should probably link him to that | 09:43 |
| lvh | lifeless: Thanks! | 09:43 |
| jml | jkakar, I like your new patch. | 09:48 |
| jml | (I have a few questions, but sadly bzr patch code review has to wait on days that Launchpad is releasintg) | 09:48 |
| lifeless | jml: btw, you can trim -some- content out in mail replies ;) | 10:19 |
| === doko_ is now known as doko | ||
| === cprov-afk is now known as cprov | ||
| ronny | hmm | 12:20 |
| ronny | lifeless: is there any other stupid thing one could do to get that exception | 12:20 |
| ronny | (im pretty convinced i keep the lock) | 12:21 |
| === mrevell is now known as mrevell-lunch | ||
| ronny | lifeless: here is my session: http://paste.pocoo.org/show/141106/ | 12:39 |
| lifeless | ronny: you haven't made the directories | 12:51 |
| lifeless | ronny: I'm not sure if you can on MemoryTree; as previously discussed its a test double, its not 'complete' | 12:52 |
| fullermd | lifeless: You pung? | 12:53 |
| lifeless | fullermd: yah; thinking I might tap you for a few BSD packages | 12:56 |
| lifeless | testtools, junitxml & subunit | 12:56 |
| ronny | hmm, appearantly it has mldir | 12:56 |
| ronny | eh mkdir | 12:56 |
| ronny | lifeless: all that path2id/id2path stuff is pretty frustrating | 12:56 |
| lifeless | ronny: all what stuff; you should only rarely need to call it | 12:59 |
| ronny | lifeless: well, i need it for setting file contents for example | 12:59 |
| lifeless | its late here and I'm not really up for an API discussion right now, but perhaps you could mail the list? | 13:00 |
| fullermd | Mmm. Possible I guess, but not with any alacrity. | 13:01 |
| lifeless | fullermd: I'll drop you a mail | 13:01 |
| fullermd | I'm leery of setting myself up as maintainer for something I don't myself use and understand. | 13:01 |
| lifeless | fullermd: fair enough; I just want to bootstrap stuff for drizzle:) | 13:01 |
| nevans | Q: Is there some special shell I could/should use for a user who only has access to a server for bzr? | 13:04 |
| === mrevell-lunch is now known as mrevell | ||
| Kinnison | How do I convert an old *old* subtree-capable tree to the new repo format? | 15:03 |
| Kinnison | Hmm, s'not that old I think | 15:03 |
| Kinnison | Standalone tree (format: pack-0.92-subtree) | 15:03 |
| Lo-lan-do | bzr upgrade --format=2a | 15:03 |
| Kinnison | bzr: ERROR: Cannot convert from format <RepositoryFormatKnitPack3> to format <RepositoryFormat2a>. Does not support nested trees | 15:04 |
| Lo-lan-do | Ah, subtree, sorry. | 15:04 |
| Lo-lan-do | I mixed with rich-root. | 15:04 |
| jelmer | Kinnison: you can't upgrade directly | 15:05 |
| bialix | Kinnison: IIRC, subtree should be possible to convert to rich-root | 15:05 |
| jelmer | Kinnison: But you should be able to pull from a subtree repo into a rich root repo | 15:05 |
| jelmer | Kinnison: so the work around is basically: | 15:05 |
| jelmer | Kinnison: bzr init --2a /tmp/foo; bzr pull -d /tmp/foo /path/to/subtree/branch | 15:05 |
| Kinnison | jelmer: aha, ta | 15:07 |
| jelmer | Kinnison: if you actually have nested trees this may give strange errors | 15:24 |
| jelmer | Kinnison: which is why upgrading is refused at the moment | 15:25 |
| jelmer | Kinnison: we should really just do a check of the contents of the repo and only allow upgrading if there aren't any nested trees | 15:25 |
| Kinnison | It was simply that it was an old svn upgrade i think | 15:30 |
| eagles0513875 | hey guys im having an issue when running the bzr bd command it keeps complaining about my secret key not available | 15:57 |
| eagles0513875 | i uploaded my key to the keyserver.ubuntu.com as well as verified the email and activated so the public key is active | 15:57 |
| eagles0513875 | anyone have any idea :( | 15:59 |
| Kinnison | What is the 'bd' command? | 16:00 |
| james_w | eagles0513875: the name in the changelog doesn't match any UIDs on your GPG key | 16:00 |
| eagles0513875 | ahhhh james_w ok | 16:01 |
| eagles0513875 | Kinnison: builds packages | 16:01 |
| eagles0513875 | thanks james_w | 16:01 |
| james_w | https://wiki.ubuntu.com/UbuntuDevelopment/Uploading#Signing%20the%20package | 16:01 |
| james_w | "The UID must be byte-for-byte identical to the Changed-By value (including the key "comment"), so any changes in the name or email address (even down to whitespace) will cause the match to fail" | 16:02 |
| james_w | see the bit under that for checking this is the case and the ways to fix it | 16:02 |
| eagles0513875 | ahhhhhhh | 16:02 |
| eagles0513875 | ok thanks | 16:02 |
| eagles0513875 | james_w: does that link still apply if im only packaging somethign to test on my local machine | 16:03 |
| james_w | in that case you don't need to sign it | 16:03 |
| james_w | "bzr bd -- -uc -us" | 16:03 |
| eagles0513875 | bzr bd --uc -us | 16:04 |
| * idnar scratches his head | 16:14 | |
| idnar | bzr: ERROR: Cannot commit from a lightweight checkout to a stacked branch. See https://bugs.launchpad.net/bzr/+bug/375013 for details. | 16:15 |
| ubottu | Launchpad bug 375013 in bzr "lightweight checkout commit to a stacked branch does not work" [High,Triaged] | 16:15 |
| idnar | I just read that bug, but I don't understand the part about "lightweight checkout"; as far as I know, I don't have any lightweight checkouts involved here | 16:16 |
| idnar | I guess I'm misunderstanding something about stacking | 16:17 |
| idnar | should I be using a shared repository instead? | 16:17 |
| bialix | idnar: run bzr info -v and you'll see what you actually have | 16:18 |
| idnar | "Standalone tree (format: 1.6)" | 16:19 |
| bialix | I don't understand what is stacked then | 16:20 |
| bialix | idnar: is your tree stacked? | 16:20 |
| idnar | parent branch: /home/mithrandi/code/Fusion/trunk | 16:20 |
| idnar | stacked on: /home/mithrandi/code/Fusion/trunk | 16:20 |
| igc | james_w: will you get a chance to look at bug 425507 before karmic beta freeze? | 16:21 |
| ubottu | Launchpad bug 425507 in bzr-explorer "[needs-packaging] bzr-explorer should be packaged in ubuntu and the ppa" [High,Confirmed] https://launchpad.net/bugs/425507 | 16:21 |
| james_w | no, afraid not | 16:22 |
| bialix | idnar: bzr info /home/mithrandi/code/Fusion/trunk | 16:22 |
| Lo-lan-do | I thought bzr-explorer was Windows stuff? | 16:22 |
| idnar | bialix: that's also "Standalone tree (format: 1.6)", not stacked on anything | 16:22 |
| bialix | Lo-lan-do: it was joke? | 16:22 |
| sidnei | igc should have called it bzr-nautilus | 16:22 |
| sidnei | or bzr-navigator | 16:23 |
| igc | james_W: would pitti or someone else be able to tackle it do you think? | 16:23 |
| bialix | or RapidBzr | 16:23 |
| Lo-lan-do | bialix: No, I must have been confused. What was the alternative to TortoiseBzr? | 16:23 |
| bialix | idnar: I'm give up | 16:23 |
| james_w | igc: well, we're well past the time when new packages are normally accepted | 16:23 |
| idnar | I guess I'll try shared repositories instead | 16:23 |
| bialix | Lo-lan-do: bzr-explorer is | 16:23 |
| Lo-lan-do | Oh. But it's portable then, right? | 16:24 |
| james_w | igc: someone may have time, but they will also need a freeze exception | 16:24 |
| bialix | Lo-lan-do: yes, it's Qt-based as QBzr | 16:24 |
| Lo-lan-do | bialix: I see. Thanks. | 16:24 |
| bialix | Lo-lan-do: but bzr-explorer can use bzr-gtk plugin | 16:24 |
| bialix | funny, eh? | 16:25 |
| igc | james_w: I thought poolie's ffe was going to cover explorer as well as bzr core - maybe it didn't | 16:25 |
| igc | Lo-lan-do: see http://doc.bazaar-vcs.org/explorer/en/ | 16:26 |
| igc | time for some sleep | 16:26 |
| igc | night all | 16:26 |
| bialix | igc: night | 16:26 |
| igc | night bialix | 16:27 |
| james_w | igc: https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/430467/comments/4, so it wasn't clear if that was how it was intended to be | 16:27 |
| ubottu | Launchpad bug 430467 in subvertpy "[ffe] please ship bzr 2.0.0 or 2.0.0rc2 in Karmic" [Undecided,Fix released] | 16:27 |
| james_w | night igc | 16:27 |
| === TheLyle is now known as IslandUsurper | ||
| === deryck is now known as deryck[lunch] | ||
| jkakar | jml: Cool. I'll be happy to try and answer whatever questions you have. | 17:30 |
| === mrevell is now known as mrevell-dinner | ||
| === deryck[lunch] is now known as deryck | ||
| magcius | What does bzr use for an SSH client on Windows? | 19:24 |
| Lo-lan-do | Paramiko or Putty, I think. | 19:26 |
| magcius | How would I add an ssh key to that in Windows? | 19:27 |
| Peng_ | Looks like bzr can use paramiko, putty, OpenSSH or SSH Corp. SSH. | 19:27 |
| Lo-lan-do | I know Putty can. No idea about Paramiko though. And I don't have a Windows box :-) | 19:28 |
| Peng_ | Whether you can run the latter two on Windows... | 19:28 |
| Peng_ | Paramiko can use either Putty or OpenSSH's keys, IIRC. | 19:28 |
| dsuch | magcius: Use Pageant for that http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html | 19:30 |
| magcius | Peng_, what does Bazaar use in the Windows distribution. | 19:31 |
| Peng_ | I honestly don't know which one is preferred. | 19:33 |
| Peng_ | What matters is which one it's using for *you* anyway. | 19:33 |
| * Peng_ tries to dodge question. | 19:33 | |
| bialix | hello jam | 19:46 |
| jam | hi bialix | 19:46 |
| bialix | may I ask you some questions about reference counting in Python? | 19:46 |
| jam | magcius: We generally use paramiko first, and I recommend using Pageant (from the putty utils) | 19:46 |
| jam | you can use that as an agent, and add your keys there | 19:46 |
| jam | (putty is a decent manual tool, it makes a bad subprocess, so we prefer not to use it for the ssh connection) | 19:47 |
| jam | bialix: sure | 19:47 |
| === mrevell-dinner is now known as mrevell | ||
| === TheLyle_ is now known as IslandUsurper | ||
| meoblast001 | hi | 21:16 |
| meoblast001 | i had a 3 MB ogg and mp3 file in my project's examples at particular points | 21:16 |
| meoblast001 | isn't that bad for people who are checking out my project? wouldn't it increase the download time? | 21:16 |
| Peng_ | Yes, but 3 MB isn't all that much. | 21:20 |
| Peng_ | Besides, it's too late to remove it from the history now. | 21:20 |
| meoblast001 | i know :( | 21:20 |
| meoblast001 | i was contemplating rerolling my revisions | 21:21 |
| meoblast001 | Peng_: is a 10MB .bzr directory for a 77 revision project normal? | 21:21 |
| bialix | you can try to use rebase plugin | 21:21 |
| meoblast001 | it's 10.3 MB | 21:21 |
| bialix | 100MB would be much worse | 21:23 |
| meoblast001 | bialix: would the rebase plugin allow me to remove an entire directory from every commit? | 21:23 |
| bialix | mmm, not really | 21:23 |
| bialix | you can replay your revisions | 21:24 |
| bialix | you can delete some revisions | 21:24 |
| meoblast001 | oh | 21:24 |
| meoblast001 | a rerolling script sounds better if i would have to | 21:24 |
| meoblast001 | and what do you mean "100MB would be much worse" | 21:24 |
| bialix | to remove entire directory you can look at fast-import pluign | 21:24 |
| meoblast001 | is 10.3MB bad? | 21:24 |
| bialix | it depends | 21:24 |
| meoblast001 | what does fast-import do | 21:24 |
| bialix | fast-import has filter feature | 21:25 |
| bialix | you can filter out some files or directories | 21:25 |
| meoblast001 | from everything? | 21:25 |
| Peng_ | Just out of curiosity, which repo format are you using? | 21:25 |
| meoblast001 | 1.x | 21:25 |
| Peng_ | And does the 10.3 MB include junk in .bzr/repository/obsolete_packs and .bzr/repository/upload? | 21:26 |
| bialix | I don't understand your question: "from everything" | 21:26 |
| meoblast001 | obsolete_packs is empty here | 21:26 |
| meoblast001 | so is upload | 21:26 |
| Peng_ | Overall, a 10 MB repo isn't very interesting... Lots of large projects are many times larger. | 21:27 |
| Peng_ | If you don't mind, got an URL? | 21:27 |
| Peng_ | I'm just curious. | 21:27 |
| bialix | 10MB usually means you have a lot of files, or several big files inside | 21:27 |
| bialix | for 77 revisions | 21:27 |
| meoblast001 | https://launchpad.net/amethyst-mm | 21:27 |
| meoblast001 | i want the examples to be gone pretty much, they are quite unnecessary | 21:28 |
| meoblast001 | well, at least the ogg and mp3 file that i had | 21:28 |
| Peng_ | I could go either way. 10 MB isn't that much data, but the longer you wait, the harder it'll be to recreate the branch... | 21:30 |
| Peng_ | In my case, laziness would probably win out over tidiness. :P | 21:30 |
| ronny | jelmer: what am i supposed to put into dulwichs object_stroe.add_objects(objects) | 21:31 |
| ronny | jelmer: trying a list of git objects, but it wants a list of tuples of path, object | 21:32 |
| meoblast001 | bialix: so, i could use fast-import and basically just tell it to chop these 2 files out off all the history? | 21:36 |
| meoblast001 | and then overwrite the repo in launchpad | 21:36 |
| bialix | you can try, yes | 21:36 |
| Peng_ | Any preexisting repos would keep all of the revisions, actually increasing their size. :D | 21:36 |
| meoblast001 | i can try meaning i would have to hack around and try to get it to do something it's not meant to do? | 21:36 |
| bialix | after fast-import processed your branch all old branches will be totally incompatible with new one | 21:37 |
| meoblast001 | what do you mean old branches? | 21:37 |
| meoblast001 | we only have 1 branch | 21:37 |
| Peng_ | All copies of it. | 21:38 |
| meoblast001 | oh, yes, that shouldn't be a big deal | 21:38 |
| meoblast001 | only like 3 people actually have pulled a copy of my project :P | 21:38 |
| bialix | meoblast001: you have big files in revno 8 and 71 | 21:39 |
| bialix | maybe you need relax and live with them | 21:39 |
| meoblast001 | i do? | 21:39 |
| meoblast001 | what are those big files? | 21:40 |
| bialix | your mp3 and ogg | 21:40 |
| meoblast001 | exactly | 21:40 |
| bialix | mp3 committed in revno 8, then deleted in 71 and replaced with ogg | 21:40 |
| bialix | rebase will rewrite entire history post revno 7 | 21:41 |
| meoblast001 | yup, i want to chop both of those out completely, sure, it would break the examples, but it's not necessary we have those files | 21:41 |
| bialix | so almost everything | 21:41 |
| meoblast001 | that would be bad, right? | 21:41 |
| bialix | it depends | 21:41 |
| bialix | fast-import will rewrite entire history | 21:41 |
| bialix | rebase nost of history | 21:41 |
| bialix | rebase most of history | 21:41 |
| meoblast001 | hm | 21:42 |
| bialix | fast-import will be simpler | 21:42 |
| meoblast001 | i know someone who wrote a bzr to git script | 21:42 |
| meoblast001 | maybe i could use that? | 21:42 |
| bialix | rebase will require manual work | 21:42 |
| meoblast001 | bzr to bzr | 21:43 |
| bialix | you can | 21:43 |
| bialix | git has filter feature | 21:43 |
| bialix | to convert form bzr to git you anyway needs fast-import ;-) | 21:43 |
| meoblast001 | well, this would be bzr to bzr minus a few files | 21:44 |
| bialix | converion bzr->git->bzr will destroy your history identity as well | 21:44 |
| meoblast001 | no | 21:44 |
| meoblast001 | not bzr->git->bzr | 21:44 |
| meoblast001 | just bzr->bzr_minus_some_files | 21:44 |
| bialix | fast-import is bzr->anything | 21:44 |
| meoblast001 | rewriting everything but removing specific files | 21:44 |
| bialix | yep | 21:45 |
| meoblast001 | fast-import can do that? | 21:45 |
| bialix | fast-import is yhe answer | 21:45 |
| bialix | fast-import is the answer | 21:45 |
| bialix | install this plugin and read its docs, there is examples | 21:45 |
| meoblast001 | ok | 21:45 |
| meoblast001 | if i need help i'll ask you :P | 21:45 |
| meoblast001 | but first i will read the docs | 21:46 |
| bialix | if you catch me ;-P | 21:46 |
| bialix | time to sleep for me | 21:46 |
| meoblast001 | oh, good night | 21:46 |
| === TheLyle is now known as IslandUsurper | ||
| meoblast001 | "bzr fast-import clean.fi clean.bzr" | 21:54 |
| meoblast001 | what is ".bzr" and ".fi" | 21:55 |
| bialix | fi is fast-import stream | 21:55 |
| meoblast001 | hm, is it a directory? | 21:56 |
| bialix | no, fi it's the file | 21:56 |
| meoblast001 | should i just use this "bzr fast-import-filter -x missile-codes.txt > clean.fi" | 21:56 |
| meoblast001 | i don't know what "the file" is | 21:56 |
| meoblast001 | the file i want removed? | 21:57 |
| bialix | fast-export command produce stream of your history in special format | 21:57 |
| bialix | format called git-fast-import | 21:57 |
| bialix | hence fi -- it's the stream saved on the disk | 21:57 |
| bialix | fi = fast-import | 21:58 |
| meoblast001 | that doesn't sound good | 21:58 |
| meoblast001 | i just want it to remove the stuff from my bazaar repository | 21:58 |
| bialix | you can use | | 21:58 |
| meoblast001 | |? | 21:58 |
| bialix | bzr fast-export YOURBRANCH | bzr fast-import-filter -x mp3 | bzr fast-import NEWBRANCH | 21:58 |
| bialix | something like that | 21:59 |
| bialix | pipes? | 21:59 |
| meoblast001 | if i want the MP3 and the OGG out, do i just add a second "bzr fast-import-filter -x ogg? | 21:59 |
| meoblast001 | and "yourbranch" would be ./ if i'm cd'd into it? | 22:00 |
| meoblast001 | and newbranch would be the new directory? | 22:00 |
| bialix | no, you can combine several -x options | 22:02 |
| meoblast001 | can i do *.mp3 and *.ogg? | 22:02 |
| bialix | I don't remember exact details about NEWBRANCH | 22:02 |
| bialix | meoblast001: I dunno | 22:02 |
| bialix | try | 22:03 |
| bialix | save the stream of original history to orig.fi file | 22:03 |
| bialix | and then filter it | 22:03 |
| meoblast001 | i don't know where the ".fi" file is | 22:03 |
| bialix | the size of this file will be hundred of MBs but it's all locally | 22:03 |
| meoblast001 | where is the file at? | 22:04 |
| bialix | bzr fst-export YOURBRANCH > somefile.fi | 22:05 |
| bialix | bzr fst-export YOURBRANCH > othernameyouwouldlike.xxx | 22:05 |
| bialix | anything will work | 22:05 |
| bialix | I mean "fast-export" above | 22:06 |
| meoblast001 | why am i importing the new branch | 22:06 |
| meoblast001 | and exporting the current branch? | 22:06 |
| bialix | you export current branch, filter it and thus get new stream, then convert the stream to the branch | 22:07 |
| bialix | fast-import working in the terms of "history stream" | 22:08 |
| meoblast001 | woah woah woah | 22:09 |
| meoblast001 | this is going to remove revisions with these files? | 22:09 |
| bialix | no, filter out files from revisions | 22:10 |
| meoblast001 | ok | 22:10 |
| meoblast001 | the last part is giving me bzr: ERROR: [Errno 2] No such file or directory: u'new.fi' | 22:10 |
| bialix | "woah"? | 22:10 |
| meoblast001 | i thought it was going to remove any revision that had to deal with that file | 22:11 |
| bialix | what is the last part? | 22:11 |
| meoblast001 | bzr fast-import new.fi | 22:11 |
| bialix | do you have new.fi file? | 22:12 |
| meoblast001 | no | 22:12 |
| bialix | hence error | 22:12 |
| meoblast001 | should i just do bzr fast-export YOURBRANCH | bzr fast-import-filter -x mp3 > file.fi? | 22:13 |
| bialix | fast-import read the stream and re-create the branch | 22:13 |
| bialix | yep | 22:13 |
| meoblast001 | bzr: broken pipe | 22:13 |
| bialix | bzr fast-export YOURBRANCH > orig.fi | 22:14 |
| meoblast001 | why ? | 22:14 |
| bialix | bzr fast-import-filter orig.fi -x mps > new.fi | 22:14 |
| meoblast001 | oh, ok | 22:14 |
| bialix | I dunno why, are you on windows? | 22:14 |
| meoblast001 | no | 22:14 |
| bialix | I dunno twice | 22:14 |
| bialix | ah | 22:15 |
| bialix | ahbzr fast-export YOURBRANCH | bzr fast-import-filter - -x mp3 > file.fi | 22:15 |
| meoblast001 | >.< it's printing to console | 22:15 |
| bialix | you'd better look at examples for filter command | 22:15 |
| meoblast001 | i forgot to output it to a file >.< | 22:16 |
| jelmer | ronny: for blobs and trees that should be the path they have but it may also be None. It's used for finding optimal delta bases | 22:16 |
| ronny | jelmer: ah, i see | 22:17 |
| jelmer | ronny: you can without problems just use None as path everywhere | 22:17 |
| ronny | jelmer: i kind of did that (using '' as path) | 22:17 |
| meoblast001 | bialix: how do i reexport this to a directory? | 22:17 |
| ronny | jelmer: im currently extending anyvc commit building to more complex cases | 22:17 |
| bialix | reexport? | 22:17 |
| bialix | run fastexport again | 22:18 |
| RenatoSilva | Why do I get this error? http://pastie.org/628005 | 22:18 |
| RenatoSilva | Is it bzr 1.18.1 bug? | 22:18 |
| RenatoSilva | Or is it because of this line: email C:\Arquivos de Programas\Bazaar\plugins\email [unknown] | 22:19 |
| bialix | look at branch.conf | 22:19 |
| RenatoSilva | I've committed two merges from personal bzr-email branches | 22:19 |
| meoblast001 | i'll take a look at it more later, thank you | 22:19 |
| meoblast001 | i've gtg | 22:19 |
| bialix | RenatoSilva: try bzr --no-plugins info | 22:20 |
| meoblast001 | bye | 22:20 |
| bialix | RenatoSilva: it seems you have wrong characters in branch.conf, have no idea why. Maybe disk failure? | 22:21 |
| === Toksyury1l is now known as Toksyuryel | ||
| * bialix disappears | 22:22 | |
| RenatoSilva | bialix: oh, it's the "Olá", non-ascii is not supported there :( | 22:26 |
| zsquareplusc | RenatoSilva: the error was with utf8. so i'd think its more than asci. but maybe the file was saved with the wrong encoding. did you edit it? | 22:27 |
| RenatoSilva | zsquareplusc: ok let me try Olá as utf-8, probably it was the encoding really | 22:28 |
| rbelem | hello all, is there an way to delete an old revision? like my current revision is 756 and the revision that i want to remove is 746. | 22:30 |
| zsquareplusc | rbelem: what do you expect to happen? edit the history? | 22:30 |
| zsquareplusc | if you just want to "unapply" the changes of that revision, that's possible. you'll just end up with a new commit undoing the changes | 22:31 |
| RenatoSilva | zsquareplusc: saved as utf-8 without bom and worked just fine, thanks :) | 22:32 |
| rbelem | zsquareplusc, yes... :-) i want to remove that revision because now see that revision do not make sense | 22:33 |
| RenatoSilva | lifeless: I was trying to understand what you said about rebase breaking pull and merge | 22:33 |
| RenatoSilva | lifeless: you mean branches based on the rebased branch in the past, right? | 22:33 |
| rbelem | zsquareplusc, but with unapply what with earlier revisions? | 22:33 |
| rbelem | * happens | 22:34 |
| RenatoSilva | lifeless: however I wasnt really thinking of rebasing trunk or branches that potentially could be branched | 22:34 |
| zsquareplusc | rbelem: nothing. the old revisions are kept as they are | 22:34 |
| rbelem | zsquareplusc, oh! i got | 22:34 |
| RenatoSilva | lifeless: the branch in question isn't really targeted for being branched, it's a personal branch targeted for merging into trunk | 22:35 |
| rbelem | zsquareplusc, ok... so if i want to make that revision vanish i will have to create another branch and reapply patch by patch? | 22:37 |
| kfogel | LarstiQ: https://code.edge.launchpad.net/~kfogel/bzr-hookless-email/byte-limit/+merge/11233 :-) | 22:37 |
| RenatoSilva | lifeless: I don't think it's a good idea to rebase project branches either, but when your feature branch personal and you know that no one will branch it (you can put a warning in description), well, in this case I think rebase is a good option | 22:38 |
| RenatoSilva_ | lifeless: I don't think it's a good idea to rebase project branches either, but when your feature branch is personal and you know that no one will branch it (you can put a warning in description), well, in this case I think rebase is a good option | 22:39 |
| RenatoSilva_ | RenatoSilva_: another good reason for rebase is that the feature diff becomes clean, only one single diff between revision can tell you how code changes compared to trunk | 22:40 |
| RenatoSilva_ | lifeless: ^ | 22:40 |
| RenatoSilva_ | lifeless: using updating merges it may be a bit hard as trunk may have changed since your work | 22:41 |
| zsquareplusc | rbelem: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#reverse-cherrypicking | 22:41 |
| lifeless | RenatoSilva_: bzr diff -r ancestor:../trunk - will tell you whats different in the branch easily as well | 22:42 |
| jelmer | ronny: cool | 22:46 |
| zsquareplusc | are the devs working on TortoiseBZR here? | 22:47 |
| rbelem | zsquareplusc, i will test here | 22:49 |
| rbelem | thanks :-) | 22:49 |
| ronny | jelmer: with some luck i'll have a nice api for building and introspecting usefull commits on all important vcs's at the end of the week | 22:49 |
| RenatoSilva | lifeless: sorry, being disconencted all the time | 22:49 |
| RenatoSilva | lifeless: bzr diff -r ancestor:../trunk -, including the '-'? | 22:50 |
| RenatoSilva | lifeless: well in my example here http://img33.yfrog.com/img33/5295/imagemxa.png, rev. 18 in the former is rev.23 in the latter | 22:51 |
| RenatoSilva | lifeless: I just have to diff -r 22..23 and I'll have the changes according to the latest code | 22:51 |
| RenatoSilva | lifeless: for the former the same diff -r 17..18 is --outdated-- | 22:52 |
| RenatoSilva | lifeless: I'll have to go through the brach and look at all merges from trunk till the end, to get a view on the updated change | 22:53 |
| RenatoSilva | lifeless: by elimitating update-only merges, I make the feature diff more natural | 22:53 |
| RenatoSilva | lifeless: unfortunately I don't have the diffs now but in that example what happened was that... | 22:54 |
| RenatoSilva | lifeless: I had pt-br_solenoid.Theme.po in branch root, then I created the feature branch and modified this file | 22:55 |
| RenatoSilva | lifeless: in the meantime, the file was moved in trunk to a subfolder /translation, and was renamed to pt_BR.po | 22:55 |
| RenatoSilva | lifeless: using update merges, the rev that implements the feature is now outdated because it relates to old /pt-br_solenoid.Theme.po | 22:56 |
| johnf | abentley: you about? | 22:58 |
| RenatoSilva | lifeless: that diff is not enougth to know how the feature changes the code, you have to also look at the specific merge feature --> trunk where the conflict occurs and is solved | 22:58 |
| lifeless | RenatoSilva: that why you use 'diff -r ancestor:../trunk', not 'dff -r 17..18' | 22:58 |
| Peng_ | RenatoSilva: Just out of curiosity, what's up with your connection? | 22:58 |
| mwhudson | hmm | 22:58 |
| mwhudson | bzr log -r $revno:$branch | 22:59 |
| mwhudson | shows $revno in the context of $branch in the output | 22:59 |
| mwhudson | not $revno in the context of . | 22:59 |
| RenatoSilva | lifeless: (i.e pt-br_solenoid.Theme.THIS and pt-br_solenoid.Theme.BASE, then you move THIS to /translations/pt_BR.po and bzr resolve --all and merge) | 22:59 |
| mwhudson | that wasn't what i was expecting | 22:59 |
| RenatoSilva | lifeless: sorry I will read your answer now | 22:59 |
| RenatoSilva | Peng_: I don't know what's up with my conn :9 | 23:00 |
| RenatoSilva | lifeless: literally as you typed? is it possible in ui? | 23:01 |
| RenatoSilva | lifeless: I'll try diff -r ancestor:../trunk at home anyway | 23:02 |
| RenatoSilva | mwhudson: so bzr log -r $revno:$branch? how would that be in my example? | 23:04 |
| lifeless | RenatoSilva: mwhudson is talking about something completely different | 23:05 |
| RenatoSilva | ok sorry then | 23:05 |
| mwhudson | RenatoSilva: yeah, sorry for dropping in with something that looked similar but is in fact entirely different | 23:05 |
| RenatoSilva | lifeless: diff -r ancestor:../trunk, s/ancestion/feature-branch's name, right? | 23:06 |
| lifeless | s/..\/trunk/path_to_trunk | 23:06 |
| RenatoSilva | lifeless: I'm sorry can't grok that command atm | 23:06 |
| lifeless | cd $feature_branch | 23:06 |
| lifeless | bzr diff -r ancestor:$trunk_url | 23:06 |
| RenatoSilva | lifeless: trunk is lp:moin-solenoid | 23:06 |
| RenatoSilva | lifeless: and feature branch is ~/moin-solenoid/userprefs | 23:07 |
| RenatoSilva | lifeless: so bzr branch [...]userprefs, cd userprefs, bzr diff -r ancestor:lp:moin-solenoid right | 23:08 |
| lifeless | yes | 23:09 |
| RenatoSilva | ok | 23:09 |
| RenatoSilva | lifeless: I'll check later if I'll get the same diff as with rebase, thanks! | 23:11 |
| RenatoSilva | is .bzr's branch.conf pushed to lp too? | 23:27 |
| RenatoSilva | I'm worried about some bzr-email confs I don't want to share | 23:27 |
| zsquareplusc | the one in your home direcotry, not | 23:27 |
| zsquareplusc | you can have a branch specific config in the .bzr folder i guess that one is pushed | 23:28 |
| fullermd | No, it's not. | 23:28 |
| zsquareplusc | ok | 23:29 |
| RenatoSilva | ok thanks! | 23:29 |
| milli | Here's a potentially stupid and probably inflammatory question that Google hasn't been able to help me with... I have a Client (customer) that has decided to move to bzr for source control from git (long story omitted about git's UI being "too hard" to use). What repository format will get me closest to the performance of git? --2a? --1.9-rich-root ? --1.14-rich-root? I.e., what is the fastest repo format given half a dozen developers using a semi-de | 23:29 |
| milli | centralized approach with some folks using a sandbox (git-like) workflow and others using a subversion-like workflow? | 23:29 |
| zsquareplusc | what's the point of holding in in the braches .bzr directory then? | 23:29 |
| thumper | milli: 2a | 23:30 |
| fullermd | milli: What thumper said, assuming everyone's on a new enough (2.0.0 ideally, 1.18 OK) version. | 23:30 |
| milli | thumper: that's it? Hands down it's the fastest? No caveats? | 23:30 |
| fullermd | 2a is supported since 1.16 (I think offhand), but it's a little rough early on. | 23:31 |
| thumper | milli: I'd say yes | 23:31 |
| milli | I saw the 2.0.0 just hit Karmic... | 23:31 |
| milli | that | 23:31 |
| milli | ok | 23:31 |
| RenatoSilva | Ursinha: ^ | 23:34 |
| lifeless | milli: 2a fixes a number of big-O scaling problems with older formats. Its got lets; we know of a handful of minor regressions, and they won't require format changes to fix. | 23:36 |
| lifeless | milli: with bzr 2.0.0 you should have fine performance; if you don't _please_ file a bug and we can figure out why | 23:36 |
| milli | lifeless: nod | 23:37 |
| lifeless | s/lets/legs/ | 23:37 |
| poolie | hi there | 23:44 |
| lifeless | hai | 23:49 |
| poolie | lifeless: i put up the uifactory tests | 23:50 |
| poolie | for review | 23:50 |
| poolie | however lp is readonly atm | 23:50 |
| lifeless | yah | 23:50 |
| * fullermd read that as "olfactory tests"... | 23:53 | |
| poolie | mm | 23:54 |
| poolie | i'd like to do some import tariff tests soon :) | 23:54 |
| poolie | blah | 23:55 |
| poolie | i guess it's better than being offline entirely | 23:55 |
| fullermd | I figured that meant "tests to tell you if your code stinks". | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
