| lifeless | does it say blackbox.test_diff, or bzrlib.tests.blackbox.test_diff ? | 00:00 |
|---|---|---|
| jfroy | Ah, it's working | 00:00 |
| jfroy | I, apparently, had not used the . :p | 00:00 |
| jfroy | * ./ | 00:00 |
| lifeless | :) | 00:00 |
| jfroy | ERROR: blackbox.test_export.TestExport.test_tar_export | 00:00 |
| jfroy | global name 'tests' is not defined | 00:00 |
| lifeless | try ./bzr selftest --no-plugins | 00:01 |
| lifeless | if that works, you have a plugin adding tests oddly | 00:02 |
| jfroy | Well if I'm running from a source distribution, would it still find any plug-ins? | 00:02 |
| lifeless | yes | 00:02 |
| jfroy | The system running those tests doesn't have any in ~/.bazaar | 00:02 |
| lifeless | ok | 00:02 |
| jfroy | but it does in the system-wide bzrlib | 00:03 |
| lifeless | this is windows? | 00:03 |
| jfroy | Mac OS X | 00:03 |
| lifeless | ok | 00:03 |
| lifeless | please try anyway | 00:03 |
| lifeless | './bzr selftest --no-plugins' | 00:03 |
| jfroy | looks good | 00:04 |
| jfroy | seems it does load system-wide plug-ins | 00:04 |
| jfroy | *eats his tongue* never mind | 00:04 |
| jfroy | same error | 00:05 |
| jfroy | well, maybe just bite :p | 00:05 |
| lifeless | ok | 00:05 |
| lifeless | what version ? | 00:06 |
| jfroy | 1.12 | 00:06 |
| jfroy | quite a few failures in blackbox.test_filesystem_cicp | 00:06 |
| lifeless | its odd that its only reporting 'blackbox..' rather than bzrlib.test.blackbox... | 00:06 |
| lifeless | it makes me think something has gone seriously wrong with module loading | 00:07 |
| lifeless | what python version ? | 00:07 |
| jfroy | 2.5.1 | 00:09 |
| jfroy | (apologies for the delay) | 00:10 |
| lifeless | vila: was that the bust version? | 00:14 |
| jfroy | So aside from that import error and the failures in filesystem_cicp it looks good so far | 00:20 |
| jfroy | Are those filesystem tests known failures on OS X? | 00:20 |
| james_w | lifeless: your extend_command patch ignores the "plugins_override" parameter that controls whether plugins should be able to override builtins. Is that the desired behaviour? | 00:20 |
| lifeless | james_w: yes | 00:21 |
| lifeless | james_w: because that patch doesn't support replacing commands at all | 00:21 |
| lifeless | jfroy: theres a buggy python on some mac os X's | 00:21 |
| lifeless | jfroy: bugs in the tarfile module, and somewhere else, IIRC | 00:22 |
| lifeless | abentley: on http://bundlebuggy.aaronbentley.com/request/%3C1235999150.10731.0.camel@flash%3E, it would be nice if the project: Bazaar link was to merge requests, and the actual project-meta-data was a link on the right | 00:28 |
| lifeless | abentley: just an oddity but I *always* click on Bazaar and end up where I don't want to be | 00:28 |
| lifeless | jelmer: has the network_name stuff been clear enough for you? | 00:40 |
| rocky | jelmer: hey, which branch of TracBzr should i use for trac 0.11.3 ? | 00:56 |
| jelmer | lifeless, is there any reason for not explicitly comparing that the various bits that make up a repository's stream ? | 00:59 |
| jelmer | rocky, sorry, I no longer follow trac-bzr development | 00:59 |
| jelmer | rocky, I've only been involved to the degree that we need it for bitlbee | 01:00 |
| rocky | jelmer: someone is the lead maintainer or it's simply not being maintained? | 01:00 |
| jelmer | rocky, I don't think there has been a maintainer for the past 2 years | 01:00 |
| rocky | ouch, that's too bad | 01:01 |
| jelmer | rocky, I have been doing some work keeping merging patches people put up until a couple of months ago | 01:02 |
| jelmer | s/keeping// | 01:02 |
| rocky | gotcha | 01:02 |
| jelmer | rocky: There's enough people interested in trac-bzr, there's just no maintainer atm | 01:03 |
| rocky | i need it for ClueMapper | 01:03 |
| rocky | i want to support bzr as the main repo format instead of svn under my trac | 01:03 |
| jelmer | rocky, would you be interested in stepping up as maintainer? | 01:05 |
| jelmer | rocky, It shouldn't be a lot of work, as there seem to be enough people proposing patches | 01:05 |
| jml | mwhudson: https://code.edge.launchpad.net/~jml/+junk/bzr-establish | 01:05 |
| mwhudson | thanks | 01:05 |
| jelmer | there just needs to be somebody to review and merge them | 01:05 |
| lifeless | jelmer: can you rephrase - 'explicitly comparing that the various bits that make up a repository's stream | 01:06 |
| lifeless | ' | 01:06 |
| rocky | jelmer: it's a possibility | 01:06 |
| mwhudson | jelmer: lp:~jelmer/bzr-git/jelmer, not lp:~jelmer/bzr-git/trunk, right? | 01:06 |
| jelmer | lifeless, so, rather than defining that repoformat X matches the network representation of repoformat Y, wouldn't it be possible to just compare the serializer format, inventory format, etc? | 01:07 |
| jelmer | lifeless, Not suggesting it should work that way, just wondering why it can't work that way? | 01:08 |
| jelmer | mwhudson, Yeah, http://people.samba.org/bzr/jelmer/bzr-git/trunk | 01:09 |
| jelmer | mwhudson, it requires bzr.dev atm | 01:10 |
| poolie | jam, if you're still here, is there any mysterious reason why http://pastebin.ubuntu.com/125544/ is not a valid simplification? | 01:10 |
| mwhudson | jelmer: ok | 01:10 |
| jml | mwhudson: http://code.mumak.net/2008/10/bazaar-hacking.html ; http://code.mumak.net/2008/10/more-bzr-hacking.html | 01:10 |
| lifeless | jelmer: su | 01:12 |
| lifeless | jelmer: 'so'. | 01:12 |
| lifeless | jelmer: two formats may have the same serialiser but still not want to behave identically | 01:12 |
| lifeless | jelmer: (format) is a complete encapsulation of behaviour, and works for things like bzr-svn that don't particularly even have serialisers | 01:13 |
| lifeless | jelmer: I think we do want to end up with a complete meta-description, but we're currently adding dimensions faster than verbs are keeping up, so using a format.network_name is future proofing until we're ahead of the curve and can lock-down the round trips for operations and eliminate teh vfs | 01:14 |
| jelmer | lifeless: ah | 01:14 |
| jelmer | lifeless: That makes sense to me | 01:14 |
| jelmer | lifeless, so | 01:14 |
| jelmer | lifeless, bb:approve | 01:15 |
| nevans | I accidentally rebased a branch, and now I want to get back the original. what would be the easiest way to find the tip revision ID for the original? | 01:15 |
| jelmer | lifeless, as this was the only bit I wasn't sure about | 01:15 |
| lifeless | jelmer: well, its all landed :P I was more asking because we have the room to change things if it was interacting badly with bzr svn | 01:15 |
| james_w | nevans: "bzr heads" from bzrtools will help | 01:15 |
| jelmer | lifeless, ahh | 01:15 |
| nevans | bzr heads is taking forever to return... is there some way to point it at the last common revision, and tell me only the descendants of that? | 01:15 |
| lifeless | jelmer: I have no desire to make your task *harder* :P | 01:16 |
| jelmer | lifeless, it shouldn't affect bzr-svn unless you're pushing from a svn repository to a smart server right? | 01:16 |
| nevans | BTW: as an aside, I really like how "bzr uncommit" gives you the original revision id right before it does its work. ;) | 01:17 |
| lifeless | jelmer: or pulling from a smart server with svn behind it | 01:17 |
| lifeless | jelmer: so you have several things you can do; you could: | 01:18 |
| lifeless | - return a network_name of a bzr native format [where you claim that your streaming data is that format, and that cloning should create that format] | 01:18 |
| lifeless | - return a unique network_name [where both ends will need bzr-svn installed, but you can potentially stream in a optimised form] | 01:18 |
| jelmer | I can't really do (1) sensibly | 01:20 |
| jelmer | since it will mean things using Repository.{texts,inventories,revisions} a lot | 01:20 |
| lifeless | ok | 01:22 |
| * mwhudson gets the feeling he's doing it wrong | 01:22 | |
| mwhudson | bzr: ERROR: No such file: u'/home/mwh/src/git-play/.git/inventory': [Errno 2] No such file or directory: u'/home/mwh/src/git-play/.git/inventory' | 01:22 |
| lifeless | note that pushing from a svn workingtree to a hpss smart server is probably not that common :) | 01:22 |
| jelmer | mwhudson, bzr-git doesn't support working trees yet | 01:22 |
| jelmer | lifeless, I've seen people do it :-) | 01:22 |
| lifeless | mwhudson: its not finished :) | 01:22 |
| mwhudson | i guess i should read the README | 01:23 |
| mwhudson | jelmer: how can i make it do something interesting? | 01:23 |
| lifeless | jelmer: ok; so we can either say 'install bzr-svn on the server' (for 2), or perhaps have a bzr-svn-light that has just the Format objects, no actual capabilities. | 01:23 |
| jelmer | mwhudson, bzr.dev branch git://git.kitenet.net/etckeeper | 01:24 |
| jelmer | lifeless, there's no fallback scenario in case the network format the server offers isn't supported by the client? | 01:25 |
| jelmer | no *generic* fallback scenario | 01:25 |
| lifeless | jelmer: no | 01:26 |
| lifeless | jelmer: you wanted to avoid people creating branches on the server the server can't open; this does that :) | 01:27 |
| mwhudson | jelmer: eh, i thought network support was flaky, did i get the wrong end of the stick | 01:27 |
| mwhudson | anyway, seems to be working, yay | 01:27 |
| jelmer | mwhudson, pull is the main thing that's flaky | 01:28 |
| mwhudson | jelmer: ok | 01:29 |
| jelmer | lifeless, well, if the server understands the format a branch is stored in, it could always send it to the client in some generic format that the client udnersatnds | 01:29 |
| jelmer | mwhudson, please do file bugs for things you find don't work or don't work well | 01:29 |
| jelmer | lifeless, can you explain the bzr-svn-light thing a bit perhaps? | 01:29 |
| mwhudson | jelmer: how do you use a dev version of dulwich out of curiosity? just set $PYTHONPATH | 01:30 |
| jelmer | mwhudson, yeah | 01:30 |
| mwhudson | fair enough | 01:31 |
| jelmer | lifeless, did apt-get find python-subvertpy for you btw? | 01:32 |
| mwhudson | jelmer: well for starters, bzr init; bzr pull git:// breaks nastily :) | 01:32 |
| mwhudson | init --1.9-rich-root is fine though | 01:32 |
| jelmer | mwhudson, whoops | 01:34 |
| lifeless | jelmer: no | 01:34 |
| * jelmer gets some sleep | 01:35 | |
| lifeless | jelmer: so, generic formats - yes, we could write a mapping table that says '1.9 is the same as 1.6' | 01:35 |
| lifeless | jelmer: and if we tell the client about a format it doesn't understand, it could ask us to translate somehow | 01:36 |
| lifeless | jelmer: and similarly client -> server | 01:36 |
| jelmer | lifeless, yeah, that's what I meant | 01:36 |
| lifeless | jelmer: however, option (2) doesn't have a mapping from 'svn' to 'bzr' at all at the moment:P | 01:36 |
| jelmer | ah, in that sense | 01:37 |
| jelmer | lifeless, tunneling svn over bzr | 01:37 |
| lifeless | jelmer: spiv and I discussed doing this if its needed, but right now there is simply no way to work with a format not mutually known | 01:37 |
| lifeless | jelmer: so we felt it was ok to not-improve-the-situation | 01:37 |
| jelmer | lifeless: Yeah, I agree | 01:38 |
| lifeless | jelmer: go sleep. doing some testing might be good if you get the chance | 01:38 |
| lifeless | if we're wrong and it it suddenly problematic, we have 1.5 weeks to get a solution for the beta | 01:38 |
| nevans | still waiting for "bzr heads" to respond with anything... in the meantime, I've managed to open a python console and get the base revision before the rebase. | 01:43 |
| rocky | jelmer: functionally, if i point repository_dir to some random dir that contained repos that contained various branches.... trac should "think" that the random dir is the base repo right? (for TracBzr) | 01:43 |
| nevans | is there any way for me to use the Revision object to tell me its children | 01:43 |
| nevans | (I'm very much a python newb) | 01:43 |
| jelmer | nevans, fwiw bzr-rebase will store the revid of the revision it is a rebase of | 01:44 |
| nevans | jelmer: o rly? :) | 01:44 |
| jelmer | nevans, in the 'rebase-of' revision property | 01:44 |
| nevans | too easy. :) | 01:44 |
| jelmer | nevans, it's not exposed in the UI, but there under the covers | 01:45 |
| nevans | how do I retrieve the revision properties? | 01:45 |
| jelmer | rocky, I think some people reported that that bit was broken | 01:45 |
| jelmer | rocky, It seemed to be having trouble using more than one bzr repository | 01:46 |
| jelmer | rocky, but multiple branches would be fine | 01:46 |
| jelmer | rocky, at least that's what I remember reading | 01:46 |
| jelmer | nevans, If you have a Revision object, it has a 'properties' member | 01:47 |
| jelmer | nevans, Repository.get_revision("some-revid").properties["rebase-of"] | 01:47 |
| rocky | jelmer: most trac projects i work with don't really correspond to the lightweight notion of bzr repos... since my trac projects consist of more than one code component and each code component really should get it's own bzr repo | 01:47 |
| lifeless | nevans: revision.parent_ids | 01:47 |
| rocky | so i guess the multiple repo thing is something that "fits me" | 01:47 |
| jelmer | rocky, are you talking about a bzr repo or a bzr branch? | 01:47 |
| nevans | jelmer: thanks. that does it! :) | 01:48 |
| rocky | jelmer: well, i have the ClueMapper "project" where it has it's own trac site ... but that project has 5 different libraries that all relate to one another conceptually ... so it seems to me each library should get it's own repo | 01:49 |
| rocky | and then each library (which has it's own repo) has it's own trunk and various branches | 01:49 |
| rocky | any decent-size project i work on is like that | 01:49 |
| rocky | jelmer: so if i call tree.inventory.path2id('') then bzr returns me None if the root of the branch has no files? that seems, odd | 02:09 |
| lifeless | rocky: two trees A and B that are both for different projects have different root ids | 02:23 |
| lifeless | rocky: at some point between 'null tree', 'new tree' and 'first commit' the id has to be set | 02:24 |
| lifeless | rocky: bzr chose to do it at 'bzr add' in the new tree | 02:24 |
| rocky | ah | 02:24 |
| rocky | lifeless: i'm using launchapd branches for the first time and when i try to push my local branch to a launchpad branch that i just registered it gives on odd error saying the target branch exists but doesn't have a valid .bzr directory ... is that normal? | 02:29 |
| lifeless | mwhudson: ^ | 02:30 |
| mwhudson | rocky: push --use-existing-dir probably? | 02:30 |
| mwhudson | rocky: but in general, don't register hosted branches in the ui :/ | 02:31 |
| rocky | lol | 02:31 |
| jam | poolie: http://pastebin.ubuntu.com/125544/ seems fine to me | 02:31 |
| rockstar | rocky, seriously, it's best to just push to Launchpad. | 02:32 |
| rocky | rockstar: sure, i will from now on... but i was just following the logical path to do what i needed, so i guess something needs some work there ;) | 02:34 |
| lifeless | rocky: yah, it needs to be deleted :) | 02:34 |
| rocky | hehe | 02:34 |
| rocky | whatever works ;) | 02:34 |
| rocky | anyways, bedtime for me | 02:34 |
| rocky | night | 02:34 |
| lifeless | gnight | 02:34 |
| poolie | thanks jam | 02:53 |
| poolie | and thanks for the reviews | 02:53 |
| mwhudson | dulwich and bzr-git require python 2.5 ? | 03:01 |
| * mwhudson sads | 03:01 | |
| johnf | I'm upgrading my smart server to 1.12. I'm currently running it out of fcgi. Does this still work or should I be using bzr --serve? | 03:02 |
| poolie | johnf: hi; afaik it should still work; spiv should know | 03:03 |
| lifeless | johnf: it should still work | 03:03 |
| lifeless | johnf: please tell us if it doesn't :) | 03:03 |
| johnf | Might switch to serve and cook up an init script for the debian package | 03:03 |
| igc | igc | 03:04 |
| igc | is back | 03:04 |
| lifeless | hi igc | 03:05 |
| lifeless | johnf: FWIW most folk run over bzr+ssh i think | 03:05 |
| poolie | hello igc | 03:05 |
| lifeless | johnf: afc runs a live server with --serve, on the internet. He may have a script. | 03:05 |
| spiv | johnf: what poolie and lifeless said. | 03:13 |
| johnf | spiv: I'm going to move to --serve the fcgi was a pain | 03:13 |
| spiv | Fair enough. | 03:14 |
| spiv | Which HTTP server? Apache? | 03:14 |
| johnf | yes. Going to use mod_proxy | 03:16 |
| lifeless | erem | 03:16 |
| lifeless | johnf: --serve isn't http | 03:16 |
| poolie | lifeless: did you also say something similar to https://bugs.edge.launchpad.net/bzr/+bug/322893 | 03:17 |
| ubottu | Launchpad bug 322893 in bzr "new progress bars only use 80 columns" [Medium,Confirmed] | 03:17 |
| johnf | lifeless: ahh :) | 03:17 |
| lifeless | johnf: --serve is 'bzr://'. IANA registered protocol. | 03:17 |
| johnf | ok back to fcgi then :) | 03:18 |
| lifeless | johnf: if you want bzr-over-http, you need mod_python or fcgi or whatever | 03:18 |
| lifeless | johnf: you don't need to do bzr-over-http | 03:18 |
| lifeless | poolie: yes, I did | 03:18 |
| lifeless | poolie: I also filed a bug about comment truncating | 03:18 |
| johnf | lifeless: yeah pondering connecting to it directly at the moment | 03:19 |
| === Toksyuryel` is now known as Toksyuryel | ||
| johnf | should "bzr serve" be logging a whole heap of NotImplemented errors? Works fine but is logging errors | 04:34 |
| poolie | probably not | 04:34 |
| poolie | like what? | 04:34 |
| jml | hello | 04:42 |
| poolie | hi | 04:42 |
| jml | [- ] Transferring:Walking content. 0/36 | 04:42 |
| poolie | :-} | 04:43 |
| jml | I've been pushing up a branch to Launchpad for about 421.534s now | 04:43 |
| poolie | srsl? | 04:43 |
| poolie | got a trace? | 04:43 |
| jml | yes. | 04:43 |
| jml | poolie: I've got the bzr log | 04:43 |
| jml | poolie: and I'm running with -Dhpss | 04:43 |
| poolie | show spiv/lifeless? | 04:44 |
| lifeless | jml: version? | 04:45 |
| jml | http://paste.ubuntu.com/125595/ | 04:45 |
| jml | Bazaar (bzr) 1.13dev | 04:45 |
| lifeless | johnf: its a bug, fixed in bzr.dev | 04:45 |
| jml | from the nightly ppa | 04:45 |
| lifeless | jml: revno please | 04:45 |
| lifeless | jml: the full package version has the revno in it | 04:46 |
| jml | (bzr version should tell me the revno, don't you think?) | 04:46 |
| jml | Version: 1.13~bzr8.10-4065-1 | 04:46 |
| lifeless | jml: (maybe, file a bug on the packaging) | 04:46 |
| jml | it's still going, fwiw. | 04:48 |
| jml | ok, now it's done | 04:49 |
| lifeless | jml: it was reading from 186.818 hpss call w/readv: 'readv', '/~launchpad-pqm/launchpad/devel/.bzr/repository/packs/fee0993f46df016a5650a9004f0f4fdf.pack' | 04:51 |
| lifeless | and writing to | 04:51 |
| lifeless | 187.201 hpss call w/body: 'append', '/~jml/launchpad/source-package-branch-listing/.bzr/repository/upload/05wh3tplu93ue19c02ok.pack', | 04:51 |
| lifeless | jml: I suspect it was filing in missing deltas for files you modified the first time | 04:52 |
| fignewman | This is probably a stupid question, but I can't find an answer. I'm using bzr in a simple centralized manner (checkout/commit) and I can't find a command similar to subversion's 'svn st -u' (that is, I want to see what has changed upstream since I last updated) | 04:52 |
| lifeless | fignewman: bzr missing | 04:52 |
| jml | lifeless: that's quite possible. | 04:52 |
| lifeless | jml: so, this is because the streaming code path precludes the pack optimised one, which really is quite fast; we're using the public generic interface to stream | 04:53 |
| jml | lifeless: I know what all of those words mean. | 04:53 |
| lifeless | jml: -> should be faster on bzr.dev servers, but some possibilities of slower on downlevel smart servers | 04:53 |
| fignewman | lifeless: thanks. It's complaining, but I think I know why. | 04:56 |
| fignewman | lifeless: would be nice if it defaulted to the branch when using a checkout. | 04:57 |
| lifeless | fignewman: possibly;possibly we should do status -u for this case | 04:57 |
| lifeless | fignewman: our checkouts are also branches (in that they are a checkout of a branch) | 04:58 |
| fignewman | lifeless: is there a way to set a default or should I just use an alias? | 05:01 |
| lifeless | fignewman: there may be a canned alias like :master, not sure though | 05:02 |
| lifeless | fignewman: you can just do missing --remember | 05:02 |
| poolie | jml, i got a tuit to make a debug_flags config option | 05:02 |
| johnf | lifeless: if I set post_commit_to in ~/.bazaar/bazaar.conf in the [DEFAULT] section should bzr-email work for all branches? | 05:03 |
| lifeless | johnf: yes | 05:04 |
| jml | poolie: what for? | 05:04 |
| poolie | so people can always capture hpss logs rather than needing to remember it | 05:05 |
| poolie | i guess you can use a shell alias | 05:05 |
| === eMBee_ is now known as eMBee | ||
| fignewman | lifeless: --remember doesn't seem to be in my version (1.3.1). For all I know, my issue was long ago resolved anyway. Thanks for the help. This will work nicely. | 05:06 |
| lifeless | poolie: you can't pass debug_flags to a smart server | 05:08 |
| lifeless | poolie: it would be nice to put them in branch.conf and have it just work :) | 05:08 |
| poolie | lifeless: when it's run over ssh you mean? | 05:09 |
| poolie | i think what i'm doing will make it read them from ~/.bazaar/bazaar.conf on the server | 05:09 |
| lifeless | ok | 05:09 |
| lifeless | thats a start :) | 05:09 |
| jml | poolie: oh, cool. | 05:09 |
| poolie | starts are good :) | 05:09 |
| jml | poolie: well, I have -Dhpss | 05:09 |
| jml | as an alias. | 05:09 |
| jml | poolie: but that sounds like a great idea. | 05:10 |
| johnf | lifeless: for bzr-email when the hook runs under bzr serve the op type seems to be "change" instead of "commit" does that make sense? | 05:24 |
| lifeless | johnf: yes. Possibly a bug, but probably just de riguer | 05:25 |
| johnf | what is a change vs a commit. Should I patch bzr-email to also send email on change or work out why it's change instead of commit? | 05:28 |
| lifeless | johnf: change is uncommit/push/pull | 05:29 |
| lifeless | johnf: commit is commit | 05:29 |
| lifeless | johnf: have you read 'bzr help email' ? | 05:29 |
| johnf | yes | 05:29 |
| lifeless | it can send mail on change | 05:29 |
| lifeless | what bzr-email version do you have? | 05:29 |
| johnf | trunk. But the thing is I'm performing a commit not a push. or does a commit become a push over bzr:// ? | 05:30 |
| lifeless | johnf: it becomes a push | 05:32 |
| lifeless | two-phase commit thingy | 05:32 |
| johnf | ahh ok I'll set post_commit_push_pull then | 05:33 |
| johnf | you want a patch for the docs to make that more obvious? | 05:33 |
| johnf | or would a patch for bzr-email to detect it's running in server mode make more sense? | 05:33 |
| lifeless | feel free to make it as lovely as possible | 05:34 |
| lifeless | I don't know offhand how easy it will be | 05:34 |
| * igc offline for ~ 2 hours | 05:35 | |
| poolie | [rfc] rename TestCase.get_transport to something like get_test_transport, because it's not interchangeable | 05:37 |
| lifeless | poolie: mmm, it could detect absolute urls, but we shouldn't really be using those in tests *anyway* | 05:38 |
| poolie | detect them and error? | 05:38 |
| poolie | i guess | 05:38 |
| poolie | well, actually we commonly do if we have a url from somewhere else | 05:39 |
| poolie | foo.base for example | 05:39 |
| lifeless | well, we have foo then :) - is this something you're running into repeatedly? | 05:41 |
| johnf | any easy way to work out from a plugin if you are running in server mode? | 05:43 |
| lifeless | johnf: 16:30 < lifeless> I don't know offhand how easy it will be | 05:46 |
| johnf | lifeless: heh I'm going to try for the server_started hook | 05:46 |
| johnf | although I have a feeling I won't get the callback | 05:47 |
| lifeless | spiv: arrrgh test_stacking failing, sometimes, if you run a specific test before it | 07:01 |
| vila | hi all | 07:15 |
| johnf | is there a way to get the path to the repo from the branch object? ie if it is chroot-1244:///devel/test I want '/devel/test' | 07:45 |
| johnf | or do I just need to regex on branch.base? | 07:46 |
| lifeless | its a software chroot | 07:51 |
| lifeless | look at bzrlib.transport.chroot | 07:51 |
| lifeless | but! | 07:51 |
| lifeless | what you probably want is branch.public_location() or whatever | 07:52 |
| johnf | lifeless: yeah I'm hacking the public_branch functionality. I adding public_branch_prefix which gets put on the front of everything served by the server | 07:53 |
| lifeless | johnf: why do you want the repo at all though | 07:55 |
| johnf | as in why am I running a server vs bzr+ssh? | 07:56 |
| lifeless | no | 07:56 |
| lifeless | as in why do you want the repo at all | 07:56 |
| johnf | as in why do I want a central code repository? | 07:57 |
| lifeless | no | 07:57 |
| lifeless | you said you wanted the path to the repo - /devel/test; thats not usable in the general case by clients, its not relevant for bzr commands, it doesn't really have any use. | 07:57 |
| lifeless | so I assume you have a larger use case | 07:59 |
| johnf | for the email in bzr-email. ie right now the email is displaying chroot-123:///devel/test or for other branches in that repo chroot-234:///devel/website | 07:59 |
| lifeless | and I'd like to know what it is | 07:59 |
| lifeless | johnf: branch.public_location() -> print that | 07:59 |
| johnf | ie multiple branches serverd by the same "bzr server" | 07:59 |
| lifeless | johnf: if thats wrong, the server admin can fix it by configuring in branch.conf or locations.conf | 07:59 |
| lifeless | its the same problem as a backend webserver with a squid frontend:) | 08:00 |
| lifeless | you have to tell the backend somehow where clients are coming into it from | 08:01 |
| johnf | doesn't that assume I set public_location for every branch? | 08:01 |
| lifeless | yes, so - if its not there assume branch.base is sane IMO. | 08:02 |
| lifeless | as an admin you can set it for all served branches with three lines in locations.conf | 08:02 |
| johnf | once per branch or globally for all? | 08:02 |
| lifeless | for all | 08:02 |
| johnf | ahh that's what I want let me go look that up | 08:03 |
| johnf | lifeless: hmm what would I be setting in locations.conf? | 08:06 |
| lifeless | in theory; note that you may have found a bug/current limitation - we need more adopters of server side stuff! | 08:07 |
| lifeless | [file:///srv/bzr/blah/blah] | 08:07 |
| lifeless | public_branch:policy = appendpath | 08:08 |
| lifeless | public_branch = bzr://host | 08:08 |
| lifeless | then .../blah/blah/b1 | 08:08 |
| lifeless | will get | 08:08 |
| lifeless | bzr://host/b1 as its public url | 08:08 |
| lifeless | for instance, I have: | 08:08 |
| lifeless | [sftp://bazaar.launchpad.net/%7Ebzr/] | 08:08 |
| lifeless | public_branch = http://bazaar.launchpad.net/~bzr/ | 08:08 |
| lifeless | public_branch:policy = appendpath | 08:08 |
| lifeless | "everything I push to lp/~bzr is visible on http://.../~bzr | 08:09 |
| johnf | ok let me give it a whirl | 08:09 |
| lifeless | the transport chroot may break it | 08:09 |
| lifeless | if so file a bug | 08:09 |
| lifeless | but thats the _right_ solution | 08:09 |
| johnf | and then that should appear in branch.get_public_branch() ? | 08:10 |
| lifeless | yes | 08:10 |
| lifeless | woo, finally landed that branch | 09:04 |
| lifeless | I thought it would never give in and succeed | 09:05 |
| johnf | lifeless: just sent you a review request. I have a feeling the way I store wether we are in server mode is a bit of a hack. But my python skills are lacking | 09:15 |
| lifeless | johnf: thanks | 09:23 |
| johnf | I also have a patch for the locations.conf chroot problem. But I'm trying to find a less hacky solution | 09:24 |
| johnf | At the moment I convert chroot-12345:///devel/test into /devel/test which means you can match it using [/] in locations.conf | 09:25 |
| lifeless | I would teach the location config handler that a chroot transport is to be unchrooted, then looked up | 09:25 |
| johnf | I'd really like to get at the non-croot path so I could turn the chroot into /srv/bzr/devel/test and match using [/srv/bzr] | 09:25 |
| lifeless | keep Branch ignorant of that | 09:25 |
| johnf | in config.py? | 09:26 |
| johnf | that's where I've been hacking so far. it;s the unchrooting from there that is the trick | 09:26 |
| lifeless | bzrlib.transport.chroot | 09:27 |
| lifeless | look in there | 09:27 |
| crisb | hi, i've got a problem with my bzr where if I do a second commit I get a SHA1KnitCorrupt error - anyone had this before? | 09:37 |
| lifeless | no | 09:40 |
| lifeless | what bzr version? | 09:40 |
| crisb | 1.12 | 09:40 |
| lifeless | are you on nfs/ftp/sftp? | 09:40 |
| crisb | its a branch I got via sftp yeah | 09:41 |
| lifeless | does 'bzr check' pass on it? | 09:42 |
| crisb | with flying colours | 09:48 |
| lifeless | unusual :P | 09:49 |
| lifeless | uhm, what does bzr info -v report ? | 09:49 |
| crisb | http://pastebin.com/m35a6a43c | 09:50 |
| Kamping_Kaiser | can someone explain why i have bzr looking for an svn cache? | 09:50 |
| Kamping_Kaiser | bzr status | 09:50 |
| Kamping_Kaiser | Initialising Subversion metadata cache in /home/kgoetz/.bazaar/svn-cache/d35b4800-ec1a-0410-b8e8-ae9f3643f637 | 09:50 |
| Kamping_Kaiser | is this a bug, or a feature i've not noticed before? | 09:50 |
| lifeless | Kamping_Kaiser: you have bzr-svn installed, and have run bzr in a svn checkout | 09:51 |
| lifeless | Kamping_Kaiser: its doing just in time translation of metadata | 09:51 |
| Kamping_Kaiser | lifeless, aaah, that explains it. (i only installed bzr-svn recently). thanks for telling me - i'd forgotten this was an svn dir *heh* | 09:52 |
| lifeless | Kamping_Kaiser: that is the idea :) | 09:52 |
| lifeless | crisb: this is very odd | 09:52 |
| lifeless | crisb: unfortunately its late for me; could you file a bug? | 09:52 |
| * Kamping_Kaiser tries it out. | 09:52 | |
| lifeless | you should get a backtrace in ~/.bzr.log , that backtrace with the version details and so on would be very useful | 09:52 |
| crisb | lifeless: sure. its strange I've tried it on another machine with python2.5.2/bzr 1.11 and all ok. the branch is taken from a machine with bzr-1.12/python2.6.1 | 09:54 |
| lifeless | crisb: none of those raise alarm bells | 09:54 |
| lifeless | crisb: and check dos a scan of all the texts that could be failing | 09:54 |
| crisb | lifeless: bzr check fails as soon as I've done the first commit after branching | 09:56 |
| crisb | the sha1 that is corrupt is the one of the last revision | 09:57 |
| lifeless | crisb: its fascinating, and AFAIK unique, but I have to halt() | 09:58 |
| lifeless | crisb: sorry | 09:58 |
| lifeless | jam: vila: either of you might like to look at this ? ^ | 09:59 |
| crisb | lifeless np ;) | 10:00 |
| crisb | about halting that is! | 10:00 |
| johnf | lifeless: just to confirm the functionality. If I have a location of [/srv/bzr] and I have append policy with public_branch = http://bzr.com/ then if a banch lives at /srv/bzr/project/trunk then the public url should be http://bzr.com/project/trunk | 10:06 |
| vila | crisb: Did you file a bug already ? | 10:09 |
| crisb | vila: not yet I was just fiddling around a bit more | 10:11 |
| vila | crisb: ok, Di you try bzr check just after branching ? And what bzr version do you use on the machine where the bug is occurring ? | 10:11 |
| crisb | bzr check just after branching is fine, its bzr 1.12 | 10:12 |
| vila | crisb: OS ? | 10:12 |
| crisb | vila: linux | 10:12 |
| vila | crisb: installed from the PPA or from sources ? | 10:12 |
| crisb | crisb: its the bzr package which I (mostly) maintain! its mandriva, and built from the official tar ball | 10:13 |
| crisb | vila: even lol | 10:13 |
| crisb | history is its a import from CVS using cvsps-import. the import was done on another machine with 1.11 | 10:14 |
| vila | crisb: Ha ! Mandriva, sorry, didn't match earlier :-/ Help me page in the context, ... yeah that way :) | 10:14 |
| vila | crisb: did you run the full test suite successfully ? | 10:15 |
| crisb | vila: :( | 10:15 |
| crisb | good call, its totally failing today! | 10:16 |
| vila | crisb: let's start with that, can you file a bug and attach the selftest output ? | 10:17 |
| vila | crisb: try to mention python version, and also versions for supporting libraries like pycurl or paramiko | 10:17 |
| crisb | vila: its probably my fault ;) i also package python-pycrypto.....added a little patch for py2.6 ;) | 10:23 |
| vila | crisb: np, let us know if you can fix it or how we could help | 10:24 |
| crisb | vila: is pycrypto used for sha-1 calcs? | 10:40 |
| vila | crisb: I don't think so, but it's used by paramiko and we use paramiko for sftp | 10:42 |
| crisb | vila: think my patch is ok then...blackbox.test_aliases.TestAliases.test_aliases shouldnt use pycrypto | 10:43 |
| vila | crisb: err, I miss context to follow you there :) | 10:44 |
| crisb | vila: that test fails with sha-1 of reconstructed text does not match expected sha-1, but should not touch any code changed by my pycrypto patch right? | 10:46 |
| vila | I'm not familiar enough with pycrypto to be definitive here, it may populate some methods that override the ones we use for example | 10:47 |
| vila | crisb: you can run 'bzr selftest -s bb.test_aliases.TestAliases.test_aliases' with and without your patch to check that | 10:47 |
| vila | crisb: using '-s' is really faster in these cases | 10:48 |
| crisb | http://pastebin.com/m488db1d9 | 10:50 |
| crisb | vila: same with and without patch | 10:50 |
| vila | crisb: can you try on a 32bits machine with the same config ? | 10:52 |
| aboSamoor | I want to commit to my repo from another PC, what I have to do ? | 10:53 |
| vila | aboSamoor: how are the two PCs connected ? How can your branch (which use a repo but is not a repo) accesible from the other PC ? | 10:55 |
| aboSamoor | vila: I have a launchpad account and I commit using my laptop. I branched it in my PC but I can not commit I got Public Key denied. I did not do anything other than branching. | 10:57 |
| crisb | vila: passes on 32-bit | 10:57 |
| vila | crisb: here we are :-/ | 10:57 |
| vila | crisb: can you file a bug ? | 10:57 |
| crisb | vila: sure. | 10:58 |
| crisb | vila: seems unlikely that no bzr developers use 64-bit though? | 10:59 |
| vila | crisb: with python2.6 ? | 10:59 |
| vila | crisb: I try to test many combinations, but I lacked that one, I have 32bits/2.[456] and 64bits/2.5 myself + OSX 10.4 but I've yet to automate that... | 11:00 |
| vila | I'm setting up 64bits/python2.6 right now, but until I make a diagnosis there, that sounds a lot like a python bug, we shouldn't have to take care of that... | 11:01 |
| lifeless | [getting a drink] try removing the .so files in bzrlib/ | 11:02 |
| crisb | vila: i swear this has been working :| | 11:02 |
| lifeless | johnf: yes; its in the docs that this works too :) | 11:03 |
| lifeless | johnf: bzr help configuration | 11:03 |
| vila | crisb: that's what bugs are about :) | 11:03 |
| lifeless | [gone again] | 11:03 |
| Coke | One file was locally removed, how do I update just that file from the remote branch? | 11:07 |
| luks | bzr revert it | 11:07 |
| vila | crisb: by the way, can you do the same tests with python2.5 ? 32 and 64 ? | 11:08 |
| Coke | Oh | 11:08 |
| Coke | that is so ugly | 11:08 |
| Coke | what happens if one file is deleted, some other are changed and I do revert on that directory? all changed files reverted to? | 11:08 |
| luks | revert just the specific file | 11:09 |
| luks | bzr revert my/removed/file.c | 11:10 |
| crisb | vila: 337183 | 11:12 |
| vila | crisb: ask ubottu instead #337183 | 11:12 |
| vila | huh ? bug #337183 | 11:12 |
| ubottu | Launchpad bug 337183 in bzr "tests fail with sha-1 corrupt on bzr-1.12/python2.6 64-bit" [Undecided,New] https://launchpad.net/bugs/337183 | 11:12 |
| vila | thanks | 11:12 |
| crisb | vila: have a sneaky feeling 1.11 was ok | 11:14 |
| vila | crisb: you used 2.6 with bzr-1.11 ? | 11:15 |
| crisb | yeah | 11:15 |
| vila | crisb: do you have 2.5 available on your 32/64 machines ? | 11:15 |
| crisb | no unfortunately :( i've tried 1.11 on a 32-bit machine with py2.5 | 11:16 |
| vila | crisb: hmm, no 1.11/2.6/64bit where you can run 'bzr selftest -s bb.test_aliases.TestAliases.test_aliases' ? | 11:17 |
| vila | crisb: in fact we are in kind of opposite configs :-) I have to build 2.6 from source... | 11:19 |
| crisb | heheh | 11:20 |
| crisb | i can try to get a 1.11 | 11:20 |
| crisb | vila: bzr's fault ;) | 11:27 |
| crisb | vila: at least it proves i'm not going mad! | 11:28 |
| vila | crisb: by that you mean you ran 'bzr selftest -s bb.test_aliases.TestAliases.test_aliases' on 1.11/2.6/64bit machine ? | 11:28 |
| vila | and it passed ? | 11:28 |
| crisb | vila: yep, straight off | 11:30 |
| lifeless | crisb: did you try removing the .so's ? | 11:31 |
| crisb | lifeless: bzr extension so's? no. | 11:32 |
| lifeless | try then :) | 11:34 |
| vila | lifeless: sorry I thought you were talking to johnf, what do you have in mind with the so ? | 11:34 |
| lifeless | vila: removing them | 11:34 |
| vila | lol | 11:34 |
| lifeless | vila: eliminates non-python code | 11:35 |
| vila | crisb: I can't reproduce here with bzr.dev python 2.6 built from sources, no bzr extensions so far | 11:36 |
| vila | crisb: correction, I have bzr extensions | 11:36 |
| lifeless | also note that all of ubuntu's devs are on 1.12 now | 11:37 |
| lifeless | sorry | 11:37 |
| lifeless | I mean 2.6 | 11:37 |
| lifeless | so we should be seeing this very widespread | 11:37 |
| vila | lifeless: with jaunty ? | 11:37 |
| lifeless | yes | 11:37 |
| crisb | vila: ok so now its weird, i've just reinstalled bzr 1.12 RPM and all is fine.... | 11:39 |
| vila | crisb's fault :-) | 11:41 |
| crisb | vila: it always is! lots of bugs here | 11:41 |
| vila | crisb: np, better safe than sorry | 11:42 |
| vila | crisb: Can I mark #337183 as invalid or do you intend to try harder to make it fail again ? ;) | 11:42 |
| crisb | vila: lets invalidate it, not sure what I can do to reproduce. apologies for the waste of your time | 11:44 |
| vila | crisb: np, helping users is never a waste of my time | 11:44 |
| crisb | can I get a diff of revision 1-4 without 3 somehow? | 12:40 |
| rocky | lifeless: don't suppose you know the easiest way to get the ancestry of a particular file id ? | 14:04 |
| rocky | apparently workingtree used to have a private _get_weave() method that could then get the ancestry from | 14:05 |
| james_w | rocky: you mean the list of revisions that touched a particular file id? | 14:07 |
| rocky | james_w: maybe... i'm trying to work with someone elses code that used self.tree._get_weave(file_id).get_ancestry(rev) | 14:08 |
| rocky | _get_weave doesn't exist anymore it seems | 14:08 |
| james_w | ah | 14:09 |
| james_w | I'm not sure exactly what replaced it | 14:09 |
| james_w | or even what that did, sorry | 14:09 |
| james_w | rocky: I think you need to go through VersionedFile now | 14:10 |
| rbriggsatuiowa | is there a way to get merge to tell me what revisions it is merging in? | 14:10 |
| rocky | james_w: if i have the repo and branch for the file_id, what's the stndard way to get the VersionedFile obj? | 14:11 |
| rocky | dir() yields me a bit too much ;) | 14:11 |
| james_w | rocky: not, sure, never done it :-) | 14:11 |
| james_w | repository.revisions | 14:12 |
| james_w | that gives you a VersionedFiles | 14:14 |
| RaceCondition | how do I convert a git repository to a bzr one? | 14:15 |
| RaceCondition | while keeping the history | 14:15 |
| Lo-lan-do | RaceCondition: There's a bzr-git plugin, but it's not complete yet. | 14:16 |
| RaceCondition | so it's not possible yet? | 14:17 |
| Lo-lan-do | It should be possible for one-time migrations. | 14:18 |
| Lo-lan-do | I wrote http://lists.fusionforge.org/pipermail/fusionforge-general/2009-January/000004.html which has a section on bzr/git interoperability. | 14:18 |
| Lo-lan-do | But there's been some activity on bzr-git lately, so hopefully it'll reach its full feature set soonish :-) | 14:19 |
| james_w | rocky: yeah, not sure, it's not obvious to me that VersionedFiles exposes the per-file graph like that | 14:20 |
| RaceCondition | Lo-lan-do: a one-time migration is what I need | 14:20 |
| RaceCondition | I could simply lose all the history too without much problem though | 14:20 |
| Lo-lan-do | RaceCondition: Then bzr-git should work. | 14:21 |
| RaceCondition | Lo-lan-do: OK, thanks | 14:21 |
| vila | jam: ping | 14:38 |
| vila | jam: when is CHKMap.iter_changes() used ? | 14:38 |
| jam | morning vila | 14:39 |
| jam | whenever someone feels like it, I guess :) | 14:39 |
| jam | I think it is used as a custom InterTree method | 14:39 |
| vila | :-) | 14:39 |
| jam | for CHKRevisionTree.iter_changes() | 14:39 |
| vila | ENOTFOUND | 14:40 |
| jam | vila: CHKinventory.iter_changes() calls down to self.id_to_entry.iter_changes() | 14:42 |
| Kobaz | yeah | 14:42 |
| Kobaz | er | 14:42 |
| jam | And I believe the default InterTree.iter_changes() calls tree.inventory.iter_changes() | 14:42 |
| vila | yup, self.target.inventory.iter_changes(self.source.inventory), thanks | 14:44 |
| vila | jam: well, it's not exactly the defaut, but I want to remove the hack that leads to that call by adding a proper InterTree optimiser | 14:48 |
| vila | see bzrlib/tree.py line 926 | 14:49 |
| jam | vila: aren't "CHKRevisionTrees" just RevisionTrees ? | 14:49 |
| vila | jam: I think so :-) Hence ENOTFOUND :) | 14:49 |
| jam | ah, ok | 14:49 |
| jam | I would like to not introduce CHKRevisionTree unless we have to | 14:50 |
| vila | I want to remove the XXX but keep the implementation, so I don't intend to change anything else | 14:51 |
| Kobaz | yeah | 14:51 |
| Kobaz | er | 14:51 |
| vila | i.e. is_compatible will be try: source and target defines id_to_entry return True except: return False | 14:52 |
| jam | vila: ah, sure, sounds like a good plan | 14:57 |
| vila | jam: the only problem is to find *where* to put that :-) As it seems I need to call it InterCHKTree (or InterCHKRevisionTree) even if none of these objects exist... | 14:58 |
| vila | jam: revisiontree.py to start with ? Will we ever add a CHKMap to dirstate ? | 14:59 |
| jam | so, you'll need to create a new Inter object, yes | 14:59 |
| jam | CHKMap w/ dirstate... | 14:59 |
| jam | we *will* want a custom implementation | 14:59 |
| jam | probably something that 'chains' changes | 14:59 |
| jam | specifically, dirstate can find the difference from the source tree to the basis tree quickly | 15:00 |
| jam | and then you want to compute the different from the basis to any other tree | 15:00 |
| jam | which should make "bzr diff -r XX" fast | 15:00 |
| jam | That is pretty low on *my* priority list, though. As it is fairly complex, and not a common op | 15:00 |
| vila | jam: ok, so InterCHLRevisionTree to start with, I'll define it in revisiontree.py then | 15:02 |
| Kobaz | i would love to be able to do a bzr diff while in the process of a bzr commit | 15:02 |
| Kobaz | i used to do that with svn all the time | 15:02 |
| vila | Kobaz: bzr commit --show-diff | 15:03 |
| Kobaz | yes i know | 15:03 |
| awilkins | What about qcommit (look at list of diffs, clickity) | 15:03 |
| Kobaz | but it would be nice to be able to selectivly show individual files | 15:03 |
| jam | vila: Why not CHM ? | 15:04 |
| jam | :) | 15:04 |
| Kobaz | i want a non-gui | 15:04 |
| vila | jam: lol | 15:04 |
| Kobaz | i dont see why the affected files have to be locked for reading | 15:04 |
| * vila would prefer a record-laughter/send-url to just 'lol' | 15:05 | |
| jam | Kobaz: the file that is locked is the meta-info file | 15:05 |
| jam | which we have plans to change so it doesn't cause this problem | 15:05 |
| jam | it just is low priority right now | 15:05 |
| Kobaz | nifty | 15:05 |
| jam | versus other thinsg | 15:05 |
| Kobaz | yeah | 15:05 |
| vila | Kobaz: you want a non-gui yet you can't fire a diff while committing ? You mean commit fire you editor but you don't consider your editor as a GUI ? (Trying to understand where you encounter the problem) | 15:06 |
| RaceCondition | I'm trying to commit over HTTP/WebDAV but getting Transport operation not possible: http does not support mkdir() | 15:08 |
| Kobaz | vila: non-gui as in non-x | 15:08 |
| awilkins | e.g. - you're using `screen` and want to check the diffs in another terminal while the commit dialog waits | 15:09 |
| awilkins | (editor being e.g. vim) | 15:09 |
| Kobaz | vila: i'm generally working in two or three ssh sessions to the same system | 15:09 |
| Kobaz | so i'll use emacs in one, to make my commit, and do diffs in another iwndow | 15:09 |
| RaceCondition | I've set up the DAV lock file and HTTP basic auth, pull works fine, but not push/commit | 15:09 |
| Kobaz | right now with bzr commit --show-diff, i do a split window, it seems to work out, but i really prefer to be able to navigate the tree and just say... i wanna do this file | 15:09 |
| vila | Kobaz: have you tried dvc ? | 15:10 |
| Kobaz | what's that? | 15:10 |
| vila | Kobaz: ok, have you tried diff-mode in a buffer containing the output of 'bzr diff -rsubmit:' ? | 15:11 |
| Kobaz | nope | 15:11 |
| Kobaz | it sounds like it would be cool | 15:11 |
| vila | Kobaz: dvc is a layer above that, a package that aim to provide the same UI than pcl-cvs was providing but for all DVCS | 15:11 |
| Kobaz | mmm, i've never used diff-mode, that's pretty cool | 15:13 |
| vila | Kobaz: my work cycle is: hack, get a buffer with 'bzr diff' in diff-mode (dvc-diff provides that and some additional niceties) from there I can do C-c C-c and it opens the file at point in that exact position (line and char) C-c C-a apply/revert the hunk at point | 15:14 |
| Kobaz | i need to change my colors though, some text is black on black, heh | 15:14 |
| vila | Kobaz: it makes appyling/reverting any hunk a breeze | 15:14 |
| vila | Kobaz: and more importantly allows me to navigate between all the files I'm modifying | 15:15 |
| vila | Kobaz: I know no other IDE that can beat that | 15:15 |
| Kobaz | yeah | 15:15 |
| Kobaz | sexy | 15:15 |
| vila | Kobaz: Oh, and I almost forget: when commit time is near: C-x 4 a in any hunk create the ChangeLog entry (remember to create the ChangeLog file at your project root though) | 15:16 |
| Kobaz | mmm | 15:16 |
| vila | Kobaz: So I *prepare* my commit in ChangeLog by doing multiple reviews of the diff buffer far before committing | 15:17 |
| LarstiQ | jelmer: I don't know if you uploaded bzr-svn to the ppa, but 0.5.2 is only in hardy | 15:17 |
| vila | Kobaz: So I never need to look at diffs when committing, I just copy/paste my already prepared messager | 15:17 |
| Kobaz | mmm | 15:18 |
| Kobaz | ionteresting | 15:18 |
| Kobaz | interesting | 15:18 |
| RaceCondition | does bzr not handle tildes (~) in URLs well? | 15:25 |
| Kobaz | have you studdied the logs | 15:26 |
| Kobaz | er | 15:26 |
| awilkins | RaceCondition: I know it doesn't understand them for bzr+ssh:// | 15:27 |
| RaceCondition | awilkins: http+webdav is what I'm using | 15:27 |
| RaceCondition | it "normalizes" ~ to %7E | 15:28 |
| RaceCondition | and then Apache makes an automatic permanent redirect which bzr errors on | 15:28 |
| awilkins | RaceCondition: Not tried it ; but is the user on the server the owner of the home folder you are aiming at? | 15:28 |
| RaceCondition | awilkins: the home folder, yes, but not the part that is accessed via WebDAV | 15:28 |
| RaceCondition | does it matter? | 15:29 |
| awilkins | I'm not entirely sure over WebDAV | 15:32 |
| RaceCondition | hmm, well, I changed to absolute paths instead of ~, but getting different errors now | 15:32 |
| RaceCondition | has anyone verified that the webdav plugin actually works? | 15:33 |
| rocky | jelmer: ping | 15:36 |
| Keybuk | remind me who does "bzr fast-import" :) | 15:42 |
| Keybuk | bzr: ERROR: Bad restart - attempted to skip commit :3 but matching revision-id is unknown | 15:45 |
| Keybuk | :-( | 15:45 |
| jelmer | rocky, pong | 15:50 |
| jelmer | Keybuk, igc (Ian Clatworthy) does fast-import | 15:50 |
| james_w | Keybuk: that's igc | 15:50 |
| james_w | Keybuk: are you using the latest lp:bzr-fastimport ? | 15:50 |
| Keybuk | james_w: afaik | 15:53 |
| james_w | ok | 15:53 |
| james_w | that was either fixed recently, or caused recently | 15:54 |
| james_w | I guess it must be the latter :-) | 15:54 |
| jelmer | LarstiQ, I uploaded 0.5.2 to Hardy at Barry's request | 15:54 |
| Keybuk | oh, no, I'm out of date | 15:54 |
| Keybuk | ssh'd to the wrong machine when I checked | 15:54 |
| Keybuk | let me pull and try again | 15:54 |
| james_w | jelmer: would you be willing to sponsor an upload to Debian this week? | 15:54 |
| rocky | jelmer: just curious, some TracBzr code is calling _get_weave(fileid) to in order to get merge history but in some versino of bzr _get_weave() disappeared... do you know a better way to track down merge history for a fileid ? | 15:55 |
| Keybuk | james_w: still fails with current HEAD | 15:56 |
| LarstiQ | jelmer: ah | 15:56 |
| jelmer | james_w, yes, happy to sponsor | 15:57 |
| james_w | jelmer: cool, thanks, I'll put details in a mail | 15:58 |
| jelmer | rocky: Repository.texts might have some function that can return ancestry | 15:58 |
| rocky | oh cool | 16:00 |
| rocky | jelmer: just so i'm familiar with terminology here... what exactly is a "weave" in the context of bzr? is it a repo format, or just some technique for relating things or ? | 16:02 |
| james_w | one annoyance with the hook to provide a starting commit message is that it means you can't exit without changes to cancel the commit | 16:03 |
| jelmer | rocky, it's a place where revisions for a particular file are stored | 16:03 |
| jelmer | rocky, it no longer exists in newer repositories | 16:03 |
| rocky | ah i c | 16:03 |
| jelmer | rocky, has been replaced with Repository.texts | 16:03 |
| rocky | gotcha | 16:03 |
| jelmer | rocky, which manages all revisions of all texts | 16:04 |
| rocky | i'm looking at VersionedFiles (which is what .text is an instance of ) but it seems rather low level with no functions that work with fileid's | 16:04 |
| jelmer | rocky: Keys are a tuple of (fileid, revision) | 16:04 |
| jelmer | rocky, VersionedFiles is generic | 16:04 |
| rocky | ohh | 16:04 |
| rocky | that makes sense | 16:04 |
| rocky | so looks like annotate may give me the ancestry i need | 16:06 |
| rocky | strange, doesn't seem obvious how to get a VersionedFile instance from VersionedFiles | 16:09 |
| jelmer | rocky: annotate will give you the contents | 16:12 |
| jelmer | rocky, not the ancestry | 16:12 |
| jelmer | you may need to use bzrlib.graph.Graph combined with Repository.texts.get_parent_map | 16:12 |
| rocky | yeah right now i'm eye'ing VersionedFile.get_ancestry() which seems to do what i need...but it's not obvious how to get a VersionedFile from a repo when i have the current file_id and rev | 16:13 |
| rocky | or is VersionedFile not really used anymore? | 16:14 |
| rocky | (since it was tied to Weave it seems) | 16:15 |
| rocky | sorry if i'm acting like a noob on this, i'm trying to get more comfortable with bzrlib flow of things so i can be more useful :) | 16:15 |
| jelmer | it was the base class for Weave's and Knit's | 16:15 |
| jelmer | rocky, no worries | 16:15 |
| jelmer | rocky, I think yu want bzrlib.graph.Graph(repo.texts.get_parent_map) | 16:16 |
| jelmer | rocky, I think yu want bzrlib.graph.Graph(repo.texts.get_parent_map).iter_ancestry([(myfile, textrevision)]) | 16:16 |
| mxpxpod | jelmer: hey... I was wondering if there are any docs for subvertpy | 16:17 |
| jelmer | mxpxpod, pydoc subvertpy :-) | 16:17 |
| jelmer | mxpxpod, other than that, I'm happy to answer questions about subvertpy or update the docs where necessary | 16:17 |
| jelmer | mxpxpod, more dosc were added recently, so be sure you're running from lp:subvertpy | 16:18 |
| mxpxpod | jelmer: how would I update a repo with a self-signed certificate? I get an exception saying the server certificate verification failed: issuer is not trusted | 16:20 |
| jelmer | mxpxpod, specify an Auth handler when opening RemoteAccess | 16:22 |
| jelmer | mxpxpod, the Auth handler should contain a SSL server certificate checker | 16:22 |
| mxpxpod | jelmer: I was using c = client.Client(); c.update(['/path/to/checkout']) | 16:22 |
| jelmer | mxpxpod, try something like this: | 16:23 |
| jelmer | c = client.Client(auth=Auth([my_ssl_checker])) | 16:24 |
| mxpxpod | jelmer: and what is my_ssl_checker? | 16:24 |
| jelmer | see bzrlib.plugins.svn.auth.create_auth_baton for an example | 16:24 |
| mxpxpod | ok | 16:24 |
| jelmer | mxpxpod, HTH, if not, I should be around again later tonight | 16:25 |
| mxpxpod | jelmer: ok, thanks for the help | 16:25 |
| jelmer | or feel free to email me, and I can add a trivial example to the bzr branch | 16:25 |
| mxpxpod | jelmer: awesome, I'll do that | 16:25 |
| === mvo_ is now known as mvo | ||
| mxpxpod | jelmer: that worked great, thanks! | 16:28 |
| === beuno_ is now known as beuno | ||
| phinze | i feel bad, but i keep getting frustrated when someone else eats my commits to our trunk | 16:41 |
| phinze | and the log starts looking like 2345: merging from remote, 2346: merging from remote | 16:41 |
| phinze | with all of the actual messages as subcommits | 16:41 |
| beuno | phinze, you can set an append-only policy | 16:42 |
| beuno | so nobody can do that | 16:42 |
| radix | phinze: That can actually be a good thing, depending on your development methodology | 16:42 |
| beuno | they'd have to change the workflow | 16:42 |
| beuno | as in, have a checkout of trunk, and merge changes *into* that from other branches | 16:42 |
| radix | phinze: if you do feature/fix-per-branch, it works out quite well: the merge commit shouldn't just say "merge from remote", but actually describe the feature or fix | 16:42 |
| radix | then it's easy to generate a news file for a release :) | 16:43 |
| phinze | well it's more like #123 my change, #124 a merge of everyone elses changes while i was working, #125 my other change, #126 a merge of everyone elses changes while i was fixing thta | 16:43 |
| phinze | or i suppose the order would be flipped | 16:43 |
| phinze | with the merges coming before the changes | 16:44 |
| beuno | phinze, right. So, set append only policy to trunk | 16:44 |
| beuno | and tell everyone to change the workflow to the one I mentioned above | 16:44 |
| phinze | beuno: yeah i suppose that's the way to go | 16:44 |
| phinze | not sure if i have the clout to force other people into that workflow though | 16:45 |
| beuno | phinze, just set the append only flag, and the rest will happen on it's own ;) | 16:46 |
| phinze | beuno: oooo you are talking about a setting i can make | 16:46 |
| beuno | phinze, of course | 16:47 |
| beuno | append_revisions_only | 16:47 |
| phinze | okay, i like that, so what will the offending coworkers experience then | 16:48 |
| beuno | :) | 16:48 |
| phinze | they branch trunk locally, make changes (while other commits are being made to shared trunk) | 16:48 |
| phinze | then they want to push | 16:48 |
| phinze | and shared trunk denies them? | 16:48 |
| beuno | yes | 16:49 |
| beuno | set it in on branch.conf of trunk | 16:49 |
| phinze | cool, now when they come to me with their local branch in that messy state... how do i get them out of it? :) | 16:49 |
| beuno | well, they will get denied merging and pushing | 16:50 |
| beuno | which is when you explain | 16:50 |
| beuno | they should have a checkout | 16:50 |
| beuno | merge into that, and commit | 16:50 |
| beuno | so no push involved | 16:50 |
| phinze | gotchya | 16:51 |
| Ollie_R_ | hey if i do a bzr push it keeps this info i.e.. bzr info displays it so it must be recored. Is there anyway to remove this? | 16:52 |
| beuno | Ollie_R_, in ~/.bazaar/locations.conf | 16:52 |
| Ollie_R_ | beuno: just manually edit it? | 16:52 |
| beuno | Ollie_R_, yes | 16:52 |
| Ollie_R_ | beuno: perfect thanks | 16:52 |
| beuno | phinze, so you edit .bzr/branch/branch.conf | 16:53 |
| beuno | and add: append_revisions_only = True | 16:53 |
| jam | phinze: I'm sure you have the clout, since if you set the policy, everyone's client will complain if they don't :) | 16:59 |
| phinze | jam: that's always the best way, no? :) | 17:01 |
| jam | phinze: well, don't you have a developer meeting this afternoon anyway? | 17:02 |
| jam | Just tell them that jam on IRC said that this is the 'one true way' | 17:02 |
| jam | :) | 17:02 |
| jam | (seriously, though, checkouts of trunk are a great way to go) | 17:02 |
| phinze | jam: lol you know too much about our group. dev mtg is thursday and it's on the agenda. we'll set the policy after the meeting gives fair warning. | 17:02 |
| phinze | yeah i've got the important players to agree with me | 17:03 |
| jam | (and having updates show up as "merged feature XXX" is another really good thing) | 17:03 |
| jam | especially when combined with 'bzr log --short -r -10..-1' | 17:03 |
| phinze | and the fact that you can set the policy on the shared branches is golden | 17:03 |
| jam | right, so with the policy set, you don't *have* to use a checkout | 17:03 |
| jam | they could still push/pull | 17:04 |
| jam | as long as they manage to maintain the history correctly | 17:04 |
| phinze | jam: hah, keith was just talking about your favorite log format | 17:04 |
| jam | *but* a checkout will help maintain that much easier | 17:04 |
| phinze | oh i didn't know about -# notation, i've been wasting keystrokes on last:# | 17:05 |
| jam | phinze: also '-#' works better in aliases, IIRC | 17:06 |
| jam | if you do 'bzr log -r -10..-1' but there are only 5 revisions, it still works | 17:06 |
| jam | I think 'last:10' might give an error about there not being 10 | 17:06 |
| phinze | cool | 17:06 |
| === serg_ is now known as serg | ||
| CaMason | I'm on windows, and using `bzr diff --using=BCompare` which launches my diffs on a file-by-file basis. Is there a way to get the entire diff output as one 'temp' file? | 17:11 |
| awilkins | jelmer: Ping? | 17:40 |
| eydaimon | are there any variables I can use? Such as $author$ etc? | 17:42 |
| awilkins | eydaimon: No keyword subbing yet | 17:42 |
| eydaimon | thanks | 17:43 |
| lifeless | rocky: list(Graph(parents_provider=t.branch.repository.texts)._make_breadth_first_searcher([(file_id, revision]))) | 17:49 |
| lifeless | rocky: thats roughly the replacement for the line of code you quoted, if you really need that :P | 17:50 |
| Ollie_R_ | is it possible to turn a heavyweight checkout into a lightweight checkout after If I have already done a checkout or bound to a repo | 17:58 |
| beuno | Ollie_R_, bzr reconfigure --lightweight-checkout | 17:59 |
| Ollie_R_ | beuno: again many thanks | 17:59 |
| beuno | Ollie_R_, you're very welcome | 18:00 |
| beuno | hiya lifeless | 18:00 |
| beuno | you're up early, aren't you? | 18:00 |
| lifeless | fsvo up | 18:02 |
| beuno | my best guess of what that means is "my fiancee woke me up" | 18:04 |
| lifeless | for some value of up | 18:07 |
| beuno | :) | 18:08 |
| === enigma1 is now known as enigma42 | ||
| rocky | lifeless: yeah, that looks good, course i was a little scared by the fact that Graph's constructor says it should rarely be used ;) | 18:26 |
| lifeless | rocky: it should be rarely used | 18:27 |
| lifeless | rocky: accessing all of history like that isn't generally a good idea | 18:27 |
| rocky | lifeless: of course now you have me using another private method ;) | 18:27 |
| rocky | _make_breadth_first | 18:28 |
| lifeless | hi mneptok | 18:29 |
| mneptok | ahoy | 18:30 |
| mneptok | irssi is strange. | 18:34 |
| lifeless | irssi, life, ce la vie | 18:35 |
| lifeless | lol, again with the softpedia - http://linux.softpedia.com/get/Programming/Version-Control/bzr-search-40745.shtml | 18:37 |
| === eix is now known as Goundy | ||
| sidnei | lifeless: evil! what text indexing does it use? xapian? lucene? something else? | 18:51 |
| beuno | sidnei, of course, it's something custom lifeless wrote | 18:52 |
| beuno | using existing libraries is for wimps | 18:52 |
| * awilkins thanks sidnei for answering a question on his brainstack about "wtf is lucene" | 18:52 | |
| awilkins | Yeah, how can you be sure that existing libraries will have exactly the right bugs? | 18:53 |
| awilkins | mneptok: irssi is awesome | 18:54 |
| awilkins | jelmer: Ping? | 18:57 |
| lifeless | sidnei: its a trivial text index I wrote using bzrlib primitives, java bindings were too nasty, and xapian was too local-only for my taste | 19:07 |
| sidnei | lifeless: solr might be an option, it's lucene with a http frontend, rest-inspired api, works around both issues. | 19:10 |
| lifeless | sidnei: well, won't work over ftp :P [the current index does] | 19:11 |
| lifeless | sidnei: also it would seem to require running up a large infrastructure to answer 'bzr search foo' from vim, which is concerning :) | 19:12 |
| lifeless | sidnei: thats actually my main concern for this; xapian would have been nearly ideal with its embedded design | 19:13 |
| === Ganja is now known as Goundy | ||
| lifeless | anyhow, the result is fast enough to do search completion for loggerhead :) | 19:14 |
| lifeless | beuno: is there a demo site showing that still? | 19:14 |
| sidnei | lifeless: been burnt by xapian myself. there's some great python client support for solr though, we've used it for replacing the built-in search in plone | 19:15 |
| beuno | lifeless, http://bzr.mattnordhoff.com/loggerhead/bzr-search/py2.6/files | 19:16 |
| beuno | Peng_ rocks | 19:16 |
| lifeless | sidnei: I will poke at it | 19:16 |
| lifeless | beuno: oh, I should merge that I guess, remind me tomorrow | 19:17 |
| lifeless | sidnei: go to the url beuno just linked | 19:17 |
| lifeless | sidnei: search box in the top right, type stuff in. You can't down arrow into the results yet | 19:18 |
| * lifeless looks at beuno | 19:18 | |
| lifeless | sidnei: so you have to click | 19:18 |
| sidnei | lifeless: looks cool! | 19:19 |
| * beuno hides behind his piles of work | 19:19 | |
| === davidstrauss_ is now known as davidstrauss | ||
| lifeless | sidnei: if you hit enter you get the non ajax search page for whatever you had been typing | 19:19 |
| beuno | lifeless, although, now that it's been YUI-ified, I have a pretty good idea how to do that | 19:19 |
| beuno | not that I have the time to implement it, but maybe I'll manage to trick someone | 19:19 |
| sidnei | lifeless: very nice | 19:20 |
| sidnei | lifeless: fyi, if you ever look at solr, this is a good start to look at how to integrate it with an existing system http://pypi.python.org/pypi/collective.solr/ | 19:20 |
| lifeless | thanks | 19:22 |
| mneptok | awilkins: alternate_nick cannot be defined in the main core section of the config file. it has to be defined in a separate core param elsewhere. weird. | 19:22 |
| lifeless | thumper: the bzr-playground mirror-log file is inaccessible now | 19:23 |
| lifeless | thumper: also the bzr-search indices for trunk seem awol | 19:24 |
| lifeless | Jc2k: do you still have your imports with search? | 19:25 |
| Jc2k | lifeless: it all just forwards on to bzr-playground now | 19:30 |
| Jc2k | there were some old imports on the playground box in my home directory | 19:31 |
| === maxb is now known as Guest27135 | ||
| mwhudson | jelmer: ping | 20:47 |
| rockstar | jelmer, hello! | 21:05 |
| savvas | /usr/lib/python2.6/dist-packages/Crypto/Hash/SHA.py:6: DeprecationWarning: the sha module is deprecated; use the hashlib module instead <- I suppose this will be fixed for bzr (if it wasn't already) :) | 21:14 |
| mwhudson | savvas: well, hashlib isn't present in 2.4, which bzr still runs with | 21:16 |
| savvas | ah, I see | 21:17 |
| mwhudson | so, "yes", i guess, but it's not totally trivial | 21:17 |
| savvas | mwhudson: is there a list with what would possibly break with python 3? | 21:18 |
| mwhudson | i have no idea, but i imagine the list would be rather long | 21:18 |
| mwhudson | i think the unicode/str stuff probably makes a mess | 21:18 |
| savvas | thanks for the information, good to know what to expect :) | 21:19 |
| igc1 | morning | 22:14 |
| === igc1 is now known as igc | ||
| poolie1 | hi igc | 22:15 |
| poolie1 | jam (over here), i was tempted to look at some of the highest bugs, but | 22:15 |
| poolie1 | that's probably actually a distraction from brisbane core | 22:15 |
| jam | morning igc | 22:16 |
| igc | poolie1: hi. I'm probably going to hit the review queue today | 22:16 |
| jam | igc: what is your comfort level for doing some testing with groupcompress+rabin? | 22:16 |
| igc | hi jam | 22:16 |
| jam | I've just finished a couple rounds of updates | 22:16 |
| poolie1 | i'd really like to get that running on orcadas | 22:16 |
| jam | and while I'm going to be working on changing the actual layout a bit next | 22:16 |
| poolie1 | if the conversion speed is getting better i'd even think about not using pre-canned data | 22:17 |
| jam | I think I have the compressor/decompressor pretty well settled | 22:17 |
| mwhudson | jelmer, Jc2k: either of you here? | 22:17 |
| jam | poolie1: I don't think it is in the 'good enough' stage yet | 22:17 |
| igc | poolie1: yesterday was unproductive - slept much of the day | 22:17 |
| nua | Hi all, quick question: Does a branch always have revision no. 1 as its first revision? or could it be something strange like 0.1? | 22:22 |
| igc | jam: can I get some help with chk_map.iter_changes()? | 22:24 |
| igc | jam: I'd like to know when excluded_keys ought to be populated | 22:24 |
| === Guest27135 is now known as maxb | ||
| Jc2k | mwhudson: sup | 22:27 |
| jelmer | mwhudson, hi | 22:27 |
| Jc2k | ha | 22:27 |
| jam | igc: so... I believe robert was the original author of that code, and I don't have a tremendous handle on it. But I'll try to help when I can. | 22:27 |
| Jc2k | jelmer: great timing :) | 22:27 |
| jelmer | Jc2k, somethign is weird here today | 22:28 |
| jelmer | I had the same thing with james_w a bit earlier | 22:28 |
| jam | robert went with a sort of 'priority queue' (heap) to determine what keys should be checked next | 22:28 |
| mwhudson | :) | 22:28 |
| jam | in general, you have 3 states | 22:28 |
| jam | keys which are in the 'known uninteresting' set | 22:28 |
| jam | keys which are in the 'known interesting' set | 22:28 |
| jam | and keys that you don't know yet | 22:29 |
| mwhudson | jelmer, Jc2k: is the dulwich dependence on python 2.5 a deep thing? | 22:29 |
| jelmer | mwhudson, not really | 22:29 |
| jam | known uninteresting is a sha1 sum that you have seen on both sides | 22:29 |
| jam | obviously no changes there | 22:29 |
| jelmer | mwhudson, it's mainly just laziness | 22:29 |
| mwhudson | i have a terribly terribly awful branch that seems to make it work on 2.4... | 22:29 |
| jam | so all children of those keys can be excluded | 22:29 |
| jam | known interesting is more difficult | 22:29 |
| mwhudson | lp:~mwhudson/dulwich/2.4-hacking i think | 22:29 |
| rockstar | jelmer, if you think it's worth it, I'm willing to clean up the awfulness of that branch. | 22:29 |
| jam | it is a sha1 sum that doesn't exist on the other side, and you *know* that it isn't possible to find it | 22:30 |
| jam | for example, if the prefix on side 1 doesn't have an 'A' record, then you know the sha1 underneath 'A' is interesting. | 22:30 |
| mwhudson | of course maybe we'll actually be able to use 2.5 before this is super important | 22:30 |
| jelmer | mwhudson, rockstar: that would be nice | 22:30 |
| mwhudson | jelmer: cool | 22:30 |
| jam | So 'excluded_keys' sounds like things that are "known_uninteresting", though I haven't really dug through the code (yet) | 22:31 |
| mwhudson | jelmer: also the dulwich tests fail on trunk for me | 22:32 |
| igc | jam: right | 22:32 |
| poolie1 | nua: the first is always 1 | 22:33 |
| nua | poolie1: excellent, thanks :) | 22:33 |
| poolie1 | jam: compression speed not good enough to convert on every benchmark, or not good enough to field it? | 22:33 |
| mwhudson | dulwich.tests.test_pack.TestPackData.test_iterentries | 22:33 |
| poolie1 | orcadas is sad about the hardy upgrade, it keeps saying | 22:33 |
| poolie1 | /srv/benchmark.bazaar-vcs.org/bzrbench/bin/monitor-load.sh: 18: 1236118801: not found | 22:34 |
| poolie1 | so i'll probably fix that first | 22:34 |
| poolie1 | nice error though: ) | 22:34 |
| jam | poolie1: not good enough to convert on every benchmark | 22:34 |
| Jc2k | mwhudson: that test never passed for me on my main laptop, but i think i have seen it pass somewhere :/ | 22:35 |
| jam | poolie1: time bzr pack on a python.org repository gc+rabin+chk255 is 30 minutes | 22:35 |
| mwhudson | Jc2k: nice | 22:35 |
| jam | I'm not sure how long a conversion is | 22:35 |
| poolie1 | ok, so igc did write this nice new pre-canned data thing | 22:36 |
| poolie1 | we can use that | 22:36 |
| mwhudson | Jc2k: i bet its a 64 bit, 32 bit bug | 22:36 |
| jam | poolie1: though as for my 'improvements', that is down from 1.8hrs yesterday | 22:37 |
| igc | jam: can you taz.bz2 that python branch and upload it to orcadas? | 22:37 |
| Jc2k | mwhudson: ooh, it never passed on my 64 bit laptop *i think* | 22:37 |
| jam | igc: I'm not sure that I have access to orcadas, and I'm pretty sure .bz2 isn't going to pack it any better :), but I can upload it somewhere | 22:37 |
| mwhudson | i love the readable error | 22:37 |
| mwhudson | it's so easy to see which things aren't equald | 22:38 |
| igc | jam: if therer's a matching 1.9 branch, we'd like it uploaded as well | 22:38 |
| igc | jam: the tar.bz2 format is just what usertest expects to find as source input | 22:38 |
| jam | igc: sure | 22:38 |
| igc | tar.gz is fine as well | 22:38 |
| igc | jam: is your rabin branch available somewhere as well? | 22:39 |
| poolie1 | gzip -1 then | 22:39 |
| jam | igc: lp:~bzr/bzr-groupcompress/rabin | 22:39 |
| mwhudson | basically it comes down to | 22:39 |
| mwhudson | -901046474 != 3393920822 | 22:39 |
| mwhudson | but | 22:41 |
| mwhudson | -901046474&0xffffffff == 3393920822 | 22:41 |
| jam | mwhudson: just to mention zlib.crc32(text) returns a signed 32-bit PyInt on 32-bit platforms, and a signed 64-bit PyInt on 64-bit platforms. However as crc32 is a 32-bit object, it shows up negative in 32-bit platforms and *positive* on 64-bit | 22:41 |
| mwhudson | i.e. it is some kind of clipping thing | 22:41 |
| jam | I don't know where else that happens | 22:41 |
| jam | but we ran into it in our code | 22:41 |
| mwhudson | i doubt git is using crc32 somehow | 22:41 |
| mwhudson | but yes, it's something like that | 22:41 |
| mwhudson | Jc2k: should i file a bug? | 22:41 |
| igc | jam: any thoughts on how long before you'll be ready to merge that into the groupcompress trunk? | 22:42 |
| jam | igc: So I think the compressor / decompressor are good | 22:42 |
| jam | And certainly faster than gc-trunk | 22:42 |
| jam | I don't have a pure python implementation yet | 22:42 |
| jam | (not sure how much I'm going to bother, potentially I'll use the old GC code as the python impl) | 22:42 |
| igc | jam: groupcompress needs a Makefile then :-) | 22:44 |
| jam | igc: python setup.py build_ext -i | 22:44 |
| jam | works fine here :) | 22:45 |
| Jc2k | mwhudson: *nod* | 22:45 |
| jam | igc: I'm uploading: python-gcr255-rr2.tar to my home directory on orcadas now | 22:45 |
| jam | It tells me that I should expect it to get there in about 2 hours | 22:45 |
| ronny | jelmer: is there any git cappability that tells if old/new objects are supported? | 22:46 |
| igc | jam: ah - cool. I wasn't sure if that only handled std plugins. If it works for other plugins installed as well, that's neat. | 22:46 |
| jam | igc: well doing it in *bzr* won't build the plugin, but doing it in the plugin directory works fine | 22:46 |
| jelmer | ronny, in the protocol you mean? | 22:48 |
| ronny | jelmer: in the repo itself | 22:49 |
| jelmer | ronny, no | 22:49 |
| jam | igc: anyway, the next step is to change how labels, etc work. Which is a fairly major change to the bytes-on-disk | 22:49 |
| jam | which is sort of what I was waiting for | 22:49 |
| jam | I suppose I could land it earlier rather than later | 22:49 |
| ronny | jelmer: ah, k, sad | 22:49 |
| igc | jam: no hurry | 22:50 |
| mwhudson | Jc2k: https://bugs.edge.launchpad.net/dulwich/+bug/337483 | 22:50 |
| ubottu | Launchpad bug 337483 in dulwich "dulwich.tests.test_pack.TestPackData.test_iterentries fails on a 64-bit system" [Undecided,New] | 22:50 |
| igc | jam: my focus is trying to get log -v faster and it just isn't in the small tests I've done to date | 22:50 |
| jam | igc: you might look at 'iter_interesting_nodes' which is a different approach to culling chk pages | 22:51 |
| jam | I don't know if it is specifically faster/slower | 22:51 |
| jam | just a different ordering | 22:51 |
| igc | jam: yeah, I'm yet to digest the last 50% of the chk_map code | 22:51 |
| jam | anyway, I'm done for the night | 22:52 |
| jam | later guys | 22:52 |
| igc | jam: night and thanks | 22:52 |
| poolie1 | night jam | 23:07 |
| poolie1 | and thanks for the roadmap updates | 23:09 |
| igc | spiv: has http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090126072506.GA30864%40steerpike.home.puzzling.org%3E landed yet? | 23:16 |
| poolie1 | lifeless: is there actually a bzr-gc plugin or am i just dreaming? | 23:18 |
| igc | poolie1: bzr-groupcompress | 23:22 |
| spiv | igc: not yet; I need to take another look at it now that vila has landed related changes for HTTP network activity reporting | 23:28 |
| spiv | igc: partly because I should probably reuse some of the code, and also to be sure it won't cause double-counting of bzr+http traffic. | 23:29 |
| * igc breakfast | 23:33 | |
| nua | I'm trying to get the id of the first revision in a branch using bzrlib, but branch.get_rev_id('1') is throwing an exception: BzrBranch6('file:///home/testuser/test/revnotest/') has no revision 1 | 23:34 |
| nua | ...there must be a neater way of doing this! | 23:35 |
| spiv | nua: have you tried branch.get_rev_id(1) | 23:39 |
| spiv | nua: i.e. the revno you pass in should be an int, not a str. | 23:39 |
| nua | spiv: yes, it says its not a valid revno | 23:39 |
| spiv | what is branch.last_revision_info()? | 23:40 |
| spiv | nua: branch.get_rev_id(1) works for me. | 23:40 |
| nua | spiv: that's interesting! | 23:40 |
| spiv | nua: http://rafb.net/p/D2wnww23.html | 23:40 |
| nua | spiv: thanks, I'll look into my code | 23:40 |
| poolie1 | igc, lifeless, i meant garbagecollect not groupcompress :) | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!