| spiv | It will run pre_change_branch_tip and post_change_branch_tip hooks if used by a 1.6 client. | 00:00 |
|---|---|---|
| spiv | pre_change_branch_tip is probably what you'd want to use to replace a pre-commit hook from SVN, I think. | 00:00 |
| spiv | I haven't quite landed the change to make it possible for pre_change_branch_tip to reject a change cleanly, but I ought to have that done this morning. | 00:01 |
| awmcclain | jelmer: Ah yes! This is the problem. The requirements for the bzr-svn ubuntu package are broken: bzr-svn: Depends: bzr (< 0.91~) but 1.4rc1-1~bazaar1~feisty1 is to be installed | 00:02 |
| jelmer | awmcclain, bzr-svn isn't maintained in the ppa at the moment | 00:02 |
| awmcclain | :( | 00:02 |
| igc | morning | 00:02 |
| jelmer | it hopefully will starting 1.6 if I can get autoppa working | 00:02 |
| awmcclain | jelmer: ooo, autoppa | 00:02 |
| awmcclain | jelmer: I like the sound of that | 00:02 |
| jelmer | 'morning Ian, Andrew, Martin | 00:02 |
| awmcclain | jelmer: What's the best way of installing? | 00:03 |
| jelmer | awmcclain, You should be able to grab the package from Debian sid | 00:03 |
| awmcclain | for ubuntu? what's the sources entry? | 00:03 |
| jelmer | awmcclain, You should be able to download it manually from the intrepid repo | 00:04 |
| awmcclain | jelmer: 0.4.10? Will that work? | 00:04 |
| jelmer | yeah, it should. I think the dependencies are all available from either the ppa or hardy | 00:05 |
| awmcclain | Ok, so I'll install the dependency packages from the ppa | 00:05 |
| mathiaz | Hi - is it possible to set the submit_to option on a bzr branch so that people branching don't have to specify the email address when using the bzr send command ? | 00:11 |
| awmcclain | jelmer: Great. Works. Thank you! | 00:12 |
| jelmer | mathiaz, yes - it's called child_submit_to | 00:13 |
| mathiaz | jelmer: well - I'd like to set in the public branch so that contributors don't have to do it themselves. | 00:16 |
| jelmer | mathiaz, yes, that's exactly what child_submit_to is | 00:16 |
| mathiaz | jelmer: gotcha - and how do I do that ? | 00:16 |
| jelmer | submit_to is retrieved from the local branch | 00:17 |
| jelmer | child_submit_to is retrieved from the submit branch | 00:17 |
| jelmer | mathiaz, set child_submit_to in the .bzr/branch/branch.conf of the main branch | 00:17 |
| mathiaz | jelmer: great - thanks :) | 00:18 |
| igc | fullermd, Peng_: fastimport does have some limited support for incremental mirroring | 00:18 |
| mathiaz | jelmer: but that will be pushed to the public location of the branch ? | 00:18 |
| mwhudson | igc: oh yes, i want to talk to you about that at some point :) | 00:18 |
| jelmer | mathiaz: how do you mean? | 00:19 |
| jelmer | mathiaz, you need to set that option in the submit branch (e.g. the one you specify as first argument to "bzr send") | 00:19 |
| fullermd | igc: Yeah, jam set me straight. Sorry for spouting bs. | 00:19 |
| mathiaz | jelmer: I'd like to setup ubuntu-doc@lists.ubuntu.com as the email address to be used to send patches for the ubuntu documentation (which is hosted in lp:ubuntu-doc) | 00:19 |
| jelmer | mathiaz: launchpad doesn't make this very easy | 00:20 |
| jelmer | you need to edit the .bzr/branch/branch.conf on launchpad to contain "child_submit_to = ubuntu-doc@lists.ubuntu.com" | 00:20 |
| mathiaz | jelmer: right - that's what I thought - I'll check with the LP guys. | 00:20 |
| jelmer | mathiaz, I think you should be able to create it locally and then upload using sftp | 00:21 |
| jelmer | at least that's what I did for bzr-gtk | 00:21 |
| spiv | gedit will probably work with an SFTP url... :) | 00:21 |
| poolie | igc: i think deprecating both those two apis, get_tar_file and put_on_disk would be good | 01:26 |
| poolie | they're very anachronistic there | 01:26 |
| igc | poolie: yeah, they feel out of place | 01:27 |
| poolie | there may even be others that should also go | 01:35 |
| === herb__ is now known as herb | ||
| mwhudson | spiv: prompted by #twisted.web | 01:49 |
| mwhudson | mwh@grond:bzr.dev$ PYTHONPATH=/home/mwh/src/pyflakes/support-lazy-imports /home/mwh/src/pyflakes/support-lazy-imports/bin/pyflakes bzrlib/ | grep -v 'could be lazy' | wc -l | 01:49 |
| mwhudson | 1239 | 01:49 |
| spiv | mwhudson: btw, the supports-lazy-imports branch seems to give duplicate warnings sometimes. | 01:50 |
| mwhudson | spiv: oh, hm | 01:50 |
| mwhudson | i know the version in hardy does | 01:51 |
| spiv | Hmm, I'm fairly sure I'm using supports-lazy-imports | 01:51 |
| spiv | (the current tip) | 01:51 |
| spiv | It's possible that I sometimes run from vim and thus side-step my bash aliases, though. | 01:52 |
| mwhudson | spiv: in running it over bzrlib, four lazy imports used at module level come out twice | 01:55 |
| mwhudson | that's all | 01:55 |
| mwhudson | unless my unix pipeline foo is lacking | 01:55 |
| spiv | mwhudson: Interesting. I guess I'll pay more attention and file an actual bug report next time :) | 01:56 |
| spiv | The "problem" is that it doesn't stop the tool being usefl :) | 01:56 |
| mwhudson | heh, 89 flakes in bzrlib/tests/test_lazy_import.py | 01:58 |
| mwhudson | bet most of those are false positive | 01:58 |
| mwhudson | spiv: the import could be lazy one is probably a mistake | 01:58 |
| mwhudson | it should at least be optional, or only spat out in files that already have lazy imports | 01:58 |
| mwhudson | ah, that cuts out 2500 flakes | 02:02 |
| spiv | Yeah, by default I wouldn't want to see those warnings for a file that doesn't use lazy imports. | 02:03 |
| * mwhudson pushes that | 02:03 | |
| spiv | mwhudson: also, I wouldn't mind a way of whitelisting certain modules as ok to not lazy import. | 02:15 |
| spiv | mwhudson: e.g. I don't really care if sys "could be lazy". | 02:15 |
| mwhudson | spiv: you do know how much support pyflakes has for configuration, right? | 02:15 |
| spiv | Happily, no :) | 02:15 |
| mwhudson | "none at all" | 02:16 |
| spiv | No wonder I was so happy :) | 02:16 |
| mwhudson | it doesn't even take options | 02:16 |
| mwhudson | mwh@grond:support-lazy-imports$ pyflakes --help | 02:16 |
| mwhudson | Traceback (most recent call last): | 02:16 |
| mwhudson | File "/usr/bin/pyflakes", line 70, in <module> | 02:16 |
| mwhudson | main(sys.argv[1:]) | 02:16 |
| mwhudson | File "/usr/bin/pyflakes", line 63, in main | 02:16 |
| mwhudson | warnings += checkPath(arg) | 02:16 |
| mwhudson | TypeError: unsupported operand type(s) for +=: 'int' and 'NoneType' | 02:16 |
| mwhudson | :) | 02:16 |
| spiv | Just Works is awesome. | 02:16 |
| mwhudson | i guess 'sys' can be whitelisted in pyflakes itself, mind | 02:17 |
| lifeless | what is 'could be lazy' for? | 02:18 |
| spiv | lifeless: an import that isn't used by any code run at import time, and thus can possibly by productively changed to a lazy_import | 02:20 |
| spiv | s/by/be/ | 02:21 |
| lifeless | spiv: I'm currently looking at whether we can remove lazy_import completely :) | 02:21 |
| spiv | lifeless: given that we use it to dodge circular import issues, probably not without some effort beyond just optimisation : | 02:21 |
| spiv | :) | 02:21 |
| mwhudson | ah yes, like bzr --no-plugins merge exploding? | 02:28 |
| lifeless | spiv: keeping it for that might be ok, but actually I hit those regularly even with it | 02:29 |
| spiv | lifeless: *nod* | 02:32 |
| lifeless | however, its breaks freeze,py2exe,cxfreeze,pyflakes, pydoctor etc | 02:33 |
| lifeless | it doesn't make the general case faster (because code that is needed is still loaded) | 02:33 |
| spiv | It doesn't break pyflakes if you use mwhudson's branch :) | 02:35 |
| jam | lifeless: we actually do have quite a bit of ancillary imports that don't always get loaded | 02:37 |
| jam | like importing gpg.py | 02:37 |
| jam | which imports subprocess | 02:37 |
| jam | but is only used if you actually sign a commit | 02:37 |
| jam | We could make that lazy in other ways | 02:38 |
| jam | like by importing them in the function that uses them | 02:38 |
| jam | we just have to be careful that those aren't in inner loops | 02:38 |
| fbond | jam: Remember that issue that you debugged on my server (AssertionError: 442 != 443). What do I have to do to work-around it? | 02:47 |
| fbond | Is upgrading bzr on the remote server the only option? | 02:47 |
| fbond | I guess I can use sftp, too...? | 02:47 |
| lifeless | fbond: I thought it was a client bug | 02:54 |
| jam | lifeless, fbond: I think you can upgrade the branch format | 02:54 |
| jam | lifeless: I think it is caused because he is using Branch5 format branches | 02:55 |
| jam | and the server is re-generating the history | 02:55 |
| jam | but there is a ghost | 02:55 |
| jam | or something along those lines | 02:55 |
| fbond | jam: sounds familiar. | 02:57 |
| fbond | bzr upgrade on the client will fix things? | 02:57 |
| fbond | The server? | 02:57 |
| jam | bzr upgrade on the server | 02:57 |
| fbond | jam: great, thanks! | 02:57 |
| arjenAU | so how is the stacked branch stuff coming along? | 03:01 |
| jam | lifeless: looking at groupcompress... you start off with 'self.lines = []', do you only add things via "compress" ? | 03:05 |
| lifeless | jam: yes | 03:05 |
| jam | I'm just wondering why you didn't special case the first compress() | 03:05 |
| jam | since you know there are 0 matches | 03:05 |
| jam | or would you actually match against text you have already output | 03:06 |
| jam | I think you actually *do* self compress texts | 03:06 |
| jam | because output_lines() updates the line_locations | 03:06 |
| jam | ah, but you don't do output_lines until you are done | 03:07 |
| jam | so anyway, it seems like you could trivially say | 03:07 |
| jam | if len(self.lines) == 0: | 03:07 |
| jam | self.output_lines(lines, [True]*len(lines)) | 03:07 |
| jam | return | 03:07 |
| lifeless | jam: it doesn't seem worth special casing | 03:08 |
| lifeless | jam: as we generally get thousands of texts in a group | 03:08 |
| jam | lifeless: well, for a 10,000 line text you skip a fairly long loop | 03:08 |
| jam | I suppose | 03:08 |
| jam | lifeless: how did you benchmark it? | 03:09 |
| jam | I didn't see any direct functions here | 03:09 |
| jam | and I have some work done for a python version of the hashtable | 03:09 |
| jam | and thinking to extend that to a pyrex one | 03:09 |
| jam | though customized for what groupcompress actually needs | 03:09 |
| lifeless | well I didn't benchmark special-cashing not-special casing | 03:09 |
| jam | lifeless: no, I just mean *I* want to benchmark here | 03:10 |
| jam | and am looking for pointers | 03:10 |
| lifeless | oh | 03:10 |
| lifeless | jam: mailed you my hacked-up scripts | 03:14 |
| jam | lifeless: thanks | 03:14 |
| lifeless | with the ability to do 'bzr branch' I'm benchmarking branching operations nowadays | 03:15 |
| lifeless | get_matching_blocks is 23% of a branch of gc itself | 03:17 |
| lifeless | flush_range 10% | 03:17 |
| lifeless | and output_lines 8% | 03:17 |
| jam | stupid special keys with compize | 03:20 |
| jam | I don't know what they are and keep accidentally triggering them | 03:20 |
| jam | I just resized my screen | 03:20 |
| jam | "zoom" | 03:20 |
| jam | only I can't pan | 03:20 |
| lifeless | :P | 03:21 |
| lifeless | I run metacity | 03:21 |
| jam | brb | 03:23 |
| jam | It seems I'm hitting everything today | 03:26 |
| jam | since when does Ctrl+Alt+Backspace reboot your machine instead of just killing X? | 03:26 |
| lifeless | rotfl | 03:26 |
| jam | I might have hit it 2x, and maybe at exactly the wrong time? | 03:26 |
| * igc lunch & doctor visit | 03:27 | |
| jam | igc: eat hardy, and feel well | 03:29 |
| lifeless | jam: meh, should have shelved setup.py; pushed a new rev | 03:41 |
| jam | lifeless: not a big deal, I already converged it with my setup.py :) | 03:41 |
| jam | which did ~ the same thing :) | 03:41 |
| lifeless | oh cool | 03:41 |
| lifeless | so I have get_matching_lines up to 33% | 03:42 |
| jam | get_matching_blocks ? | 03:42 |
| lifeless | yes | 03:42 |
| lifeless | jam: what are you working on, I don't want to overlap too much | 03:45 |
| jam | lifeless: well, *right now* trying to get 'bzr branch' to actually work for me :) | 03:46 |
| lifeless | ~/source/baz/btree-graphindex/bzr init-repo --gc-plain --no-trees gc | 03:46 |
| lifeless | time ~/source/baz/btree-graphindex/bzr branch ~/source/baz/plugins/index2/trunk/ gc/t | 03:47 |
| jam | I get the feeling get_matching_blocks is getting stuck in an infinite loop | 03:47 |
| jam | lifeless: do you have a custom bzr as well? | 03:47 |
| lifeless | what are you branching? | 03:47 |
| jam | bzr.dev | 03:47 |
| lifeless | that will take quite some time | 03:47 |
| jam | is gc that slow? | 03:47 |
| jam | ah ok | 03:48 |
| lifeless | its recompressing everything | 03:48 |
| jam | I thought it was at the point of being real-world usable and that is why you said you were testing with "bzr branch" :) | 03:48 |
| lifeless | I'm working up to bigger and bigger branches | 03:48 |
| jam | lifeless: so... I was thinking about bringing a pyrex version of the hash-table | 03:49 |
| jam | at the moment, I've just been prototyping it out | 03:49 |
| jam | in python | 03:49 |
| jam | interesting | 03:50 |
| jam | my change at least doesn't slow it down | 03:50 |
| djbclark | Am I correct in determing that none of the DVCS systems support svn-like versioned properties (metadata), but bazaar ir probably the closest to having that feature? | 03:51 |
| jam | maybe 41s versus 43s for bzrtools | 03:51 |
| jam | probably the big win is that you don't actually need to use sets() everywhere | 03:51 |
| jam | as a plain list is just as good | 03:51 |
| jam | (you know you won't get duplicates because of how the line lists are built up) | 03:51 |
| lifeless | djbclark: seems plausible | 03:52 |
| berto- | looks like i broke a bzr-svn repository by running "bzr uncommit" on it. i get internal errors now. any way to revert back to the committed state. then, any way to safely have bzr forget what i committed? | 03:53 |
| djbclark | ah, just found http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/40419/focus=40479 :-) | 03:53 |
| jelmer | berto-, broke it how? | 03:53 |
| lifeless | berto-: well, file bugs please :P | 03:53 |
| berto- | lifeless: i want to see if it's really broken first. :P | 03:54 |
| lifeless | berto-: if you are getting internal errors, its a bug | 03:54 |
| lifeless | jam: so - I'll work on getting the fetch order to be good | 03:56 |
| lifeless | jam: as hacking on get_matching_blocks would collide with you | 03:56 |
| jam | sure | 03:56 |
| jam | sounds reasonable | 03:56 |
| berto- | jelmer: hmm, may not be the uncommit that broke it. i ran bzr merge on ~/.bazaar/plugins/svn and recompiled, got some error, ran make clean && find . -name '*.pyc' | xargs rm && make, and now i get an import error on from bzrlib.plugins.svn.versionedfiles import (SvnTexts, VirtualRevisionTexts[...]: File "/home/berto/.bazaar/plugins/svn/versionedfiles.py", line 18 | 03:58 |
| berto- | ImportError: cannot import name VirtualVersionedFiles | 03:58 |
| jelmer | berto-: you need a newer version of bzr | 03:58 |
| berto- | jelmer: cool, thanks, working on updating | 03:58 |
| jelmer | VirtualVersionedFiles is only in a recent revision of bzr.dev | 03:58 |
| berto- | jelmer: alright, working great again, thanks! | 04:03 |
| jelmer | :-) | 04:03 |
| berto- | jelmer: i take it bzr uncommit now works? should i remove it from the wiki as an unsupported command? | 04:04 |
| berto- | jelmer: how about bzr push --overwrite ? | 04:04 |
| jelmer | berto-: what did uncommit do? | 04:04 |
| berto- | jelmer: i ran bzr uncommit -r <revno>; that uncommitted a directory i had added as well as some other files i had modified. it basically put the added directory back into an add state, then put the other files back in a modified state. i was then able to run bzr ci -m'[...]' <dir> | 04:05 |
| berto- | ... which just committed the added directory and left all the modified files alone. | 04:06 |
| jelmer | Was that committing it back to svn as well though? | 04:06 |
| berto- | jelmer: no, all that was local, i have not committed back up to svn as it's an svn repo i don't have commit access to. | 04:07 |
| jelmer | berto-, ok, so that's all unrelated to bzr-svn | 04:07 |
| lifeless | berto-: then you're operating purely in bzr land :) | 04:07 |
| berto- | jelmer: ah, ok. cool. | 04:07 |
| berto- | i see, awesome. | 04:07 |
| === sm_ is now known as sm | ||
| berto- | so it's trying to uncommit something that was committed in svn that's not going to work right. | 04:08 |
| berto- | [the current version of] svn has no concept of being able to uncommit, so will there ever be some sort of support for that, or is a revert mechanism as close as it gets? | 04:08 |
| jelmer | it will be possible to uncommit, but it'll basically do a revert (copy from a revision in the past) | 04:09 |
| jelmer | s/copy/replace/ | 04:09 |
| lifeless | back later | 04:42 |
| berto- | jelmer: thanks again for the help! | 04:46 |
| berto- | lifeless: thank you too. | 04:46 |
| jam | lifeless: holy crap | 04:49 |
| jam | compacting all of NEWS in 'topological order' | 04:49 |
| jam | Compressed 3213 text with 437350320 bytes to 74265451 bytes (5.89:1) in 109.994s | 04:49 |
| jam | and in *reverse* topological order | 04:49 |
| jam | Compressed 3213 text with 437350320 bytes to 5814355 bytes (75.22:1) in 271.026s | 04:49 |
| jam | 75:1 versus 6:1 | 04:50 |
| jam | bit of a difference | 04:50 |
| mwhudson | i also guess that this is going to be quite a slow 'bzr upgrade'? | 04:50 |
| mwhudson | but wow, nice numbers | 04:50 |
| jam | mwhudson: well, I'm working on writing a C extension to improve the speed | 04:51 |
| mwhudson | ah right | 04:51 |
| jam | but the 75:1 compression ratio is pretty darn good | 04:51 |
| jam | I have the feeling it owes the most to the multi-location abilities of groupcompress | 04:52 |
| jam | basically, it follows *all* matches concurrently | 04:52 |
| jam | and picks the one with the longest sequence | 04:52 |
| jam | And NEWS is rather a special case | 04:52 |
| jam | since it is 95% insert-only | 04:52 |
| mwhudson | jam: yeah, i guess builtins.py is another obvious one to try | 04:53 |
| jam | mwhudson: running it now | 04:54 |
| mwhudson | :) | 04:54 |
| jam | forward: Compressed 1837 text with 210568735 bytes to 38663891 bytes (5.45:1) in 80.498s | 04:54 |
| jam | mwhudson: builtins.py was the one I used for my xdelta testing | 04:54 |
| mwhudson | ah right, i remember now | 04:55 |
| jam | though it had only 1300 texts, IIRC | 04:55 |
| jam | reverse: Compressed 1837 text with 210568735 bytes to 21061973 bytes (10.00:1) in 76.862s | 04:56 |
| jam | Don't trust the times completely, as I'm poking at the code while waiting :) | 04:56 |
| mwhudson | heh | 04:56 |
| mwhudson | less spectacular | 04:56 |
| jam | less spectacular, but 2:1 for going in reverse versus forward | 04:56 |
| bob2 | and faster in reverse | 04:56 |
| jam | bob2: well, as I said, I poked at the code in there, so maybe, maybe not | 04:57 |
| lifeless | also | 04:59 |
| lifeless | is that the raw output or the gzipped? | 05:00 |
| jam | lifeless: raw | 05:00 |
| lifeless | yah | 05:00 |
| lifeless | thought so :) | 05:00 |
| lifeless | but now you see why I think this has legs :) | 05:00 |
| jam | lifeless: does that normalize a bit more? | 05:00 |
| lifeless | jam: its the gzip phase takes the reverse output below git in size | 05:01 |
| bob2 | is gc similar to how git does packs? | 05:01 |
| jam | bob2: git does xdelta compression | 05:01 |
| jam | gc is a different algorithm | 05:01 |
| jam | the idea of --reverse versus --forward is somewhat taken from git | 05:01 |
| lifeless | jam: oh, it *does* do xdelta? | 05:01 |
| jam | lifeless: yes | 05:01 |
| jam | I'm not sure if it is xdelta 1,2,3 | 05:01 |
| jam | but xdelta | 05:02 |
| jam | at least, that is what I remember | 05:02 |
| jam | lifeless: interestingly, sorting by text size | 05:04 |
| jam | is slightly better for group-compress | 05:04 |
| jam | (without gzip) | 05:04 |
| jam | rather than reverse topological | 05:05 |
| lifeless | jam: as expected; though we don't cache size at a good place to use for this | 05:05 |
| jam | at least, in my 2 trivial tests | 05:05 |
| jam | lifeless: strictly because it gives more locations to match ? | 05:05 |
| lifeless | yes | 05:05 |
| lifeless | well | 05:05 |
| lifeless | because it can encode longer sequences | 05:06 |
| jam | lifeless: you may be interested in lp:~jameinel/+junk/test-groupcompress | 05:07 |
| jam | You may not | 05:07 |
| jam | but it provides direct GC testin | 05:07 |
| jam | testing | 05:07 |
| jam | by extracting the texts from the ancestry of a supplied file | 05:08 |
| jam | and --lsp filename.callgrind will profile *just* the GC operations | 05:08 |
| sohail | hey guys, I deleted directory foo in commit 560 but also a whole bunch of other stuff that I don't want. How can I bring back just directory foo? | 05:15 |
| lifeless | sohail: bzr revert -r 560 foo | 05:17 |
| sohail | lifeless, ah! | 05:17 |
| * sohail tries | 05:17 | |
| sohail | lifeless, "ERROR: Path(s) are not versioned: foo" | 05:18 |
| lifeless | sohail: oh :( | 05:23 |
| lifeless | sohail: try -r 559 ;) | 05:24 |
| sohail | lifeless, I did bzr merge -r560..559 aka svn :-) | 05:26 |
| sohail | but what I really want to do is bzr cp foo@559 dir/foo | 05:26 |
| sohail | but I can't figure out how to do that | 05:26 |
| lifeless | sohail: well, merge -r560..559 foo should work | 05:27 |
| sohail | lifeless, yeah that worked | 05:28 |
| lifeless | sohail: revert -r 559 foo should have worked too | 05:28 |
| lifeless | (clearly -r 560 can't as foo doesn't exist there :p) | 05:28 |
| sohail | lifeless, trying now | 05:29 |
| sohail | lifeless, you were right, it worked | 05:31 |
| === samurai_ is now known as samurai | ||
| sohail | in the star trek universe, the person who figures out how to transport with shields still up will win the nobel prize | 05:33 |
| spiv | bzrlib.tests.blackbox.test_info.TestInfo.test_info_standalone in bzr.dev is failing for me. | 05:48 |
| spiv | File "/home/andrew/code/bzr/bzrlib/tests/blackbox/test_info.py", line 158, in test_info_standalone | 05:48 |
| spiv | bzrlib.upgrade.upgrade('bound', knit1_format) | 05:48 |
| spiv | AttributeError: 'module' object has no attribute 'upgrade' | 05:48 |
| lifeless | spiv: funky | 05:49 |
| lifeless | spiv: and does it? | 05:50 |
| spiv | lifeless: | 05:51 |
| spiv | $ PYTHONPATH=. python -c "from bzrlib.upgrade import upgrade" | 05:51 |
| spiv | $ | 05:51 |
| spiv | Hmm. | 05:51 |
| mwhudson | circular imports again? | 05:53 |
| spiv | Ah. | 05:53 |
| spiv | It's the 'bzrlib' object that lacks the 'upgrade' attr, not the 'bzrlib.upgrade' object. | 05:53 |
| spiv | i.e. there's a missing "import bzrlib.upgrade" | 05:54 |
| mwhudson | oh hee | 05:54 |
| mwhudson | it makes a difference whether you selftest <that test> | 05:54 |
| mwhudson | or selftest -s <that test> | 05:54 |
| spiv | Yeah. | 05:54 |
| spiv | Which is why I couldn't reproduce it with 1.5: I couldn't use -s :) | 05:54 |
| * spiv fires off a trivial fix. | 05:55 | |
| Stumbles | hi, I've just read quickly through the bzr user guide, but couldn't see an example of how to make a topic branch. How do I do this? | 09:00 |
| luks | bzr branch A B? | 09:00 |
| Stumbles | what's A and what's B? | 09:01 |
| Stumbles | as in, which is the trunk? | 09:01 |
| luks | A is the original branch, B is the branch you want to create | 09:01 |
| luks | A | 09:01 |
| Stumbles | thanks | 09:02 |
| Stumbles | Just trying to get my head around bazaar after using Git for a while. So if I do "bzr init repo" and then "bzr branch repo repo2", do I then have two full repositories? | 09:05 |
| RAOF | Kindof. | 09:06 |
| spiv | Stumbles: there's some terminology differences with Git that confuses things a little. | 09:06 |
| RAOF | bzr makes a distinction between things that are conflated in git. | 09:06 |
| * RAOF leaves it to the more knowledgable spiv | 09:07 | |
| spiv | Stumbles: you have two branches, each with a full copy of history in them. (And so if you haven't done other set up to avoid this, you'll be using twice as much disk space as if you only had one branch). | 09:07 |
| spiv | Stumbles: "bzr init" creates a what we call a "branch". | 09:08 |
| spiv | Stumbles: "bzr init-repo" creates what we call a "shared repository". | 09:08 |
| Stumbles | Thanks, this is a great help. So the way to go is "bzr init-repo myrepo", "mkdir myrepo/trunk", "cd myrepo", "bzr branch trunk mytopicbranch"? | 09:09 |
| spiv | Stumbles: so for comparison, if you did "bzr init-repo repo", then "cd repo; bzr init branch-one; bzr branch branch-one branch-two", you'd have two branches inside one shared repository. | 09:10 |
| spiv | Stumbles: right, except "bzr init myrepo/trunk" rather than "mkdir myrepo/trunk". | 09:10 |
| Stumbles | lovely | 09:10 |
| Stumbles | ok, right | 09:11 |
| Stumbles | and that way the second branch doesn't take additional space until I change files? | 09:11 |
| spiv | Right. | 09:12 |
| spiv | The two branches will use the same storage for their revisions. | 09:13 |
| Stumbles | ah right, I see, shared repository, but two full working copies | 09:13 |
| Stumbles | shared history i mean | 09:14 |
| Stumbles | thanks spiv, much appreciated | 09:15 |
| luks | you can have just one working directory, but then it gets a little complicated | 09:16 |
| spiv | Stumbles: you're welcome | 09:16 |
| Stumbles | so if you were doing lots of short-lived branching, say one or two commits before merging with the main line, a shared repository would definitely be the way to go, right? | 09:32 |
| spiv | Stumbles: yep | 09:33 |
| === weigon_ is now known as weigon | ||
| Stumbles | if not using a shared repository, what would the difference be between "cp -r original branch" and "bzr branch original branch"? | 09:39 |
| Peng_ | Stumbles: Since it actually access the repo, it would somewhat verify that it isn't broken. It won't copy working tree modifications and unversioned files. | 09:41 |
| Stumbles | thanks | 09:43 |
| Peng_ | accesses* | 09:43 |
| RAOF | Even without doing lots of short-lived branching, you probably want a shared repository anyway. Pulling other people's remote branches is orders of magnitude faster when you pull them into a shared repository which already contains most of the history. | 09:44 |
| RAOF | And the way that I use bzr, pulling other people's branches is by far the slowest operation, so a shared repository makes a lot of difference. | 09:46 |
| Stumbles | thans RAOF | 09:51 |
| === yacc__ is now known as yacc | ||
| pitti | hi | 10:07 |
| pitti | KnitCorrupt: Knit text:x_Matt_Zimmerman_<matt.zimmerman@canonical.com>_Sun_Mar_13_00:51:19_2005_1366.38 corrupt: line-delta from stream for version mdz@mizar-20051205230117-c327e75be767f237 references missing parent Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21 | 10:08 |
| pitti | oh, the late wrath of arch... | 10:08 |
| pitti | I get that when trying bzr get lp:~ubuntu-core-dev/casper/trunk casper | 10:08 |
| pitti | any idea what I can do to debug/fix this/ | 10:08 |
| pitti | ? | 10:08 |
| james_w | hi pitti | 10:22 |
| pitti | in the meantime I found some pointers to that | 10:22 |
| james_w | I've heard rumblings about the casper branch. | 10:22 |
| pitti | bug 246880 and https://answers.launchpad.net/launchpad-bazaar/+question/39693 | 10:22 |
| ubottu | Launchpad bug 246880 in bzr "Can't branch casper which misses some parents in old revisions" [Undecided,New] https://launchpad.net/bugs/246880 | 10:22 |
| cjwatson | I'm working on it | 10:23 |
| cjwatson | mdz still has the old branch kicking around | 10:23 |
| cjwatson | so I'll fetch the ghosts | 10:24 |
| cjwatson | pitti: no point you working on this simultaneously :) | 10:24 |
| pitti | right, I just started asking here | 10:24 |
| pitti | cjwatson: thanks | 10:24 |
| cjwatson | though first I have to remember how the hell to mirror an archive using baz | 10:24 |
| cjwatson | recycled neurons FTW | 10:25 |
| pitti | I might still have it in the REAME.Developers of postgresql-common in an ancient revision | 10:25 |
| cjwatson | it's OK, I've got far enough to remember the basics | 10:25 |
| pitti | ouch | 10:26 |
| * pitti reads about make-archive, register-archive, branch, get, and gets painful memories | 10:27 | |
| pitti | "27 easy steps to check out a branch" | 10:27 |
| * Kinnison giggles | 10:38 | |
| * Kinnison has utterly evicted that knowledge from his head too | 10:38 | |
| pitti | hey Kinnison, how's life? | 10:39 |
| Kinnison | busy and full of windows, poorly written packet sniffers, and embedded RF microprocessors | 10:39 |
| pitti | yay hardware development :) | 10:39 |
| Kinnison | indeed | 10:40 |
| * pitti was happy about the atmel toolchain back then, which ran fine under linux | 10:40 | |
| Kinnison | In this instance, I'm trying to work out why a three-byte payload packet ends up doing around 8 packets, comprising around 200 bytes over the air | 10:40 |
| Kinnison | mmm 802.15.4+ZigBee2004 | 10:40 |
| cjwatson | Kinnison: hi! TLNS | 10:41 |
| cjwatson | err, ^T | 10:41 |
| * Kinnison grins | 10:41 | |
| * Kinnison is usually around :-) | 10:41 | |
| krani1 | hi! I'm having a problem. a developer branched my repo, worked on something, created a bundle with "bzr bundle" and send it to me.. I worked on my branch too... Now everytime I want to merge his bundle "bzr merge file.bundle" I'm getting an error "Revision {('dev mail address-foo bar',)} not present... | 11:37 |
| Peng_ | Sounds like the bundle is broken, corrupt, or just missing some revisions you don't have. | 11:38 |
| krani1 | Peng_: the base_resvision_id on the bundle exists on my tree | 11:39 |
| krani1 | bzr jsut can't find the "revision_id" on my tree.. and I think it doesn't make sense... *after* aplying the bundle it shuld exist, not *before* | 11:39 |
| Kinnison | has the bundle become corrupted in transit? | 11:41 |
| Kinnison | E.g. has an email mangled it? | 11:41 |
| Peng_ | "dev mail address-foo bar" is a horribly weird revision ID; bzr would never generate that on its own. | 11:43 |
| lifeless | Peng_: I think krani1 is paraphrasing | 11:44 |
| krani1 | Peng_: :) | 11:44 |
| lifeless | Kinnison: bundles are base64 encoded | 11:45 |
| lifeless | Kinnison: and checksummed: its not mangled | 11:45 |
| Kinnison | aah | 11:45 |
| Kinnison | cunning | 11:45 |
| james_w | krani1: is the revision it complains about the base_revision_id mentioned in the bundle? | 11:45 |
| james_w | also, is the branch it refers to the branch that you are trying to merge it in to, or another? | 11:46 |
| krani1 | james_w: no! the "base_revision_id" mentioned in the bundle exists on my tree! It complains about the "revision_id" mentioned in the bundle! | 11:46 |
| james_w | do you get a backtrace? | 11:46 |
| krani1 | james_w: actually, I'm trying to merge on another branch... does that make a difference? | 11:47 |
| james_w | if so, could you pastebin it please? If not, then please run again with -Derror | 11:47 |
| james_w | another branch? | 11:48 |
| james_w | I don't really understand, you are trying to merge it in to a branch, and that has the base_revision_id, but it is complaining? | 11:49 |
| krani1 | james_w here is the traceback with -Derror http://pastebin.com/m127de67c | 11:49 |
| krani1 | james_w: exactly! that! it doesn't make sense! | 11:50 |
| james_w | that's in _verify_patch | 11:50 |
| james_w | so it hasn't started merging yet | 11:50 |
| krani1 | I'm not merging into the "target_branch" mentioned in the bundle, can that be a problem? | 11:53 |
| james_w | possibly | 11:53 |
| james_w | at first look, this should never work, but that's obviously wrong. | 11:54 |
| lifeless | krani1: that shouldn't matter, as long as the branch you are merging into has at least the same revisions the target did | 11:54 |
| james_w | so, it's trying to regenerate the diff to check it, so it takes the repository you are trying to merge in to, and then extracts the trees of the base_revision_id and the target revision, but I can't see how that would ever be expected to work | 11:55 |
| krani1 | lifeless: well as I said it, the "base_revision_id" in the bundle exists on my tree.... something went wrong here... the dev is telling me he have more commits, and just sent me a particular commit using "bzr bundle -r ..." | 11:56 |
| spiv | james_w: because from_mergeable does install_revisions to tree.branch.repository before it does get_merge_request. | 11:56 |
| james_w | spiv: ah, thanks. | 11:56 |
| james_w | krani1: this would suggest that the bundle doesn't contain all of the revisions. | 11:57 |
| krani1 | james_w: ok.. will talk to the dev and try to sort things out, thank you guys | 11:58 |
| james_w | krani1: I'm just looking for a way to debug this a little more | 11:58 |
| krani1 | james_w: If I can provide you more info, feel free to ask | 11:59 |
| james_w | the command to debug a bundle was removed I think, so I'm not sure what to do | 11:59 |
| Peng_ | ...Oh. Right. Paraphrasing. Heh. Never mind then. | 11:59 |
| james_w | it would be useful to know what command and arguments they used to generate this bundle. | 12:00 |
| krani1 | I will try to get them, just a minute | 12:00 |
| krani1 | james_w: bzr bundle -o build.patch -r revno:107..revno:108 | 12:02 |
| krani1 | that's the exact command he used | 12:02 |
| james_w | just as aside "revno:" is default, so "-r 107..108" would be work and is less to type. That won't affect this though. | 12:03 |
| james_w | is revno 107 something that you have in your branch? | 12:03 |
| krani1 | james_w: yes! | 12:03 |
| krani1 | he branched on that exact revno | 12:04 |
| lifeless | krani1: are you editing the backtrace that we see ? | 12:05 |
| krani1 | lifeless: just the 'dev mail' everyting is verbatim | 12:05 |
| spiv | krani1: I'm curious about why they didn't use "bzr send -o build.patch target_branch" to generate the merge directive? | 12:06 |
| lifeless | krani1: ok, can you only edit the mail part of it, keep the UUID bit at the end intact ? | 12:06 |
| krani1 | spiv: cause bzr send generates a bundle that I can't apply on my local branch.. it seems I can only apply it on the branch the dev first got (target_branch)...... but that's another problem.... | 12:07 |
| spiv | krani1: bzr send tries pretty hard to automatically figure out what the right merge directive is, but using -r circumvents that. | 12:07 |
| spiv | krani1: Hmm! I have a very strong suspicion that that is actually a symptom of the same root problem. | 12:08 |
| krani1 | spiv: the workflow is. I have local branches, and push the changes to a shared server. the dev branches from the server, works, commits and sends bundle back to me, so I can review and push them back to server... does this help? | 12:09 |
| spiv | I wonder if revno 107 in the two branches are actually the same revision... | 12:09 |
| krani1 | spiv: is there an easy way to verify that? | 12:09 |
| lifeless | revision-info | 12:10 |
| Peng_ | krani1: If you gave devs push access to an area of the server, you wouldn't have to bother with bundles.. | 12:10 |
| krani1 | Peng_: I'm working like a gatekeeper.... | 12:10 |
| lifeless | bundles should work fine | 12:11 |
| spiv | krani1: Compare the output of "bzr revision-info -r107" in both branches. | 12:11 |
| krani1 | spiv: doing that | 12:11 |
| lifeless | you don't need them though if you had the devs push up their own branches to a different area | 12:11 |
| spiv | krani1: Or of "bzr log --short -r 107 --show-ids" if you want slightly more verbose output. | 12:11 |
| krani1 | spiv: OMG they are different! w00t??? | 12:11 |
| spiv | krani1: ta-da. | 12:11 |
| krani1 | spiv: how can this happen?! | 12:12 |
| Peng_ | Revnos are per-branch. bzr.dev has a different revision 107 too.. | 12:12 |
| lifeless | krani1: the dotted decimal revision numbers are just a convenience over the underlying UUIDs. they are specific to an individual branch | 12:12 |
| krani1 | lifeless: so how the dev should generate the bundle then? | 12:13 |
| spiv | krani1: so, if they do "bzr send -o foo.patch target_branch", it should generate a workable bundle. | 12:13 |
| lifeless | krani1: as spiv says, you don't need the -r parameters ever, unless you need to do a cherry pick | 12:14 |
| spiv | krani1: so long as the branch you try to merge foo.patch into includes all the history of the target_branch given to bzr send. | 12:14 |
| spiv | krani1: (e.g. it's the same branch, or it has merged that branch, etc) | 12:14 |
| krani1 | humm it all makes sense now | 12:15 |
| krani1 | I've got the lesson.. never trust revno :-) | 12:17 |
| krani1 | in the bundle, what does it really mean the "revision_id" and the "base_revision_id" ? | 12:29 |
| james_w | krani1: the base_revision_id is the ancestor revision that the bundle is based on, revision_id is the tip revision in the bundle | 12:54 |
| lamont | bzrlib/_dirstate_helpers_c.c:2161: warning: dereferencing type-punned pointer will break strict-aliasing rules | 14:19 |
| lamont | and many others. | 14:19 |
| VSpike | does anyone know if the bzr-upload plugin is in a useful state? | 14:46 |
| beuno | VSpike, I sure hope so :) | 14:46 |
| beuno | quite a few people have been using it for months | 14:46 |
| beuno | and we've had no major bug reports | 14:46 |
| mtaylor | beuno: bzr-upload? | 14:46 |
| VSpike | beuno: thanks - I couldn't really see any indication of its development status on the launchpad site | 14:47 |
| mtaylor | oh, neat | 14:47 |
| beuno | mtaylor, yes, it's a plugin to upload *just* the working tree | 14:47 |
| mtaylor | very cool | 14:47 |
| beuno | mainly for websites, but there must be all kinds of creative use cases | 14:47 |
| * beuno looks at the lp page to make the status more obvious | 14:48 | |
| VSpike | beuno: are there any install/use instructions anywhere? | 14:48 |
| beuno | VSpike, there's a README in the branch, and you can install it like any other plugin: bzr co lp:bzr-upload ~/.bazaar/plugins/upload | 14:49 |
| beuno | (basically, copy it to the plugins dir) | 14:49 |
| VSpike | beuno: does lp: use ssh underneath? | 14:50 |
| Peng_ | VSpike: If you're logged out, it uses http. If you're logged in (bzr launchpad-login my_username), it uses bzr+ssh | 14:51 |
| VSpike | Peng_: I'm not logged in .. it's just it's giving me "bzr: ERROR: [Errno 0] Error" which is what I get when I try use sftp | 14:51 |
| Peng_ | VSpike: What's the exact command you're running? | 14:53 |
| VSpike | as beuno just typed | 14:53 |
| VSpike | Peng_: ^ | 14:53 |
| Peng_ | Oh. | 14:53 |
| Peng_ | I dunno, then, and I'm about to go to bed. Good luck. Hopefully someone else can figure it out. | 14:53 |
| VSpike | Ta :) | 14:54 |
| beuno | VSpike, what version of bzr are you using? | 14:58 |
| VSpike | I may have found a fix, hold on | 15:00 |
| VSpike | Cygwin version :) | 15:00 |
| beuno | ah, ew :) | 15:00 |
| beuno | I'm off for a bit | 15:00 |
| VSpike | You mention cygwin and people just leg it | 15:00 |
| beuno | I'll read the backlog when I get back in case you run into more trouble | 15:00 |
| VSpike | :D | 15:00 |
| VSpike | Well, I found a fix for my sftp problem, but the lp one might not succumb | 15:01 |
| VSpike | Ah no.. just had to mkdir -p ~/.bazaar/plugins/upload | 15:02 |
| VSpike | beuno: Thanks for the help | 15:03 |
| VSpike | If I already have the site uploaded, do I need to delete it before running bzr upload for the first time? | 15:25 |
| VSpike | I'm getting an error "File exists: '/AllUsers': 500 /AllUsers: Access is denied." | 15:26 |
| VSpike | If I know it's in sync with the current revision, can I create a revision ID marker on the site ftp so that it works without doing a full upload? | 15:37 |
| beuno | VSpike, yeap | 15:48 |
| beuno | you can trick it | 15:48 |
| VSpike | beuno: what do I need to put there? | 15:50 |
| beuno | VSpike, a file named: .bzr-upload.revid | 15:52 |
| beuno | which contains the last revid | 15:52 |
| beuno | of your branch | 15:53 |
| beuno | (you get revids by adding --show-ids to the log command) | 15:53 |
| VSpike | Thanks :) | 15:54 |
| beuno | welcome' | 15:55 |
| VSpike | Yes, although generally we would be expecting people to use Thuraya for messages so not an issue | 16:09 |
| VSpike | I guess we should publish this info on the site | 16:09 |
| beuno | probably the wrong window :) | 16:09 |
| VSpike | Ah yeah ta | 16:10 |
| VSpike | Sheesh | 16:10 |
| === mvo__ is now known as mvo | ||
| VSpike | beuno: how critical is the format of that file? It's not finding it | 16:26 |
| beuno | VSpike, it doesn't have much of a format | 16:27 |
| beuno | just the name and the revid text in it | 16:27 |
| VSpike | beuno: it contains -- johncc@gort-20080724140726-blahblahblah<LF> | 16:28 |
| beuno | VSpike, what the <LF> at the end? | 16:28 |
| VSpike | I mean it ends with a normal unix line ending | 16:28 |
| beuno | no line ending | 16:28 |
| fbond | Hi. I used `bzr replay -r x..y' one day and was surprised to find that revision x had been replayed. | 16:29 |
| fbond | `bzr merge -r x..y', `bzr diff -r x..y' don't seem to include revision x. Right? | 16:29 |
| beuno | VSpike, and, is that in the root of the dir? | 16:29 |
| fbond | Is replay an odd duck? | 16:29 |
| * beuno has no idea what replay does | 16:30 | |
| fbond | beuno: it is part of the rebase plugin. | 16:30 |
| VSpike | beuno: yeah, it's in the root. Still not working though. | 16:31 |
| beuno | VSpike, it still tries to upload? | 16:32 |
| fullermd | It doesn't sound odd, just a different meaning. | 16:40 |
| fullermd | `bzr log -rx..y` includes x, frex. | 16:40 |
| luks | what's the best way to upgrade branches on launchpad? I'm running an upgrade over sftp right now, but I'm starting to regret that | 16:40 |
| luks | bzr+ssh just told me the branch is already up to date | 16:41 |
| luks | (it probably tries to upgrade only the branch, not the repo) | 16:41 |
| beuno | VSpike, bug report was a good way to go, thanks | 16:42 |
| fullermd | I'm not sure it tries to upgrade anything; I think it still just sees a totally fake format. | 16:42 |
| luks | oh | 16:43 |
| fullermd | Try info -v: | 16:44 |
| fullermd | Format: | 16:44 |
| fullermd | control: bzr remote bzrdir | 16:44 |
| fullermd | branch: Remote BZR Branch | 16:44 |
| fullermd | repository: bzr remote repository | 16:44 |
| beuno | for some reason, bzr info via ssh always lies. Only http tells you the actual format | 16:45 |
| beuno | (maybe sftp too) | 16:46 |
| fullermd | Well, the reasin is because that's how the SS does its thing. | 16:46 |
| fullermd | Info over bzr:// or bzr+http:// would presumably tell you just the same. | 16:46 |
| VSpike | beuno: no prob. Yes, it says "No uploaded revision id found, switching to full upload" | 16:47 |
| luks | I was stupidly hoping it would just run an equivalent of 'bzr upgrade' remotely, so it doesn't have to transfer anything | 16:47 |
| VSpike | Hmm maybe doing strace python /usr/bin/bzr upload .. was not such a good idea :) | 16:48 |
| ddrreeeaaammss | When I install bazaar on vista whenever I fire up a new command prompt the workling directory is automatically "C:\program files\bazaar" how do i change this? | 16:52 |
| VSpike | ddrreeeaaammss: do you mean the bazaar command prompt entry in the start menu? | 16:57 |
| ddrreeeaaammss | No | 16:57 |
| ddrreeeaaammss | I mean if I go start "cmd" press enter I start in c:\program files\bazaar | 16:57 |
| cjwatson | luks: there's a bug report asking for that | 17:00 |
| cjwatson | (I don't have the number to hand but look for "upgrade" and "smart server" or some such) | 17:00 |
| fullermd | luks: It's a good hope... | 17:06 |
| fbond | fullermd: The inconsistency bothers me a bit. replay is more similar to merge than it is to log, but merge is exclusive, and both replay and log are inclusive. | 17:27 |
| fbond | It's confusing, and inspires doubt. | 17:27 |
| fullermd | Well, merge is a stick point. | 17:33 |
| fbond | rebase is inclusive | 17:34 |
| fullermd | Merge is what merge is by analogy to diff. | 17:34 |
| fbond | diff is exclusive | 17:34 |
| fullermd | Where it's simple. | 17:34 |
| fbond | fullermd: And why is diff exclusive? | 17:34 |
| fullermd | "Show me the differences from state x to state y" | 17:34 |
| fullermd | That wouldn't include the differences from state (x-1) to x. | 17:35 |
| fbond | "Merge the differences from state x to state y" | 17:35 |
| fullermd | Compare log, where it's "Show me the logs from revision x to revision y", where you'd expect to see both x and y. | 17:35 |
| fbond | "Replay the differences between state x and state y" | 17:35 |
| dash | hi. just got a traceback making a checkin on 1.5 -- | 17:35 |
| fullermd | That's now how I read replay. | 17:35 |
| fullermd | (not) | 17:35 |
| fullermd | I'd read it as "replay revisions x to y". | 17:35 |
| dash | http://rafb.net/p/QokLZ842.html | 17:36 |
| fbond | fullermd: I get it, but I think it is more arbitrary than you are portraying. | 17:36 |
| dash | this look familiar to anyone? | 17:36 |
| fullermd | Well, everything's arbitrary. My reading feels more natural to me. Doesn't mean it does to everybody, but it suggests that it does to whoever wrote replay. | 17:36 |
| fbond | fullermd: I'm just saying that doing it arbitrarily in two different ways is confusing. | 17:37 |
| fbond | I don't think the meaning follows naturally from the command. | 17:37 |
| fullermd | It'd be more confusing otherwise. | 17:38 |
| fbond | It is not obvious that replay replays revisions while merge merges deltas. | 17:38 |
| luks | fbond: then `bzr replay -rX` should be invalid? | 17:38 |
| fullermd | Well, it is to me... | 17:38 |
| fbond | luks: Not necessarily. | 17:38 |
| fbond | luks: merge -rX is valid, too... | 17:38 |
| luks | it would be noop, if it's exclusive | 17:38 |
| fbond | luks: For merge it means "from the beginning up to X". | 17:38 |
| luks | fbond: but I think it does something very different from -rX..Y | 17:39 |
| fbond | luks: I'm not sure what -rX should do for replay. | 17:39 |
| fbond | But I don't think that that should dilute my point. | 17:39 |
| luks | replay revision X, which means it should be inclusive | 17:39 |
| fbond | Why should -rX syntax imply anything about -rX..Y syntax? | 17:40 |
| fbond | The meaning of -rX obviously varies heavily from one command to the next, anyway. | 17:40 |
| luks | -rX..Y in merge is a special case, "a cherry-pick" | 17:40 |
| luks | what is confusing in case of replay is that is treats revisions as changesets | 17:41 |
| luks | ideally it should use -cX..Y | 17:42 |
| luks | that should be more clear, I think | 17:42 |
| fbond | luks: Okay, now we're getting somewhere, I think. | 17:42 |
| gnomefreak | has bzr changed to where bzr bd --merge --dont-purge --builder='dpkg-buildpackage -rfakeroot -kA5C42601 -i.bzr' . no longer waits for passphrase? | 17:44 |
| gnomefreak | i had steppeed away for about an hour and came back and it told me invalid passphrase | 17:45 |
| james_w | gnomefreak: shouldn't have | 17:45 |
| gnomefreak | james_w: give me a minute or 2 | 17:46 |
| gnomefreak | i have output just lagging alot | 17:46 |
| gnomefreak | james_w: http://pastebin.mozilla.org/498831 | 17:47 |
| gnomefreak | if that helps | 17:47 |
| gnomefreak | it never waited for me | 17:47 |
| james_w | nothing should have changed in bzr/bzr-builddeb to break that I don't think | 17:47 |
| gnomefreak | i havetn used it since hardy devel cycle and it worked than | 17:48 |
| * gnomefreak sitting and waiting for the source build to see if that atleast asks me | 17:49 | |
| gnomefreak | if it fails this time ill file a bug on LP about it in morning | 17:49 |
| gnomefreak | dpkg-buildpackage still asks me so i figured it had to do with bze-builddeb | 17:50 |
| gnomefreak | james_w: -S -sa gave me the passphrase popup dialog | 17:52 |
| === davi_ is now known as davi | ||
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| strk | is it possible to get keyword substitution on commit like for CVS ? | 18:38 |
| strk | it seems $Id$ isn't substituted ... | 18:38 |
| beuno | strk, you could probably script something with the pre-commit hook | 18:42 |
| strk | urgh | 18:43 |
| strk | really nothing built in for that ? | 18:44 |
| dash | strk: you want the uuid in there? | 18:48 |
| strk | don't even know what it is :( | 18:49 |
| strk | whatever identifies a specific revision of the file | 18:49 |
| dash | right, that'd be the uuid (because the short revision numbers aren't guaranteed to be unique or stable) | 18:50 |
| strk | k | 18:50 |
| strk | hope for me ? :> | 18:50 |
| dash | so, something like foo@baz.com-20080722154412-x8m52mo7rj5umv9a | 18:51 |
| dash | strk: I guess the question is, why do you want it in the file? :) | 18:51 |
| dash | my experience has been that software version numbers are useful to have in the text of the files; if revision information is needed, it's pretty easy to ask the revision control system for it | 18:52 |
| === mw is now known as mw|out | ||
| strk | dash: http://gnashdev.org/testcases/v6/array-v6.swf | 18:53 |
| strk | see on top, between [] | 18:53 |
| dash | ah. | 18:54 |
| strk | it comes from .as source containing the keyword | 18:54 |
| strk | http://wiki.gnashdev.org/Testcases#Testcases | 18:54 |
| strk | ^^^ more info about how that's useful | 18:54 |
| strk | the uuid doesn't look as readable as the current RCSId :/ | 18:56 |
| strk | know what ? the best would be branch name and revision of that branch | 18:58 |
| strk | possible ? | 18:58 |
| strk | like: trunk 9532. | 18:58 |
| fullermd | The best would be different per situation :p | 18:58 |
| strk | best in *this* situation ofc | 18:58 |
| fullermd | At the least you'd want the options of {revno,revid,date} of last change to the {file,tree}. | 18:59 |
| strk | ah, right, don't care about revision of the whole branch | 19:00 |
| strk | but, dunno what revno,revid are (ie: why two?) | 19:00 |
| fullermd | Yah. Sometimes you do, sometimes you don't. | 19:00 |
| fullermd | Because revid alone is user-hostile. | 19:00 |
| dash | strk: a revision can appear in a bunch of different branches | 19:00 |
| dash | strk: and have a different revision number in each | 19:01 |
| dash | but the revid will be the same | 19:01 |
| strk | the id being the ugly loooking thing above ? | 19:02 |
| dash | right | 19:02 |
| strk | it says revision date, that's fine | 19:03 |
| fullermd | Not necessarily. | 19:03 |
| fullermd | All it says is <opaque string> | 19:03 |
| strk | mm, let's try to figure some use cases | 19:03 |
| strk | case 1: we check website to figure if the versions up there are the most recent revision from official trunk | 19:03 |
| fullermd | The ones bzr generates itself tend to include the committer and commit date, but that's happenstance. | 19:03 |
| strk | is "happenstance" an english word ? I always wondered how would I say that :) | 19:06 |
| fullermd | I hope so, otherwise I've confused a lot of people in my life :) | 19:06 |
| dash | it's an english word ;) | 19:07 |
| * strk can't wait to use that ! :P | 19:07 | |
| strk | case 2: a user reports a bug in the testcase and we use that id to check if that bug was fixed already | 19:08 |
| strk | I guess I'm out of cases | 19:08 |
| fullermd | There's certainly no lack of cases calling for it. | 19:09 |
| fullermd | The code that's recently in (or not in? Discussed a lot anyway) for line ending stuff is also intended to handle cases like keyword expansion. | 19:09 |
| strk | does it help if I jump in and put my vote ? :) | 19:10 |
| dash | Hmm | 19:13 |
| dash | is there an existing bzrlib method to determine if an URL specifies an existing branch? | 19:14 |
| dash | previously I was just going with: bzrlib.bzrdir.BzrDir.open() | 19:16 |
| dash | and expecting NotBranchError if it didn't exist | 19:17 |
| luks | Branch.open? | 19:18 |
| dash | hm | 19:18 |
| dash | that seems more reasonable. | 19:22 |
| === yacc_ is now known as yacc | ||
| === rockstar` is now known as rockstar | ||
| mwhudson | beuno: hi there | 22:18 |
| jelmer | Is Colin Bennett? | 22:40 |
| jelmer | Is Colin Bennett here? | 22:41 |
| === mw|out is now known as mw | ||
| beuno | mwhudson, mornin' | 22:49 |
| Verterok | hi | 23:22 |
| amanica | hi Verterok | 23:30 |
| lifeless | `moin | 23:36 |
| Verterok | mornin' lifeless | 23:36 |
| beuno | mornin' lifeless! back to AU time? | 23:36 |
| mwhudson | hi lifeless | 23:36 |
| lifeless | approximately | 23:36 |
| beuno | good, AU fits me better than european :) | 23:47 |
| igc | morning | 23:48 |
| beuno | mornin' igc | 23:48 |
| beuno | how are you today? | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!