| Odd_Bloke | Is there a way to convert bzr -> SVN? | 12:30 |
|---|---|---|
| Odd_Bloke | It only need be a one-off conversion, I just want to run some metrics. | 12:31 |
| lifeless | bzr push | 12:31 |
| lifeless | jelmer: ^ | 12:31 |
| lifeless | Odd_Bloke: or perhaps bzr svnserve | 12:32 |
| === keir [n=keir@206-248-160-33.dsl.teksavvy.com] has joined #bzr | ||
| keir | when testing out 'bzr send', and mailing to myself, why is the subject '[MERGE] (Nam Nguyen) Pre-commit hook' ? i didn't specify that subject, or the name 'nam nguyen' anywhere | 12:40 |
| keir | (this is in a clean branch of bzr.dev) | 12:40 |
| lifeless | keir: do 'bzr log -r -1' | 12:40 |
| keir | hmm, ok | 12:41 |
| jelmer | Odd_Bloke: bzr svn-push from bzr-svn 0.4 should be able to do that | 12:42 |
| jelmer | lifeless: bzr svnserve is pretty much nonexistant | 12:42 |
| lifeless | jelmer: ok | 12:42 |
| keir | ok. so it uses the last commit message as the subject? | 12:44 |
| keir | i'm trying to figure out how to get bzr send to work nicely with gmail, and then write a wiki page about it | 12:45 |
| keir | (gmail has smtp) | 12:45 |
| lifeless | keir: normally you have two branches | 12:45 |
| lifeless | your branch | 12:45 |
| lifeless | and the target | 12:45 |
| lifeless | testing with your branch == target is unusual | 12:45 |
| Odd_Bloke | jelmer: "bzr: ERROR: Invalid http response for http://svn.uwcs.co.uk/repos/gryle/.bzr/branch-format: Unable to handle http code 401: Authorization Required | 12:46 |
| jelmer | Odd_Bloke: does the repository require authentication? | 12:47 |
| keir | lifeless, as i understand it bzr send is intended for the following use case: | 12:47 |
| Odd_Bloke | jelmer: Yeah, I was wondering if I need to put that in a config file somewhere? | 12:47 |
| keir | 1) bzr branch 2) hack hack 3) commit 4) repeat 2&3 5) bzr send --mail-to=somelist@someproj.org | 12:47 |
| lifeless | keir: thats right | 12:48 |
| jelmer | Odd_Bloke: bzr-svn uses the credentials stored in ~/.subversion/auth/ | 12:48 |
| jelmer | Odd_Bloke: the easiest way is to force svn to store those credentials first before using bzr-svn | 12:48 |
| keir | lifeless, and by default it uses the parent branch as the target | 12:49 |
| lifeless | keir: send --help | 12:50 |
| lifeless | :) | 12:50 |
| lifeless | I'm not familiar with send really | 12:50 |
| === igc [n=igc@ppp121-45-197-71.lns1.bne1.internode.on.net] has joined #bzr | ||
| igc | morning | 12:52 |
| === troy_s [n=aphorism@d206-116-6-170.bchsia.telus.net] has joined #bzr | ||
| === jml [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr | ||
| === jml_ [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr | ||
| === jml_ is now known as jml | ||
| === sverrej [n=sverrej@tul-1x-dhcp013.studby.uio.no] has joined #bzr | ||
| Odd_Bloke | jelmer: I've finally sorted out the auth'ing problems, but I'm now being told the branches have diverged and I need to merge them. Running 'bzr merge <SVN repo location>' gives me an error about incompatible repositories. What should I be doing now? | 01:09 |
| jelmer | Odd_Bloke: the location you're trying to push to, does that already exist? | 01:12 |
| Odd_Bloke | jelmer: Yeah. | 01:14 |
| === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr | ||
| === p4tux [n=p4tux@189.169.92.184] has joined #bzr | ||
| poolie | hi all | 01:15 |
| igc | morning poolie | 01:16 |
| poolie | hi ian | 01:16 |
| jelmer | Odd_Bloke: that doesn't work yet :-( pushing to /trunk if it doesn't exist yet should work | 01:16 |
| lifeless | whats with the NEWS indenting changes | 01:17 |
| Odd_Bloke | jelmer: Ah OK. | 01:17 |
| Odd_Bloke | I'll do that then. :D | 01:17 |
| lifeless | I don't recall seeing anything on-list | 01:17 |
| lifeless | and all my branches are conflicting heinously | 01:17 |
| poolie | lifeless, different sections were inconsistent, it looks bad in rest | 01:18 |
| poolie | i am sorry for all the conflicts | 01:18 |
| keir | i see there is support for thunderbird in mail_client.py; how do i tell bzr to use it? | 01:18 |
| lifeless | I think you should announce the right indent on list | 01:18 |
| poolie | probably should have done it during freeze | 01:18 |
| lifeless | everyone who has outstanding branches will need to review their new sections | 01:18 |
| igc | lifeless: I mentioned it yesterday on IRC - it's a pain :-( | 01:19 |
| lifeless | igc: btw pqm submit standard is (submitter) MESSAGE (authors) (as far as I know) | 01:20 |
| Odd_Bloke | jelmer: I got http://pastebin.com/m47fed230 when pushing to the uncreated /trunk. | 01:20 |
| Odd_Bloke | jelmer: Both with and without --overwrite. | 01:20 |
| lifeless | igc: did you profile the pre commit hook changes on big trees or do I need to ? | 01:20 |
| poolie | it would be nice to patch pqm to use the signer or email sender | 01:20 |
| poolie | or indeed to just read a merge directive... | 01:21 |
| jelmer | Odd_Bloke: please use the svn-push command | 01:21 |
| === mlh_ [n=mlh@c211-30-211-232.belrs1.nsw.optusnet.com.au] has joined #bzr | ||
| igc | lifeless: I'm happy to do it | 01:21 |
| keir | nm! | 01:21 |
| lifeless | poolie: indeed, patches considered gratefully | 01:21 |
| lifeless | :) | 01:21 |
| jelmer | Odd_Bloke: you're hitting bug 127945 | 01:21 |
| ubotu | Launchpad bug 127945 in bzr-svn "Integrate creating new branch functionality into standard push" [Low,Triaged] https://launchpad.net/bugs/127945 | 01:21 |
| Odd_Bloke | jelmer: OK, I've tried with svn-push and hit http://pastebin.com/m4a239e0d | 01:23 |
| Odd_Bloke | jelmer: Thanks for helping me with this, by the way. :) | 01:23 |
| jelmer | argh | 01:23 |
| igc | lifeless: checking bzr log --short on bzr.dev shows both forms in equal amounts :-) | 01:23 |
| jelmer | Odd_Bloke: please change _is_http_transport() in transport.py to return False | 01:23 |
| jelmer | Odd_Bloke: you've hit pretty much all known bugs in bzr-svn :-/ | 01:23 |
| lifeless | igc: we should choose one on list | 01:24 |
| igc | I'm happy either way - but we should all the same as you suggest | 01:24 |
| poolie | lifeless, did you see my PM? | 01:25 |
| Odd_Bloke | jelmer: A progress bar! \o/ | 01:26 |
| === mlh [n=mlh@c211-30-211-232.belrs1.nsw.optusnet.com.au] has joined #bzr | ||
| lifeless | poolie: ah yes | 01:29 |
| lifeless | jelmer: I'm not sure where the bug is | 01:31 |
| lifeless | igc: I don't feel confident enough in your delta based code for recommend it for 0.91 | 01:39 |
| lifeless | not that I think its actually wrong, just its changing something rather core | 01:39 |
| igc | lifeless: do you mean delta-based code or the iter-changes change? The delta-based code is certainly not going into to 0.91 | 01:40 |
| lifeless | the iter changes change | 01:41 |
| igc | fair enough - it's a risky area .... | 01:41 |
| igc | which is why I asked the Q re benefit/risk in the submission | 01:41 |
| igc | lifeless: I felt it was useful to get out there in any case ... | 01:43 |
| igc | it's a clean patch you can apply to your stuff while benchmarking initial commit for example | 01:43 |
| igc | it's also a "better" routine to move to your iterator from than the existing one I suspect | 01:44 |
| lifeless | 48% of time is in record_revision at the moment | 01:47 |
| lifeless | thata 1m30 | 01:47 |
| lifeless | we know that the whole commit can be done in 1m | 01:48 |
| lifeless | so there should be about 50% fat there | 01:48 |
| jelmer | lifeless: ok, version info is fixed now. if you find the bug, please let me know so we can close it + mention the bug # in NEWS | 01:49 |
| lifeless | :) | 01:49 |
| lifeless | danke | 01:49 |
| keir | lifeless, you mentioned in a list email sometime ago that you wanted to write a high-speed index layer | 02:14 |
| keir | lifeless, is that done yet? | 02:14 |
| keir | lifeless, and if not, where do i start? | 02:14 |
| lifeless | hi | 02:15 |
| lifeless | its not done yet | 02:15 |
| lifeless | the index layer thats needed is currently implemented as bzrlib.index | 02:16 |
| keir | basically, i'd love to help, but i'm not familiar with the innards of bzr | 02:16 |
| lifeless | I have a branch up at http://people.ubuntu.com/~robertc/baz2.0/index | 02:16 |
| lifeless | if you look inside bzrlib/index.py | 02:16 |
| lifeless | and bzrlib/tests/test_index.py | 02:16 |
| keir | however i love writing high speed c code :) | 02:16 |
| === mw is now known as mw|out | ||
| lifeless | you can see the current layer | 02:16 |
| keir | which ops would this speed up? | 02:17 |
| lifeless | the python code is performing quite well | 02:17 |
| lifeless | what needs changing is the disk format primarily | 02:17 |
| lifeless | after that is made efficient doing a C version becomes a discussion point | 02:17 |
| keir | ok | 02:17 |
| keir | i buy that | 02:17 |
| lifeless | the current disk format is bisectable but I haven't written bisection code yet | 02:17 |
| lifeless | however it could be better | 02:17 |
| keir | so i should focus on 1) understanding current format | 02:18 |
| keir | 2) make new format | 02:18 |
| lifeless | e.g. a 4K node size b*tree would give something like 20-way fan out compared to 2-way for bisection | 02:18 |
| lifeless | I'd suggest | 02:18 |
| lifeless | 1) understand the index API | 02:18 |
| lifeless | 2) discuss with me on the list your ideas for a new format | 02:18 |
| keir | ok | 02:19 |
| lifeless | I'll probably remember/realise constraints that are not documented that will impact your design | 02:19 |
| lifeless | 3) go do it :) | 02:19 |
| keir | what i'd like to do is make a very compact format which needs to be rebuilt occasionally | 02:19 |
| lifeless | there is no need to keep the current format code - you can replace it in-place | 02:19 |
| lifeless | (its documented as being unstable) | 02:19 |
| keir | we did some super cool hacking on our project (astrometry.net) to make 1gb trees which have to pointers and other coolness. they can be mmaped directly from disk! | 02:19 |
| lifeless | ok this suggests a couple of immediate things to highlight | 02:20 |
| lifeless | the index layer has write-once indices | 02:20 |
| keir | *have no pointetrs* | 02:20 |
| keir | cool | 02:20 |
| lifeless | each pack transaction adds a new pack, and new indices for that one pack | 02:20 |
| lifeless | we don't modify existing files because that is problematic - permissions, and appending and data integrity | 02:21 |
| keir | ok | 02:21 |
| lifeless | we can't rely on mmap because indices may be on sftp/ftp/http servers | 02:21 |
| keir | of course, but if it's local, then you can do that. | 02:21 |
| lifeless | indices can be big - mozilla's text index is 200MB | 02:21 |
| keir | is there a 'bzr for computer scientists' link somewhere? | 02:22 |
| lifeless | well mmap has portability issues. So mmap might be an optimisation, but we need to avoid full-index access regardless because of the size indices grow too | 02:22 |
| keir | of course; mmap'ing has the very desirable property that only the necessary parts are read | 02:22 |
| lifeless | doc/developers/repository.txt has some notes about indexing, and the comments and docstrings and source text have more | 02:23 |
| keir | your OS handles smart caching and even sharing previously read pages between processes | 02:23 |
| lifeless | except that read errors show up as segfaults | 02:23 |
| lifeless | which can make diagnosis rather hard. | 02:23 |
| keir | true | 02:23 |
| keir | well, first a new disk format then speeding it up | 02:23 |
| lifeless | I'm not saying 'dont use mmap at all', I'm saying that mmap would be a 4), like a C version. | 02:23 |
| keir | :) | 02:24 |
| lifeless | something that we should not design-in, but its not harmful if its possible for mmap to be used in future. | 02:24 |
| keir | the other thing i've come to appreciate, that makes me feel sooo 1980, is fixed-width file formats like FITS. | 02:25 |
| Peng | Huh. I tried to branch baz2.0/index with 0.90, and it errored out about not supporting the format (duh), and then I tried with the pack branch, and it branched 0 revisions. I had to rm -rf the index dir and try again. | 02:25 |
| === Peng wanders off. | ||
| lifeless | Peng: it waspushing | 02:25 |
| keir | anyway, i'll think about it | 02:25 |
| lifeless | Peng: try now | 02:25 |
| lifeless | keir: yah, we have variale length keys | 02:25 |
| lifeless | keir: oh, and we don't have a seek() interface to files, only readv | 02:26 |
| Peng | lifeless: Oh. | 02:26 |
| Peng | lifeless: Okies. | 02:26 |
| Peng | lifeless: yeah, it did work when I tried it again. | 02:26 |
| keir | lifeless, this is because of transports? | 02:26 |
| lifeless | keir: also forward-only IO is faster than random access, and a single readv() is much faster than 10 readv() covering the same data due to reduced roundtrips | 02:26 |
| lifeless | keir: its because of the internet:) | 02:26 |
| keir | how do pack-based repos fit into this? | 02:28 |
| lifeless | pack based repos are the only user of the index layer | 02:28 |
| keir | would a superfast index speed much up? or would it be optimizing 10%? | 02:29 |
| lifeless | oh | 02:29 |
| lifeless | well depends on the case | 02:29 |
| lifeless | 'bzr cat http://mozila.org/bzr/trunk/ChangeLog' (as a hypothetical) | 02:30 |
| lifeless | should go from downloading > 200MB of index data | 02:30 |
| lifeless | to downloading (say) 64K | 02:30 |
| keir | heh, ok | 02:30 |
| lifeless | there are also common query patterns to consider | 02:30 |
| lifeless | these indices have graphs embedded in them | 02:30 |
| lifeless | At the moment graph walking is done by repeated queries to the index | 02:31 |
| keir | ok | 02:31 |
| keir | why are the graph keys variable-length? | 02:31 |
| lifeless | probably the index wants to cache data it has accessed in some manner | 02:31 |
| lifeless | the keys are tuples with a fixed number of byte-strings; but each byte-string is variable length | 02:32 |
| lifeless | revision ids are variable length | 02:32 |
| lifeless | file ids likewise | 02:32 |
| keir | ok. | 02:32 |
| keir | i have to run now but i'll be back | 02:32 |
| lifeless | ok | 02:32 |
| lifeless | anyhow graph walking is kindof pathological | 02:32 |
| lifeless | many queries in a row going from parent to child each time | 02:33 |
| lifeless | only a topological sort can give locality of reference on such things | 02:33 |
| lifeless | and we also have the combining of separate index files to accommodate | 02:34 |
| === orospakr [n=orospakr@CPE001a70d1de84-CM0019474a8676.cpe.net.cable.rogers.com] has joined #bzr | ||
| === michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr | ||
| Peng | Woah. One 56 MB pack and one 55 MB one. Not super disk-efficient. | 03:03 |
| === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr | ||
| === jeremyb_ is now known as jeremyb | ||
| lifeless | Peng: you are using an old pack branch I bet | 04:06 |
| lifeless | Peng: that was fixed way back | 04:06 |
| === ionstorm [n=ion@70-58-119-250.phnx.qwest.net] has joined #bzr | ||
| === jdong [n=jdong@ubuntu/member/jdong] has joined #bzr | ||
| === Verterok [n=Verterok@184-220-114-200.fibertel.com.ar] has joined #bzr | ||
| === AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr | ||
| === orospakr [n=orospakr@CPE001a70d1de84-CM0019474a8676.cpe.net.cable.rogers.com] has joined #bzr | ||
| === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr | ||
| === jml [n=jml@ppp108-61.static.internode.on.net] has joined #bzr | ||
| lifeless | spiv: when you so 'selftest Remote' do you see unlock errors? | 05:02 |
| keir | i sent a merge message to the list, but it hasn't shown up | 05:10 |
| keir | might it be caught in moderator limbo? i did subscribe. | 05:10 |
| keir | from mierle@gmail.com | 05:10 |
| spiv | lifeless: I'll check | 05:11 |
| spiv | lifeless: but I didn't last night. | 05:11 |
| lifeless | keir: I haven't seen one | 05:11 |
| lifeless | [5484/8093 in 432s, 296 skipped, 4 missing features] branch_implementations.test_locking.TestBranchLocking.test_unlock_after_lock_write_with_token(RemoteBranchFormat) / | 05:12 |
| lifeless | home/robertc/source/baz/commit/bzrlib/lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.remote.RemoteTCPTransport url=bzr://127.0.0.1:52245/b/.bzr/repository/>) was not explicitly unlocked | 05:12 |
| lifeless | warn("file group %r was not explicitly unlocked" % self) | 05:12 |
| spiv | lifeless: it passes for me. I see unlock warnings though. | 05:12 |
| lifeless | could you fix please :) | 05:12 |
| spiv | Right. Those have been there for ages. | 05:12 |
| lifeless | I blame you with reason | 05:12 |
| lifeless | but perhaps not accuracy | 05:12 |
| spiv | I took a quick look a few days ago, actually, but it's messy. | 05:13 |
| spiv | I think it may require untangling some of the mess in Remote{Repository,Branch}._ensure_real | 05:13 |
| lifeless | surely not | 05:13 |
| lifeless | surely its just a bug that something is wrong in nlock() ? | 05:14 |
| === vaidhy [n=chatzill@61.11.88.65] has joined #bzr | ||
| spiv | That test does: | 05:15 |
| spiv | # We only want to test the relocking abilities of branch, so use the | 05:15 |
| spiv | # existing repository object which is already locked. | 05:15 |
| spiv | new_branch.repository = branch.repository | 05:15 |
| spiv | new_branch.lock_write(token=token) | 05:15 |
| spiv | new_branch.unlock() | 05:15 |
| vaidhy | I am trying to push my changes in bzr using webdav and it fails everytime.. Has anyone used webdav to push successfully? | 05:15 |
| spiv | which seems to cause confusion when branch.unlock happens. | 05:15 |
| spiv | Because the repository's lock state has been twiddled in some way. | 05:16 |
| lifeless | vaidhy: I don't know; perhaps you could mail the list or file a bug on the webdav plugin ? | 05:16 |
| vaidhy | that is my next step.. I was hoping to catch vila so that I can ask him :) | 05:16 |
| lifeless | hes in franch | 05:17 |
| lifeless | so this is not a good time for catching him | 05:17 |
| vaidhy | ok.. let me email the list.. | 05:17 |
| === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr | ||
| poolie_ | lifeless, re special casing initial commit | 05:26 |
| poolie_ | i'm kind of sympathetic | 05:26 |
| lifeless | your _ is showing | 05:26 |
| poolie_ | i know | 05:26 |
| poolie_ | irc sucks | 05:26 |
| poolie_ | or maybe i'm a member variable | 05:26 |
| poolie_ | anyhow, it does seem a bit arbitrary | 05:26 |
| lifeless | yup | 05:27 |
| poolie_ | maybe we should just say 'commit is faster if you do -q' | 05:27 |
| lifeless | I think thats fine too | 05:27 |
| poolie_ | and ask people to do that for bulk imports or benchmarking | 05:27 |
| lifeless | I'd like us to not change the default verbosity level | 05:27 |
| poolie_ | ok | 05:27 |
| lifeless | I'm happy with special casing initial commit | 05:27 |
| lifeless | because though it is arbitrary, its the least useful time for commit output whent here are k's of files. | 05:27 |
| vaidhy | can I specify a port for sftp in bzr? | 05:28 |
| poolie_ | so would -v still show them? | 05:28 |
| lifeless | poolie_: that is what I was proposing | 05:28 |
| lifeless | vaidhy: sftp://host:port/ should work | 05:28 |
| vaidhy | ok. thanks | 05:28 |
| === keir votes for special casing initial commit | ||
| poolie_ | lifeless, as long as the help text makes it clear, it's ok with me | 05:30 |
| keir | actually i think we should have a single command to do init, add *, commit too :) | 05:30 |
| Peng | lifeless: One of the packs was last modified 2007-08-25 and the other 2007-08-30. I've been keeping pretty up-to-date. | 05:31 |
| keir | bazaar@lists.canonical.com | 05:32 |
| keir | is that the right place to 'bzr send' to? | 05:32 |
| lifeless | Peng: check the branch you used, not the date of the packs :) | 05:32 |
| lifeless | Peng: it definately doesn't do that for me | 05:32 |
| lifeless | keir: yes | 05:32 |
| keir | weird | 05:32 |
| keir | it's there in my sent mail on gmail, to that address | 05:32 |
| Peng | lifeless: I would've been using the latest version of the branch from those days. | 05:32 |
| Peng | lifeless: Or possibly the knit version of it. | 05:33 |
| lifeless | poolie_: I was thinking something like the builtins.py code doing 'Initial commit - setting default verbosity to -q. You can can interrupt the commit, or run bzr uncommit, then commit again with -v to see the files being added.' | 05:33 |
| keir | where should i send my patch? for whatever reason the list isn't getting through | 05:34 |
| keir | the irony is not lost on me (my patch is for bzr send) | 05:34 |
| lifeless | Peng: check bzr st and bzr revno in the branch you ran bzr from :) | 05:34 |
| poolie_ | keir, i'll check the mail feature | 05:34 |
| lifeless | keir: perhaps file a bug and attach the branch ? | 05:34 |
| poolie_ | lifeless, what is that quoted string? the news entry? the help? | 05:34 |
| lifeless | poolie_: output | 05:34 |
| lifeless | poolie_: I don't think help really needs to mention it | 05:35 |
| lifeless | but it could | 05:35 |
| poolie_ | that would be printed to stdout? | 05:35 |
| Peng | lifeless: I updated it today. | 05:35 |
| poolie_ | i don't like that so much | 05:35 |
| Peng | Huh. | 05:35 |
| lifeless | poolie_: ok it was a thought | 05:35 |
| poolie_ | i'd rather add to the help message | 05:35 |
| Peng | I ran "bzr pack", and now there's the 56 MB one and a new 56.6 MB one. | 05:35 |
| Peng | And some small ones. | 05:35 |
| Peng | But not as many as there were before. | 05:36 |
| lifeless | Peng: oh hmm.. can you check th epack files against pack-names ? | 05:36 |
| keir | lifeless, the branch is not public | 05:36 |
| poolie_ | 'for the initial commit in a branch, which typically adds many files, the filenames are not printed unless -v is given. in every other case, the changes are shown unless -q is given.' | 05:36 |
| poolie_ | keir, i don't see it in mailman | 05:36 |
| lifeless | Peng: there is a small race condition where the pack is added to the dir then the pack-names index is updated | 05:36 |
| poolie_ | can you please forward your message to me mbp@canonical.com, including the original message-id, if you have ti | 05:36 |
| lifeless | Peng: a crash at the wrong time will leave an unreferenced .pack file | 05:37 |
| Peng | lifeless: pack-names seems to only list the new 56.6 MB one. | 05:37 |
| keir | poolie_, i just re-sent it to bazaar@lists.canonical.com, this time manually (rather than via gmail SMTP) | 05:37 |
| lifeless | there you go | 05:37 |
| Peng | lifeless: I don't think I've crashed it. | 05:37 |
| lifeless | ctrl-C'd it ? | 05:37 |
| Peng | Nevar! | 05:37 |
| Peng | Hold on. TV is more fun than packs. | 05:38 |
| poolie_ | lifeless, i agree about watching for the performance impact of changes | 05:38 |
| igc | poolie_: I like that wording. I'll grab some lunch then resubmit my patch to be 'initial commit less verbose' | 05:38 |
| === igc lunch | ||
| keir | weird, it must be my gmail send that is broken. | 05:38 |
| poolie_ | speaking of which | 05:39 |
| poolie_ | http://benchmark.bazaar-vcs.org/usertest/usertest.log | 05:39 |
| keir | i'm trying to setup a bzr send + gmail tutorial | 05:39 |
| poolie_ | shows good results, except that script_common.AddTask:status is three times slower than 0.17 | 05:39 |
| poolie_ | can this really be true? | 05:39 |
| poolie_ | keir, that'd be good | 05:39 |
| lifeless | I think it can be true | 05:39 |
| poolie_ | or maybe we can have gmail as a mail_client? | 05:39 |
| keir | there are all these complicated ways to send mail via gmail | 05:40 |
| keir | but you can do it in 10 lines of python (including tls) via smtplib | 05:40 |
| poolie_ | keir, i got your patch about python | 05:40 |
| poolie_ | i mean, mutt | 05:40 |
| keir | poolie_, yeah, i sent it a 2nd time manually rather than via bzr send | 05:40 |
| keir | gmail as a mail client would be really nice, but i don't see how we can automatically add attachments | 05:41 |
| keir | so the next closest thing i came up with is to use mutt + gmail smtp backend | 05:41 |
| keir | but i really feel good gmail integration is a killer feature | 05:41 |
| poolie_ | mm | 05:41 |
| poolie_ | i would like that, as i use gmail myself | 05:41 |
| lifeless | keir: file a bug on gmail:) | 05:41 |
| keir | exactly | 05:41 |
| poolie_ | i typically just write to a file then paste that into the compose window | 05:41 |
| poolie_ | so it's a bit manual | 05:41 |
| keir | that's too annoying for me :) i'm a usability snob | 05:42 |
| poolie_ | i'm very happy you're looking at it | 05:42 |
| poolie_ | i agree it would be a great feature | 05:42 |
| keir | what i have now is pretty decent; bzr send pops up mutt, then i 'set sendmail=~/bin/gmail_send.py" which uses python's smtplib to send | 05:42 |
| keir | then your mail shows up in gmail outbox | 05:43 |
| keir | poolie_, would that be good enough for you? or do you really want the web interface too? | 05:43 |
| poolie_ | i'm going for a bit | 05:43 |
| poolie_ | keir, that would be ok | 05:43 |
| Peng | lifeless: So bzr forgot about the one pack in the past, and left it there this time? Or did it forget about it just now? | 05:43 |
| poolie_ | it might be cleaner if it just got a message from $EDITOR then sent the mail directly | 05:43 |
| poolie_ | as not everyone has mutt | 05:44 |
| keir | poolie_, true, but bzr send as editor botches the filename and mime stuff | 05:44 |
| keir | besides, edit-headers is super handy | 05:44 |
| lifeless | Peng: probably some time ago | 05:44 |
| lifeless | Peng: whats the date on it | 05:44 |
| keir | one issue is: i have to store gmail pw somewhere | 05:45 |
| keir | should i store it rot13'd? | 05:45 |
| poolie_ | actually you should look at vila's auth ring spec | 05:45 |
| poolie_ | it's not implemented yet but he wants to add a standard store for these things | 05:46 |
| Peng | lifeless: It's the 2007-08-25 one. | 05:46 |
| lifeless | I still think netrc is the right place ;) | 05:46 |
| Peng | lifeless: The mtime, you mean? | 05:46 |
| lifeless | yah | 05:46 |
| lifeless | we never modify packs | 05:46 |
| Peng | Right. | 05:47 |
| === Peng wanders off. | ||
| keir | regarding auth, can we use a ssh key? | 05:50 |
| keir | everyone has pub/priv ssh keys; i figure it'd be neat if we could use those to store the pw's | 05:51 |
| lifeless | uhm | 05:51 |
| lifeless | some people get obsessive about such things, having unaudited code access passphrases is generally bad | 05:51 |
| keir | possibly. | 05:52 |
| lifeless | I'm one of those people :) | 05:52 |
| keir | heh, ok | 05:52 |
| keir | where is the right place to put a 'bzr with gmail' page? | 05:53 |
| lifeless | I'd be putting it in the bzr send help, or a help topic in a seealso from that | 05:53 |
| keir | ok | 05:54 |
| keir | i wonder how hard it would be to have bzr notice recent bundles floating around on the ML, then just pick one and merge it | 05:55 |
| keir | rather than dl'ing them | 05:55 |
| AfC | [I'm a bit vague about why you're wondering about keyrings, but as of 2.18 or so we have a good one built in; bzr should probably consider just talking to it] | 05:56 |
| keir | 2.18? | 05:56 |
| keir | gnome you mean? | 05:56 |
| AfC | Of course | 05:56 |
| keir | python api? | 05:56 |
| AfC | I imagine so | 05:57 |
| keir | cool | 05:57 |
| keir | ok, maybe i'll do that now | 05:57 |
| lifeless | I think making the backend pluggable might be good | 05:57 |
| lifeless | but we need to support | 05:57 |
| lifeless | windows | 05:57 |
| lifeless | console unix | 05:58 |
| lifeless | gnome | 05:58 |
| lifeless | kde | 05:58 |
| keir | well, for sending to gmail, it's kinda specific | 05:58 |
| keir | i just need a sendmail work-alike | 05:58 |
| lifeless | fluxbox and other such things | 05:58 |
| keir | my python script is 10 lines right now, but has my pw in the clear | 05:58 |
| lifeless | keir: just prompt for the password ? | 05:58 |
| lifeless | bzrlib has a password prompt routine | 05:58 |
| AfC | I find that so frustrating. Who gives a hoot about the rest of them? This project is paid for by Canonical, whose primary product is a GNOME desktop. Why would we give up a better user experience in our environment to support the platforms of non-free vendors? | 05:59 |
| keir | if others want to do that, sure, but all i want is a super slick bzr send for my env of choice, ubuntu :) | 06:00 |
| AfC | keir: exactly. | 06:00 |
| lifeless | AfC: Wow, lets address a few points there. Its only partly paid for by Canonical. Its primarily an open source project. | 06:00 |
| lifeless | AfC: secondly, Kubuntu and Xubuntu are both primary products along with Ubuntu. | 06:00 |
| lifeless | AfC: thirdly Windows is a strategic user base for us because many open source projects - including chunks of Gnome - build or otherwise target windows. Not supporting windows for infratructure like VCS is bad. | 06:01 |
| lifeless | AfC: Lastly no one talked about giving up user experience. | 06:02 |
| lifeless | so that minirant was IMO entirely aimed at a strawman | 06:02 |
| AfC | I didn't say not supporting Windows. I said to treat them like the second class citizens they deserve yo be, and not crippling or giving up a potentially better desktop integration in _our_ environments. Taking today's example, GNOME has a desktop wide keyring agent facility; it would be tremendous to integrate cleanly with it, rather than being yet another stand-alone program that doesn't integrate with anything. | 06:03 |
| === orospakr [n=orospakr@CPE001a70d1de84-CM0019474a8676.cpe.net.cable.rogers.com] has joined #bzr | ||
| lifeless | AfC: You are clearly arguing with some position you *think* I've taken, rather than what I have said or proposed. | 06:06 |
| lifeless | so I'm going to go back to making commit faster | 06:06 |
| === AfC files this away for use at his next conference. | ||
| keir | in the meantime, i figured out how to use gnome keyring from python :) | 06:09 |
| AfC | keir: which library was it in? | 06:13 |
| fullermd | Gnome? What is this 'gnome' of which you speak? :p | 06:14 |
| keir | afc: http://www.rittau.org/blog/20070726-01 | 06:17 |
| lifeless | I'm popping out for a walk, thinking through therestructuring | 06:28 |
| lifeless | poolie_: if you are idle and wanted to ring my mobile to be an idea bouncer that might be useful | 06:29 |
| igc | so lifeless, poolie_: less verbose on initial commit only is agreed yes? | 06:30 |
| === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr | ||
| lifeless | hi abentley | 06:59 |
| lifeless | igc: I think so | 06:59 |
| abentley | Hi. | 06:59 |
| igc | hi abentley | 06:59 |
| lifeless | abentley: what are your thoughts on defaulting commit to -q for first-commit only | 07:06 |
| abentley | lifeless: I'd prefer to use -q all the time-- don't like inconsistency. | 07:07 |
| lifeless | abentley: I don't either; AFAICT the use case for this is benchmarking folk that don't take terminal overhead into account | 07:09 |
| lifeless | I like the current output | 07:09 |
| lifeless | I don't want regular commits to lose that | 07:09 |
| igc | lifeless: that not quite true ... | 07:09 |
| igc | it's not terminal overhead | 07:09 |
| igc | it's the overhead of deciding on the nature of a change | 07:10 |
| lifeless | well | 07:10 |
| lifeless | on first commit that should be nearly zero | 07:10 |
| lifeless | it can be special cased to have everything new | 07:10 |
| igc | sounds right | 07:11 |
| lifeless | so why do you want to change the default verbosity to -q then? That was never answered to my satisfaction I guess | 07:11 |
| igc | it's also the UI question of just how useful listing 100s of files is on initial commit | 07:12 |
| abentley | igc: That's one case of initial commit. | 07:12 |
| abentley | The other case has two or three files. | 07:12 |
| igc | please don't use -q -that's separate again | 07:12 |
| lifeless | you've lost me | 07:13 |
| igc | -q is no output | 07:13 |
| igc | the proposal was for ocmmit to just show the "Commited revision n" msg | 07:13 |
| === igc digs ... | ||
| igc | https://lists.ubuntu.com/archives/bazaar/2007q2/027044.html | 07:14 |
| igc | the change was a better UI | 07:14 |
| igc | the performance gain was a side benefit | 07:14 |
| abentley | Oy, so it's not even consistent with -q. | 07:14 |
| lifeless | garh | 07:14 |
| lifeless | igc: I don't think hiding the changed paths list is better | 07:15 |
| lifeless | I'd tolerate it for first-commit only, when there are many files, if that was trivial to detect performance wise | 07:15 |
| igc | I understand | 07:15 |
| abentley | It's especially not better for new projects, where there's only a few files to commit, and the inconsistency will be surprising. | 07:16 |
| lifeless | or for first-commit only, though as abentley says that has higher surprise factor | 07:16 |
| igc | the theory was that most other VCSs don't show the info unless -v was specified | 07:16 |
| lifeless | and we're better than them. | 07:16 |
| lifeless | thats our raison d'etre | 07:16 |
| igc | sure ... | 07:17 |
| lifeless | anytime we look at what another VCS does in terms of behaviour we have to get the rationale | 07:17 |
| igc | but that's not what everyone said in the mailing list thread above :-) | 07:17 |
| abentley | What mailing list thread? Something that happened in the last 12 hours? | 07:18 |
| igc | https://lists.ubuntu.com/archives/bazaar/2007q2/027044.html | 07:18 |
| igc | in the last 12-15 hrs, I've put up a patch - which was consistent | 07:19 |
| igc | it was then suggested we special case it for initial commit only | 07:19 |
| igc | which I just started doing but haven't done | 07:20 |
| lifeless | igc: I am planning a new method on mutable tree | 07:21 |
| lifeless | 'path_content_summary' | 07:21 |
| igc | sounds nice | 07:21 |
| igc | what does it return? | 07:21 |
| lifeless | igc: this will return a tuple: (kind, size or None, executable, sha or None) | 07:21 |
| lifeless | size is None for things that have no Size | 07:21 |
| igc | that will help | 07:21 |
| lifeless | same for exec | 07:21 |
| lifeless | sha is returned if it can be got from hash cache only | 07:21 |
| lifeless | I plan to use this to delete _read_tree_state | 07:22 |
| igc | dirstate is fast but one lookup is better than multiple | 07:22 |
| igc | hooray for _read_tree_state being nuked ... | 07:22 |
| igc | it's not like I haven't been trying to do that :-) | 07:22 |
| lifeless | I did suggest how to get to it when you started on commit :) | 07:23 |
| === sverrej_ [n=sverrej@tul-1x-dhcp013.studby.uio.no] has joined #bzr | ||
| keir | is there an easy way to query a pw and not show it in python? | 07:41 |
| lifeless | pydoc bzrlib.ui | 07:41 |
| keir | my gmail send util is independent of bzr | 07:41 |
| lifeless | and ? | 07:41 |
| lifeless | :) | 07:41 |
| lifeless | bzrlib is a library | 07:41 |
| keir | heh | 07:41 |
| lifeless | also | 07:41 |
| lifeless | you can look at the code we have | 07:42 |
| lifeless | to see how to do it | 07:42 |
| keir | true :) | 07:42 |
| === luks [i=lukas@unaffiliated/luks] has joined #bzr | ||
| jml | also 'pydoc getpass' | 07:42 |
| lifeless | tooeasy.com | 07:43 |
| lifeless | abentley: ping | 07:54 |
| abentley | lifeless: muh? | 07:54 |
| lifeless | tree._comparison_data | 07:55 |
| lifeless | there's no docstring, I'm trying to figure out why it returns the raw stat, and never the sha | 07:55 |
| lifeless | I guess that what I'm working on is basically in the same api space and don't want to duplicate unnecessarily | 07:56 |
| lifeless | I was going to write path_content_summary that would take just a path and return (kind, size-or-none, exec-or-none, sha-or-none) | 07:57 |
| abentley | Well, I suppose it *could* pass the sha1, when needed. But what actually happens is that the stat value is examined, and if it needs the sha1, it uses the stat value to get it. | 07:57 |
| lifeless | ah | 07:57 |
| lifeless | whats entry there for - win32 ? | 07:58 |
| abentley | It's quite possible that there are cleaner ways to do this. | 07:58 |
| abentley | The entry's for revision trees. | 07:59 |
| lifeless | ok | 07:59 |
| abentley | G'night. | 07:59 |
| lifeless | I think I'll my little API up and ask you to comment on it's usefulness | 07:59 |
| lifeless | I want it for commit, and don't want 'entry' there | 07:59 |
| lifeless | but I can look at moving _iter_changes onto my api, or reusing _comparison_data if that makes more sense | 08:00 |
| lifeless | gnight, sleep well | 08:00 |
| lifeless | ciaoish | 08:10 |
| === ionstorm [n=ion@70-58-119-250.phnx.qwest.net] has joined #bzr | ||
| keir | well, i have a nice gmail sendmail replacement which uses gnome keyring to store pw's now | 08:37 |
| keir | what is the default bzr url for trunk when you register a new project on launchpad? | 08:39 |
| === abadger1999 [n=abadger1@65.78.187.68] has left #bzr [] | ||
| === allenap [n=allenap@212.233.37.68] has joined #bzr | ||
| === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr | ||
| poolie_ | keir? | 09:10 |
| poolie_ | oh, typically something like | 09:10 |
| poolie_ | sftp://bazaar.launchpad.net/~keir/bzr-gmail/trunk | 09:10 |
| poolie_ | you can use any branch name you like for the last component | 09:11 |
| keir | poolie_, yup, i got it | 09:12 |
| keir | poolie_, can you try something for me? | 09:12 |
| poolie_ | sure | 09:13 |
| keir | poolie_, http://bazaar-vcs.org/BzrSendWithGmail | 09:13 |
| keir | see if you can get it to work | 09:13 |
| keir | sadly this is rather gnome/unix specific | 09:13 |
| keir | i really believe we need slick all-platform gmail support, but this is better than nothing | 09:13 |
| === g0ph3r [n=g0ph3r@p57A0A160.dip0.t-ipconnect.de] has joined #bzr | ||
| === sverrej [n=sverrej@tul-1x-dhcp013.studby.uio.no] has joined #bzr | ||
| keir | poolie_, i'm sleepy (in EST) so let me know if you have any success. mierle@gmail.com | 09:18 |
| === tca [n=tom@ti541110a080-5238.bb.online.no] has joined #bzr | ||
| poolie_ | ok | 09:18 |
| keir | poolie_, also i'd like to write tests for gsendmail.py, but i'm not sure how/what to test because it's all API! | 09:18 |
| poolie_ | Password: | 09:20 |
| poolie_ | Traceback (most recent call last): | 09:20 |
| poolie_ | File "gsendmail.py", line 137, in <module> | 09:20 |
| poolie_ | sys.exit(main(options, args)) | 09:20 |
| poolie_ | File "gsendmail.py", line 108, in main | 09:20 |
| poolie_ | gmail_key_ring.set_credentials((gmail_addr, pw)) | 09:20 |
| poolie_ | File "gsendmail.py", line 75, in set_credentials | 09:20 |
| poolie_ | gkey.ITEM_NETWORK_PASSWORD, self._name, attrs, pw, True) | 09:20 |
| poolie_ | gnomekeyring.DeniedError | 09:20 |
| poolie_ | it asked me for an initial keyring password, then this. | 09:20 |
| AfC | poolie_: credential not [yet] stored, maybe? | 09:21 |
| poolie_ | keir, when i tried a second time it seemed to work | 09:22 |
| === mvo [n=egon@p54A6734A.dip.t-dialin.net] has joined #bzr | ||
| AfC | What timezone is Jelmer in? | 09:27 |
| poolie_ | +1 or +2 | 09:28 |
| === jml [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr | ||
| === mvo_ [n=egon@p54A6734A.dip.t-dialin.net] has joined #bzr | ||
| AfC | poolie_: thanks | 09:49 |
| === anandn [n=anandn@59.163.70.253] has joined #bzr | ||
| mwhudson | +2 right now | 10:10 |
| === hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr | ||
| AfC | poolie_: got a sec? | 10:29 |
| poolie_ | yes | 10:30 |
| AfC | poolie_: using the bzr bundle command (as recently amended to be bzr send, really), the command line is now (and perhaps for some time) has "submit branch" and "public branch" as arguments. | 10:35 |
| AfC | poolie_: trying to figure out what these mean, I ran help, and was somewhat lost after reading the description there | 10:35 |
| AfC | poolie_: so I poked around | 10:35 |
| AfC | and have the following [as ever, from an "outsider"'s perspective] | 10:36 |
| === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr | ||
| AfC | poolie_: http://rafb.net/p/imxMEp87.html | 10:36 |
| AfC | which is bzr info on three different branches here | 10:36 |
| igc | latest commit reporting patch/proposal send to the list | 10:36 |
| AfC | The first one makes sense (although I'm not entirely sure how ../primary is the parent of mainline) | 10:36 |
| igc | time for some food & time with the kids | 10:37 |
| igc | night all | 10:37 |
| === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr | ||
| AfC | The second one (where I have run bzr bundle (send) at least once since 0.90), is a bit more confusing | 10:37 |
| AfC | indeed, my thought was that it was all a bit repetitive. | 10:37 |
| poolie_ | it's not so obvious how these locations match up to other operations | 10:38 |
| poolie_ | i have been wondering if we should perhaps say | 10:38 |
| AfC | Then the third one, from one of the contributors whom I've given access to create branches on our server, is really confusing. | 10:38 |
| poolie_ | defaults for: | 10:38 |
| AfC | Yeah | 10:38 |
| poolie_ | push: ... | 10:38 |
| poolie_ | merge source: ... | 10:38 |
| poolie_ | public location: | 10:38 |
| AfC | So I can sorta guess where each might have come from, but it's all inference and, as you say, its not clear how it aligns | 10:38 |
| AfC | [and .bazaar/locations.conf also confuses me - at one point I was wondering if I was supposed to edit THAT. Ick. Classic case of just enough knowledge to be dangerous to oneself] | 10:39 |
| AfC | End of first impression | 10:39 |
| === gabe_ [n=gabriel@91.84.56.254] has joined #bzr | ||
| poolie_ | so do you think just making it more clear how they map to commands or operations would be enough? | 10:41 |
| poolie_ | ideally in both info and the configuration | 10:41 |
| poolie_ | or is it more than that? | 10:41 |
| AfC | poolie_: I suspect so | 10:41 |
| AfC | poolie_: combination of more specific help text, less noise about version this and tagstate-dir that, and what you suggest about where those come from and what they're used for when running info would seem to more than cover it. | 10:42 |
| rotty` | how does one list bzr repos in config-manager "configs"? | 10:43 |
| AfC | [alternately, you could make these public, submit, parent, etc the first class items, and change the text of `push`, `pull`, etc to state that they use "the public branch" or "this command will diff by default from the submit branch" or whatever | 10:44 |
| === dhon__ [n=dhon@60-240-97-109.static.tpgi.com.au] has joined #bzr | ||
| === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr | ||
| poolie_ | rotty`, i think just by the url? | 10:47 |
| poolie_ | for the branch? | 10:47 |
| rotty` | (it always tells me "Unknown url type") | 10:47 |
| poolie_ | there's an example in the configmanager source | 10:47 |
| poolie_ | i don't have it on this machine... | 10:48 |
| poolie_ | rotty`, maybe you have a really old configmanagere version | 10:53 |
| thumper | are there any Solaris 10 packages for bzr somewhere? | 10:55 |
| poolie_ | thumper, i don't know of current packages | 10:57 |
| thumper | are they easy to make? | 10:58 |
| thumper | or do you need a Solaris person? | 10:58 |
| === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr | ||
| === herzel [i=herzel@gateway/tor/x-516b114cd89b0639] has joined #bzr | ||
| rotty` | poolie_: where do I get the newest config-manager? | 11:14 |
| poolie_ | rotty`, that's a really good question | 11:17 |
| poolie_ | i was sure it was on launchpad but i can't find it | 11:18 |
| poolie_ | rotty`, i suggest you mail bazaar@lists.canonical.com | 11:23 |
| poolie_ | i'm going to call it a night | 11:24 |
| alla | is the submit-by-mail plugin still supported? or is there a better way to email and apply patches? | 11:30 |
| luks | not sure what does the plugin do, but there is 'bzr send --mail-to XXX' in bzr 0.90 | 11:31 |
| alla | ooh | 11:31 |
| alla | bzr: ERROR: unknown command "send" | 11:32 |
| alla | Using 0.17.0 | 11:33 |
| spiv | alla: yeah, it's a pretty new command. | 11:33 |
| spiv | alla: upgrade to 0.90 | 11:33 |
| alla | ooh, I need to upgrade, thanks! | 11:34 |
| luks | oh, wait | 11:35 |
| luks | --mail-to is only in not-yet-released 0.91 | 11:36 |
| alla | hmph. Well how do people normally email patches? | 11:36 |
| luks | 0.90 has only 'send -o' | 11:36 |
| luks | with older versions `bzr bundle >mypatch.diff` and then mail the patch manually | 11:36 |
| luks | with 0.90, `bzr send -o mypatch.diff` | 11:37 |
| === fog [n=fog@debian/developer/fog] has joined #bzr | ||
| alla | I'm upgrading now.. what's -o? | 11:37 |
| luks | --output, it will save the patch to a file | 11:38 |
| AfC | thumper: I must admit that on the one Solaris machine we have, we just installed bzr manually rather than attempting to package it; since Solaris packaging is brain dead anyway. and this machine is not under a proper infrastructure management regime, we didn't worry about it too much. | 11:38 |
| luks | then you can use `bzr merge` or `bzr pull` to apply it | 11:38 |
| alla | luks: surely you cannot `bzr merge` a .diff file ..? | 11:39 |
| alla | oh it's a patch file? | 11:39 |
| luks | it's not a traditional patch file | 11:39 |
| luks | but it's patch-compatible | 11:39 |
| alla | exciting | 11:39 |
| luks | it has all the revision data needed to merge/pull it | 11:39 |
| AfC | [.patch ( .diff ) is a good extension to use for bundles because then mail clients get the MIME type right, so a wise man once told me] | 11:40 |
| alla | AfC: Your syntax does not compute. Are you saying .diff is preferred? | 11:44 |
| AfC | .patch, actually | 11:44 |
| alla | Ok, thanks. | 11:44 |
| === pachi_ [n=pachi@84.76.208.29] has joined #bzr | ||
| === pachi_ [n=pachi@84.76.208.29] has left #bzr ["Information] | ||
| === vila [n=vila@lec67-4-82-230-53-244.fbx.proxad.net] has joined #bzr | ||
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === tchan [n=tchan@lunar-linux/developer/tchan] has joined #bzr | ||
| AfC | Where does the --author option live? (Or is that not released yet?) | 12:11 |
| AfC | [I expected it on commit, but it wasn't there] | 12:11 |
| dato | if you don't see it on commit, then it's not released yet | 12:12 |
| === AfC rather wishes that it just worked automatically, ie, I am cherry picking from someone else's code [branch] , so clearly they [those revisions] are the author | ||
| AfC | What _is_ the difference between "submit branch" and "public branch" in the arguments to bzr bundle|send? | 12:15 |
| luks | submit branch is the target | 12:17 |
| fullermd | I believe 'submit' is "The branch these changes are to be applied to, so the one used to determine the base" | 12:17 |
| luks | public branch is the public location if your branch | 12:17 |
| AfC | Right. So I just did | 12:17 |
| AfC | bzr bundle ../mainline http://research.operationaldynamics.com/bzr/java-gnome/mainline/ | 12:17 |
| AfC | (as I am creating a cherry pick for someone) | 12:17 |
| fullermd | Public would reallyonly be _required_ if you were sending a directive without a built-in bundle. | 12:18 |
| AfC | and, by inspection, the first argument is the branch it "diffs against" (sic), as before | 12:18 |
| fullermd | (it's just informative if there is a bundle) | 12:18 |
| luks | AfC: yes, because that's the branch you want to merge it to | 12:18 |
| AfC | whereas the second conveys "public branch" along which ... well, not sure what that's for, but it seems a nice touch. | 12:18 |
| AfC | but I'm not quite clear on why the bundle needs to record the submit (-> "target") in the bundle. | 12:19 |
| AfC | as ../mainline has no relevance for the recipient. | 12:19 |
| luks | but you can have a merge-directive without bundle | 12:19 |
| AfC | [so maybe I should only do bundles against a connected repo and not against local branches, convenient as that seems?] | 12:19 |
| luks | and use a public location of the target branch | 12:20 |
| AfC | fullermd: er, huh? "sending a directive without a built-in bundle"? How can you send a bundle without its attached patch? | 12:20 |
| AfC | fullermd: it sounds like I've got it backwards, and public branch is something the person is suppose to pull the bundlerevisions from | 12:21 |
| AfC | ? | 12:21 |
| fullermd | Other way around (and you don't send a bundle, you send a merge directive) | 12:21 |
| AfC | (Yikes, but this is confusing) | 12:21 |
| fullermd | You can send a merge directive that contains no revision information, which is just an instruction "Merge rev[s] X[,Y,Z] from $PUBLIC_LOCATION" | 12:21 |
| AfC | fullermd: call it what you will, we're sending that-which-people-send-to-submit-code-for-consideration-for-inclusion-in-the-upstream-project | 12:22 |
| fullermd | Well, it's not a rose. By any other name, it's something different. | 12:22 |
| AfC | fullermd: ah. It is "from $public-branch" | 12:22 |
| fullermd | "bundle" doesn't refer to "The whole output", it's just that part of the output containing the revisions to apply. | 12:22 |
| AfC | hm. So little point in me the upstream maintainer using that | 12:22 |
| AfC | fullermd: the patch in bzr from, sure. | 12:23 |
| fullermd | If you send a directive with a bundle, it's got all that information, and can be used directly to apply to the target branch. | 12:23 |
| AfC | s/from/form as committed revisions/ | 12:23 |
| fullermd | If you send a directive _without_ a bundle, it needs that public branch location since it doesn't have any info internally, and just says "go there". | 12:23 |
| AfC | H | 12:23 |
| AfC | Hm | 12:23 |
| AfC | I guess. Not sure what we'd use that for, but I'm sure you use it for something. | 12:23 |
| luks | AfC: btw, regarding cherry picking and the author info, I wrote this simple hack for it - https://code.launchpad.net/~luks/+junk/bzr-pick | 12:23 |
| fullermd | If you're merging a lot of code from a long-lived branch, say. You don't want to send many 5 meg emails, when you have a existing public location for this previously-experimental-now-landing code. | 12:24 |
| AfC | fullermd: ok, sure. | 12:24 |
| fullermd | For little stuff, 'traditional' directives with the bundle are probably a lot simpler. | 12:24 |
| AfC | fullermd: [assuming such a place exists and the receiving party, by the grace of god, actually has global network access at the time they attempt to use the received email lacking revisions, implying a high level of communication between the parties involved. Fair enough] | 12:25 |
| fullermd | And in those cases, the 'public' info is pretty cosmetic (may be interesting for human reviewers, but it's not needed) | 12:25 |
| fullermd | Well, it's also aimed at being used for automated processes, like PQM. Merge directive is a standard formal format, so it can be used to tell a robot "Go merge this in this way". | 12:26 |
| AfC | fullermd: so we've dispensed with public branch as a needed argument since the revisions in question I'm sending to someone are not, in fact, in mainline (yet, which is the whole point). Fine. From there, I wonder | 12:26 |
| AfC | fullermd: what the value of having the branch I diffed against ("../mainline") included in the bundle with the label "TARGET"? | 12:26 |
| fullermd | Mostly cosmetic, probably. Informative to you, and assuming you have known reasonable-ish local branch naming, informative to your target. | 12:27 |
| fullermd | e.g., if it says "../v1_legacy", the person you send it to could assume that there's a branch for old v1 code that you're making this against, if you fail to mention such. | 12:27 |
| AfC | fullermd: [re PQM, yes, I know, but since mere mortals and other medium size projects with humans rather than robots doing the work need the means to ship revisions around, and bundles (in the old sense of the word) were preserved (thank god) in 0.90 even though merge-directive happens to be the encoding] | 12:28 |
| fullermd | You certainly should mention, though. | 12:28 |
| fullermd | It's probably more a matter of "This info was supplied, so shouldn't be discarded" than "This info will have direct application at the target". | 12:28 |
| AfC | fullermd: re cosmetic - yeah, I suppose, but it has near zero relevance to the receiver and I have to therefore worry not to use anything offencive in my local branch directory names because these names leak. Not super thrilled about htat. | 12:29 |
| fullermd | Sure, if you're sending to humans, a bundle-less directive is probably less interesting than just bashing out an email saying "Hey, look at revs X-Y of my branch at http://...". | 12:29 |
| AfC | fullermd: let me put it this way: bundle-full revisions are a feature we're using and that humans are looking at. | 12:29 |
| fullermd | Oh, well, I think of it as an opportunity to use extra offensivity in my local branch naming, to help thin the herd ;) | 12:29 |
| AfC | fullermd: uh huh :) | 12:30 |
| === AfC adds some notes to the bug he's going to file about this. | ||
| === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr | ||
| fullermd | In that situation, bundle-less directives are probably pretty uninteresting to you (at least, except for occasional cases of really large suggestions that you don't want to waste tons of email bandwidth on) | 12:31 |
| === tca [n=tom@ti541110a080-5238.bb.online.no] has left #bzr [] | ||
| lifeless | night all | 01:02 |
| === niemeyer [n=niemeyer@200-103-134-216.ctame705.dsl.brasiltelecom.net.br] has joined #bzr | ||
| === matkor [n=matkor@beauty.ant.gliwice.pl] has joined #bzr | ||
| matkor | Can I do branch checkout having only r-o access to repo via ssh/sftp ? I get error bzr: ERROR: Permission denied: u'/srv/bzr/abbon/admin/.bzr/branch-format': [Errno 13] Permission denied ? | 01:39 |
| matkor | http manages somehow to work without such locks ? | 01:40 |
| === mrevell is now known as mrevell-lunch | ||
| === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr | ||
| matkor | seems http: must be special ;) bzr: ERROR: Transport error: Server refuses to fullfil the request for: http://appserver.ant.vpn/bzr/abbon/admin/.bzr/branch-format | 01:51 |
| luks | maybe you really don't have access to the file? | 01:51 |
| luks | and neither does apache? | 01:51 |
| === bac [n=bac@canonical/launchpad/bac] has joined #bzr | ||
| === ddaa [n=david@canonical/launchpad/ddaa] has joined #bzr | ||
| === ddaa [n=david@canonical/launchpad/ddaa] has joined #bzr | ||
| matkor | luks: Should I have r/w access inside bzr repo using sftp: transport or read only is enough ? | 01:55 |
| luks | read only should be enough | 01:56 |
| mwhudson | hm | 01:57 |
| mwhudson | the smart server isn't too happy with branch names that contain newlines methinks :) | 01:57 |
| === jdong_ [n=jdong@ubuntu/member/jdong] has joined #bzr | ||
| === jdong_ is now known as jdong | ||
| AfC | newlines in branch names. Nice. | 02:13 |
| matkor | OK. one not only neads r but also rX to get access ... | 02:15 |
| === deadwill [n=deadwill@146037.fln.virtua.com.br] has joined #bzr | ||
| === phanatic [n=phanatic@3e70d9e7.adsl.enternet.hu] has joined #bzr | ||
| === mrevell-lunch is now known as mrevell | ||
| === jdong [n=jdong@ubuntu/member/jdong] has joined #bzr | ||
| === mw|out [n=mw@189.146.15.187] has joined #bzr | ||
| === bigdog [n=scmikes@79-67-14-216-arpa.cust.cinci.current.net] has joined #bzr | ||
| spiv | mwhudson: in theory it should be ok, it should just url-escape the offending byte... | 03:01 |
| spiv | mwhudson: I wouldn't be shocked if that's not true though. | 03:02 |
| === mkanat [n=mkanat@c-71-202-202-106.hsd1.ca.comcast.net] has joined #bzr | ||
| mkanat | Is "log -v" any faster in 0.90 than in 0.18? | 03:10 |
| mkanat | Because man, it's slow. :-) | 03:10 |
| mkanat | Something like 60-90x slower than just plain "log". | 03:10 |
| mkanat | (In 0.18, that is.) | 03:11 |
| === bwinton [n=bwinton@mail.phantomfiber.com] has joined #bzr | ||
| mwhudson | spiv: hm | 03:24 |
| mwhudson | spiv: theery and praxis seem to differ here | 03:24 |
| === jdong [n=jdong@ubuntu/member/jdong] has joined #bzr | ||
| mwhudson | spiv: is there a way i can make the smart server more verbose on the server side? | 03:28 |
| mwhudson | mwh@mithril-inside:aa$ bzr push 'bzr+ssh://bazaar.launchpad.dev/~sabdfl/+junk/aaa | 03:31 |
| mwhudson | > bbb' | 03:31 |
| mwhudson | bzr: ERROR: Generic bzr smart protocol error: Generic bzr smart protocol error: bad request 'bbb/' | 03:31 |
| mwhudson | hmmmm | 03:31 |
| mwhudson | something screwy here | 03:33 |
| === Mez [n=Mez@ubuntu/member/mez] has joined #bzr | ||
| === juliank [n=juliank@p548AE60A.dip.t-dialin.net] has joined #bzr | ||
| === mw|out is now known as mw | ||
| === juliank0 [n=juliank@p548AE60A.dip.t-dialin.net] has joined #bzr | ||
| === rburton [n=ross@althur.gotadsl.co.uk] has joined #bzr | ||
| rburton | afternoon all | 03:58 |
| rburton | is there a way to update a bzr checkout (not a branch) to a particular revision? | 03:58 |
| rburton | bzr update -r [revno] doesn't appear to exist, which is a shame | 04:02 |
| matkor | rburton: I would use branch if need particular revision | 04:05 |
| ubotu | New bug: #137283 in bzr "oddness in smart server with paths containing newlines" [Undecided,New] https://launchpad.net/bugs/137283 | 04:06 |
| rburton | matkor: so how do i switch to a particular revision with a branch then? | 04:06 |
| spiv | rburton: bzr revert -r | 04:06 |
| rburton | spiv: does that go forwards too? | 04:06 |
| rburton | https://bugs.launchpad.net/bzr/+bug/45719 contains a patch for update, marked "fix committed" but the comments imply its waiting review | 04:07 |
| spiv | rburton: I'm not sure, but I expect that in a checkout it would. | 04:07 |
| ubotu | Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,Fix committed] | 04:07 |
| spiv | We use "fix committed" to mean "the fix is committed in a branch somewhere" (vs. "fix released" == "the fix is committed to bzr.dev.") | 04:08 |
| rburton | ah | 04:08 |
| spiv | (http://bazaar-vcs.org/BugGuidelines) | 04:09 |
| rburton | bzr: ERROR: Requested revision: u'10' does not exist in branch: BzrBranch5('file:///home/ross/Local/mess/36/flickrpc/') | 04:09 |
| rburton | you can't revert to a newer revision with a checkout | 04:09 |
| rburton | same error with a branch | 04:10 |
| === ionstorm [n=ion@70-58-119-250.phnx.qwest.net] has joined #bzr | ||
| mwhudson | yes, i would somehow expect revert to not go outside the branch looking for revisions | 04:10 |
| rburton | yeah me too | 04:10 |
| rburton | ah well, we'll delete the tree and rebuild it then | 04:11 |
| mwhudson | rburton: you could comment on that bug, it may kick it into life... | 04:11 |
| rburton | doing now | 04:12 |
| === p4tux [n=p4tux@189.169.92.184] has joined #bzr | ||
| mwhudson | cool | 04:12 |
| === keir [n=keir@206-248-160-33.dsl.teksavvy.com] has joined #bzr | ||
| === juliank [n=juliank@p548AE60A.dip.t-dialin.net] has joined #bzr | ||
| === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr | ||
| === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr | ||
| === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr | ||
| === Mez [n=Mez@ubuntu/member/mez] has joined #bzr | ||
| === Lo-lan-do [n=roland@mirenboite.placard.fr.eu.org] has joined #bzr | ||
| Lo-lan-do | Guess who? | 05:00 |
| fullermd | Elizabeth Taylor? | 05:01 |
| Lo-lan-do | Also, guess what :-) | 05:01 |
| Lo-lan-do | It's me, coming back to haunt jelmer with a problem I have with bzr-svn! | 05:01 |
| Lo-lan-do | http://paste.debian.net/36211 | 05:01 |
| === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr | ||
| jelmer | hey Lo-lan-do | 05:05 |
| Lo-lan-do | Hey mate, sorry for the repeated nagging :-) | 05:05 |
| jelmer | Lo-lan-do: sorry for the bugs ! | 05:06 |
| jelmer | Lo-lan-do: can you paste the 'bzr missing -v ' output ? | 05:06 |
| Lo-lan-do | http://paste.debian.net/36213 | 05:08 |
| fullermd | Hm, whaddaya know... .so's build on Python 2.4 don't get along with 2.5 Whoda thunkit? | 05:12 |
| mwhudson | fullermd: they probably sorta mostly work, actually | 05:14 |
| mwhudson | unless there were more pervasive changes than i remember in the version bump | 05:14 |
| fullermd | Well, I dunno if they worked, or just refused to load and bzr fell back to the .py version. | 05:14 |
| fullermd | I just blew 'em away (and got annoyed again at how 'make clean' doesn't actually clean 'em up) and remade 'em. | 05:15 |
| jelmer | Lo-lan-do: can you perhaps also paste the output of 'bzr log -v -r -6..-1' ? I'm mainly | 05:15 |
| mwhudson | oh, or in a 64 bit environment | 05:15 |
| jelmer | interested in the parents of those revisions, was hoping 'bzr missing -v' would print those | 05:15 |
| mwhudson | fullermd: but yeah, definitely not recommended or supported | 05:15 |
| Lo-lan-do | jelmer: http://paste.debian.net/36214 | 05:16 |
| jelmer | mwhudson: hi! Can you still reproduce bug 125751 ? | 05:17 |
| ubotu | Launchpad bug 125751 in bzr-svn "yet another failing push" [Undecided,New] https://launchpad.net/bugs/125751 | 05:17 |
| jelmer | Lo-lan-do: thanks | 05:17 |
| mwhudson | jelmer: good question | 05:18 |
| jelmer | Lo-lan-do: bug 131692 :-( | 05:22 |
| ubotu | Launchpad bug 131692 in bzr-svn "pushing on top of non-lhs parent fails" [High,Triaged] https://launchpad.net/bugs/131692 | 05:22 |
| Lo-lan-do | "Non-lhs" referring to the order in which the branches have diverged, or something similar? | 05:23 |
| jelmer | to the relation of the revisions | 05:24 |
| jelmer | 4864.1.1 in that log output is a subversion revision I guess? | 05:24 |
| Lo-lan-do | Yes | 05:26 |
| jelmer | non-lhs is a non-left hand side revision | 05:30 |
| === Mez [n=Mez@ubuntu/member/mez] has joined #bzr | ||
| === Mez [n=Mez@ubuntu/member/mez] has joined #bzr | ||
| Lo-lan-do | Is that hard to fix? | 05:40 |
| Lo-lan-do | I can wait for a few weeks before pushing, but if it takes a few months instead, I'll find workarounds. | 05:41 |
| === grimboy [n=grimboy@85-211-246-129.dsl.pipex.com] has joined #bzr | ||
| jelmer | Lo-lan-do: Hopefully less than a week | 05:45 |
| jelmer | I badly need to do a 0.4.3 because there are a couple of other issues that need to be fixed urgently | 05:46 |
| jelmer | s/0.4.3/0.4.2/ | 05:46 |
| Lo-lan-do | Oh, that's ample soon enough. As long as I can pull/merge from SVN, I can postpone my pushing for a while. | 05:46 |
| Lo-lan-do | Thanks for the hard work :-) | 05:46 |
| mwhudson | jelmer: http://rafb.net/p/nloZz560.html | 05:46 |
| mwhudson | which is different, and possibly related to my branching scheme hacks | 05:47 |
| jelmer | mwhudson: that one is fixable by making _is_http_transport() return False in transport.py | 05:47 |
| mwhudson | jelmer: then i get the same traceback as is already in the bug report | 05:48 |
| === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr | ||
| asabil | hi all | 05:56 |
| asabil | is there a way to specify a default push path directly after a bzr get ? | 05:56 |
| Lo-lan-do | push --remember? | 05:57 |
| jelmer | mwhudson: ok - thanks | 05:58 |
| mthaddon | is there a way to undo a bzr pull --overwrite? can I do bzr uncommit? | 05:59 |
| asabil | Lo-lan-do: without doing a push | 05:59 |
| jelmer | asabil: you can edit .bzr/branch/branch.conf | 06:00 |
| jelmer | not sure if there's a way to do so via the command line | 06:00 |
| asabil | hmmm ok | 06:02 |
| mwhudson | jelmer: i can execute other commands if you want | 06:05 |
| mwhudson | jelmer: just not right now :) | 06:05 |
| === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr | ||
| === fog [n=fog@debian/developer/fog] has joined #bzr | ||
| === sumdeus [n=sumdeus@c-69-242-210-34.hsd1.mi.comcast.net] has joined #bzr | ||
| sumdeus | I can't seem to find an answer to this and hope someone can point me in the right direction: I have two separate trees which have no common ancestry. I would like to apply a patch from tree A to tree B. What is the best way to accomplish this? | 06:29 |
| beuno | sumdeus, probably using "bzr bundle" | 06:30 |
| beuno | checkout "bzr help bundle" | 06:30 |
| beuno | *check out | 06:30 |
| beuno | that would create a patch you can apply as revisions | 06:30 |
| sumdeus | beuno, cheers, I shall have a look | 06:30 |
| james_w | that wont work I'm afraid, as a bundle requires the base revision to be present. | 06:51 |
| james_w | you can do diff + patch at best I think. | 06:52 |
| james_w | ah no, you can use merge I belive if you specify a start revision. | 06:53 |
| james_w | which you can do when merging from a bundle. | 06:53 |
| beuno | oh, sumdeus, listen to james_w :D | 06:53 |
| james_w | however there will be conflicts if the two branches have files of the same names (filename conflicts, so bzr wont even try to merge contents). | 06:53 |
| james_w | if that is the case then diff + patch might be the best way to go. | 06:54 |
| james_w | mthaddon: if you know the revision id of where you were before you can pull --overwrite back to where you were. | 06:55 |
| sumdeus | Hmm... what looks like it will work, since I'm using old school baz (1.x) is to do "baz delta --diffs > patch.patch" and then patch -p1 in the new tree. | 06:55 |
| mthaddon | james_w, went with restore from backup - thx in any case | 06:55 |
| sumdeus | of course after diffs put in the two trees | 06:55 |
| sumdeus | Which is what james_w suggested, so perfect! | 06:55 |
| james_w | mthaddon: no problem. | 06:56 |
| === ipkiss_ is now known as ipkiss | ||
| === keir is fishing for people to test his mutt+gmail+bzr send tutorial | ||
| keir | see if you can get the following to work: http://bazaar-vcs.org/BzrSendWithGmail | 07:17 |
| keir | anyone? | 07:30 |
| keir | abentley, i still think alphabetizing is the right thing to do | 07:34 |
| james_w | could you alphebetise in two sections, clients first, and then others second? | 07:35 |
| keir | yeah, that's what i'm doing now | 07:35 |
| keir | it's really unclear what the ordering means unless is specifically mention that it's clients then generic options | 07:35 |
| keir | ok, i'm doing that | 07:38 |
| === hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr | ||
| === sverrej [n=sverrej@tul-1x-dhcp013.studby.uio.no] has joined #bzr | ||
| === p4tux [n=p4tux@189.169.92.184] has joined #bzr | ||
| === duckx [n=Duck@tox.dyndns.org] has joined #bzr | ||
| === sverrej_ [n=sverrej@tul-1x-dhcp014.studby.uio.no] has joined #bzr | ||
| === corehosting [n=ctrlprox@a81-14-225-28.net-htp.de] has joined #bzr | ||
| corehosting | hello, stupid question: what is the name of the package (suse 10.1), if i want to use "bze get"? | 08:18 |
| bwinton | bzr? | 08:18 |
| === asak [n=alexis@201-1-44-231.dsl.telesp.net.br] has joined #bzr | ||
| === BasicOSX [n=Basic@fortress.tanners.org] has joined #bzr | ||
| corehosting | 0 result(s) | 08:19 |
| === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr | ||
| BasicOSX | Anyone running osx+python2.5 and bzr? Any problems? | 08:19 |
| bwinton | What's in your Development/Tools/Version Control directory? (Assuming you have one.) | 08:20 |
| james_w | corehosting: http://benjiweber.co.uk:8080/webpin/index.jsp?searchTerm=bzr | 08:21 |
| corehosting | ohhhh, coool | 08:22 |
| corehosting | this looks good | 08:22 |
| bwinton | Basic, I'm on OSX/Python 2.4/bzr 0.90.0 candidate 0, and haven't run into any problems yet. | 08:23 |
| BasicOSX | wondering if the problem is python-2.5 | 08:23 |
| bwinton | Well, that's not entirely true. The GTK extra stuff didn't work, because I haven't installed X-Windows, but I expected that to not work. | 08:23 |
| BasicOSX | that is the tread related to my problem with bzr on osx http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/30469/focus=30555 | 08:24 |
| BasicOSX | bwinton: could I ask you to bzr get http://bazaar.eqenchanters.org/WoW/AddOns | 08:25 |
| bwinton | Sure. | 08:25 |
| BasicOSX | Also, is there a way to "check" the sanity of your remote repo? | 08:26 |
| bwinton | Getting... | 08:26 |
| james_w | bzr check http://... should work I guess. | 08:26 |
| bwinton | Basic: Fetch phase 1/4... | 08:27 |
| fullermd | It won't. | 08:27 |
| BasicOSX | I have local access to the "remote" repo as well | 08:27 |
| BasicOSX | on the local machine doing a bzr check /path/to/repo, seems to be working | 08:28 |
| === sverrej__ [n=sverrej@tul-1x-dhcp014.studby.uio.no] has joined #bzr | ||
| === pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr | ||
| === Gwaihir [n=Gwaihir@ubuntu/member/gwaihir] has joined #bzr | ||
| === sverrej [n=sverrej@tul-1x-dhcp013.studby.uio.no] has joined #bzr | ||
| === orutherfurd [n=orutherf@dsl092-164-022.wdc2.dsl.speakeasy.net] has joined #bzr | ||
| === pygi [n=mario@78-0-6-100.adsl.net.t-com.hr] has joined #bzr | ||
| corehosting | no I tried "python setup.py install" (bzr-0.90.tar.gz) | 09:00 |
| corehosting | >> ImportError: No module named distutils.core | 09:00 |
| corehosting | whats my fault? | 09:00 |
| bwinton | Basic: You still there? It finally finished with a "bzr: ERROR: [Errno 66] Directory not empty" | 09:00 |
| james_w | corehosting: you don't have distutils installed at a guess. | 09:01 |
| dato | but distutils come with python itself | 09:02 |
| keir | i don't understand the difference between merge-directive and send; do they both generate exactly the same output? | 09:02 |
| corehosting | phyton 2.4.2 is installed | 09:02 |
| === grimboy [n=grimboy@84.13.125.171] has joined #bzr | ||
| james_w | keir: a merge-directive is what bzr send sends. | 09:06 |
| === orospakr [n=orospakr@132.213.238.4] has joined #bzr | ||
| james_w | the merge-directive command just creates a merge-directive. I think send -o is equal to merge-directive | 09:07 |
| jelmer | corehosting: looks like it isn't included in the default python package on suse, maybe it's in python-dev or python-devel | 09:07 |
| jelmer | corehosting: or perhaps you need to run 'python2.4 setup.py install' | 09:08 |
| jelmer | (there may be an older version of python installed as well) | 09:08 |
| corehosting | hello jelmer *g* | 09:09 |
| keir | james_w, ok. it's a bit weird because merge-directive has a --mail-to, which appears exactly the same as send | 09:11 |
| james_w | keir: I don't know if Aaron made it the same as send now, but it used to work differently. | 09:12 |
| dato | keir: merge-directive predates send. bundle and merge-directive have been combined into send. | 09:12 |
| dato | keir: and anyway, I don't know if you noticed, but merge-directive is a *hidden* command | 09:13 |
| keir | aaah, ok | 09:13 |
| keir | great | 09:13 |
| keir | i was about to suggest merge-directive should be deprecated | 09:13 |
| corehosting | jelmer: python-dev installed, now install bzr runs | 09:15 |
| corehosting | thanks @all | 09:15 |
| BasicOSX | bwinton: interesting, same problem with python 2.5 | 09:17 |
| dato | how... strange/inconvinient/lame | 09:17 |
| === synic [n=squish@pdpc/supporter/student/synic] has left #bzr [] | ||
| dato | (not having distutils installed with python) | 09:17 |
| ubotu | New bug: #137335 in bzr "End configuration files with newline" [Undecided,New] https://launchpad.net/bugs/137335 | 09:28 |
| bwinton | Basic: Well, at least you know it's not a 2.4/2.5 thing... | 09:28 |
| asabil | hmm, anyone managed to use the bzr visual studio plugin ? | 09:30 |
| BasicOSX | bwinton: yep, testing with windoze now as well | 09:31 |
| === mw [n=mw@189.146.15.187] has joined #bzr | ||
| corehosting | bye @all | 09:34 |
| === corehosting [n=ctrlprox@a81-14-225-28.net-htp.de] has left #bzr [] | ||
| === grimboy [n=grimboy@84.13.125.171] has joined #bzr | ||
| === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr | ||
| ubotu | New bug: #137348 in bzr "transport.ensure_base() fails for c: on windows" [Undecided,New] https://launchpad.net/bugs/137348 | 09:40 |
| === herzel [i=herzel@gateway/tor/x-7e029f58e1b88426] has joined #bzr | ||
| === pygi [n=mario@78-0-6-100.adsl.net.t-com.hr] has joined #bzr | ||
| === shirish [n=shirish@59.95.55.184] has joined #bzr | ||
| lifeless | moin | 10:48 |
| james_w | morning lifeless | 10:48 |
| keir | lifeless, morning | 10:49 |
| keir | lifeless, i've been reading index.py | 10:49 |
| keir | lifeless, so a 'key' is a tuple of bytestrings | 10:49 |
| keir | and for a given index, the length of that tuple is fixed, but the bytestrings may have differing length, correct? | 10:50 |
| lifeless | keir: right | 10:54 |
| james_w | is there a way to find out the executability of a tree entry without using _iter_changes to locate it? | 10:54 |
| lifeless | keir: if you browse to http://people.ubuntu.com/~robertc/baz2.0/.bzr/repository/indices/ | 10:54 |
| lifeless | keir: you can see a number of live indices | 10:54 |
| lifeless | james_w: yes, there's an API on tree to query for that | 10:54 |
| james_w | lifeless: I can't find it, any hints on the name? | 10:55 |
| lifeless | **executab | 10:55 |
| lifeless | *executab* | 10:55 |
| james_w | _comparison_data | 10:57 |
| lifeless | thats somewhat internal | 10:57 |
| lifeless | but it will answer you | 10:57 |
| lifeless | is_executable() | 10:57 |
| keir | lifeless, these are only used for fast lookup, correct? | 10:57 |
| keir | is hashing the keys insane? | 10:58 |
| james_w | lifeless: I cannot find that for the life of me. | 10:58 |
| james_w | ah, it's on working tree. | 10:58 |
| lifeless | james_w: pydoc bzrlib.workingtree.WorkingTree | 10:59 |
| james_w | that seems wrong to me. Is it a Windows thing? | 10:59 |
| lifeless | thats the interface of working tree | 10:59 |
| lifeless | james_w: windows support makes it more complex | 10:59 |
| lifeless | keir: not necessarily, but you would want to detect collisions | 10:59 |
| lifeless | keir: also | 11:00 |
| lifeless | keir: you want to be able to iterate the keys | 11:00 |
| lifeless | keir: iter_all_entries() | 11:00 |
| keir | lifeless, yes, i see that | 11:00 |
| lifeless | keir: so you can definately use hashing internally if that makes sense and you do it defensively and support the current public interface | 11:01 |
| shirish | guys I'm a simple checkout guy, I have used svn before this, just like in svn is there a way to find info. about a copy one downloads | 11:01 |
| keir | just brainstorming, i realize this may not work: first bit is a linear list of keys | 11:01 |
| james_w | lifeless: it's on revisiontree as well, which I think should work for me. Thanks for the pointer. | 11:01 |
| shirish | like one does svn info. something & it gives everything in nice order. | 11:01 |
| keir | nothing else | 11:01 |
| lifeless | shirish: 'bzr info' | 11:01 |
| keir | lifeless, then second part is similar to current format, but with fixed-length md5's to refer | 11:01 |
| james_w | shirish: there is bzr info, I'm not sure how the information compares though. | 11:02 |
| shirish | lifeless: I did try bzr info, but it doesn't give me full info. | 11:02 |
| keir | lifeless, depending on connectedness of the graphs, this could be faster/slower bigger/smaller | 11:02 |
| lifeless | shirish: I think you need to be more precise about what you want to know about | 11:02 |
| james_w | shirish: try info -v if you have a recent bzr. | 11:02 |
| keir | shirsh, what information from svn are you looking for? | 11:03 |
| lifeless | keir: wouldn't it cause considerable double-dereference latency, and nearly double the index size ? | 11:03 |
| shirish | james_w: that bzr info -v is cooler than svn info | 11:03 |
| === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr | ||
| shirish | keir: I was looking for revision nos. & stuff like that. | 11:04 |
| keir | lifeless, i bet it would shrink it for most of the indexes i've looked at | 11:04 |
| keir | lifeless, with a 128 bit hash, you're looking at 16 bytes per reference | 11:04 |
| keir | lifeless, right now those keys are much longer than 16 chars | 11:04 |
| shirish | guys, another issue, like svn up is there, there is also bzr up, what is the difference between the two, simple language please. | 11:05 |
| keir | lifeless, and depending on the index size you may be able to get away with 64 bit hash if it's only one file | 11:05 |
| keir | er smaller | 11:05 |
| lifeless | keir: current references are about 7 bytes | 11:05 |
| keir | lifeless, you are right about double deref | 11:05 |
| lifeless | for a 4.5MB index | 11:05 |
| keir | ah, right | 11:06 |
| james_w | shirish: there is also bzr revno for that information quickly. | 11:06 |
| shirish | james_w: thanx for the heads up | 11:06 |
| james_w | shirish: as for bzr up I believe that it works in the same way on checkouts. | 11:06 |
| === bwinton [n=bwinton@mail.phantomfiber.com] has left #bzr [] | ||
| lifeless | for a 200MB index - the largest I've seen, its 9 bytes | 11:06 |
| james_w | shirish: but I can't remeber svn very well. | 11:06 |
| lifeless | keir: I can see you are starting to think through things - this is great | 11:07 |
| shirish | james_w: as far as bzr updates to whatever the latest on repository, its good | 11:08 |
| shirish | btw can you guys have a look at http://paste.ubuntu-nl.org/36374/ | 11:08 |
| shirish | look at line 12, it says Branch is out of date: missing 1 revision. | 11:08 |
| lifeless | shirish: if you used 'bzr checkout' to get the code, 'bzr update' will do what you want | 11:08 |
| keir | lifeless, ok. so if we can't seek (only readv on transports) how is there any way we can do better than now? | 11:08 |
| james_w | shirish: I think that means a bzr up is in order. I don't know though. | 11:09 |
| lifeless | shirish: if you use 'bzr branch', then 'bzr pull' or 'bzr merge' is what you will want to respectively mirror and merge other peoples code | 11:09 |
| lifeless | shirish: yes, you need to bzr up | 11:09 |
| keir | lifeless, what was the usecase you mentioned before where it required reading 200mb of index but should only need 64k? | 11:10 |
| lifeless | keir: sure, consider a 16-way B-tree for example | 11:10 |
| shirish | lifeless: this is main, so no need of bzr pull, its needed only when one is taking stuff from branches. | 11:10 |
| lifeless | with the node packing on disk having the root node at the front of the file | 11:10 |
| keir | lifeless, i guess it depends on what you need to access | 11:11 |
| shirish | guys, when I did bzr info -v how did it come to know I was missing one revision, does it do a compare between me & the remote repository to know the details? | 11:12 |
| lifeless | shirish: if you are grabbing someting from a branch for your trunk you should never use pull only merge | 11:12 |
| lifeless | shirish: yes | 11:12 |
| lifeless | keir: well this is why it needs time and thought to do a great index layer | 11:13 |
| shirish | lifeless: I'm not contributing anything to that project other than checking out the build, seeing what's new, seeing if it breaks while building & reporting if any issues happen. | 11:13 |
| keir | lifeless, ok :) interesting stuff. | 11:14 |
| lifeless | shirish: then just bzr up is fine for you | 11:14 |
| keir | lifeless, 64k vs 200mb use case? | 11:14 |
| lifeless | keir: righto - cosnider the mozilla full-history text index | 11:14 |
| lifeless | keir: its a 200MB .tix | 11:14 |
| shirish | lifeless: thanx, btw there is bzr 0.90 out but why isn't it on gutsy? | 11:14 |
| lifeless | shirish: hasn't propogated yet | 11:15 |
| lifeless | keir: .tix's are length-2 keys, with 2 key reference lists per node | 11:15 |
| lifeless | keir: the way they are used is (fileid, revisionid) for the keys | 11:15 |
| shirish | lifeless: 0.90 seems to be out more than few days right? | 11:15 |
| lifeless | shirish: I presume thats rhetorical | 11:16 |
| === shirish goes to find out the meaning of rhetorical | ||
| lifeless | its a question to which you know the answer already and are asking in order to make a point to the person you ask it | 11:16 |
| lifeless | its rather annoying | 11:16 |
| shirish | lifeless: I didn't know, honest | 11:17 |
| james_w | shirish: 0.90 was released a week ago. | 11:18 |
| keir | lifeless, ok, so they are (fileid, revid) -> (fileid1, revid1), (fileid2, revid2) | 11:18 |
| lifeless | keir: more | 11:18 |
| shirish | james_w: oh wow, so what's stopping it, any critical bugs or something? | 11:18 |
| lifeless | key -> VALUE, [key_list1, key_list2] | 11:19 |
| shirish | james_w: I meant some major regressions or something new, which makes it unsuitable to release? | 11:19 |
| lifeless | keir: key_list1 contains the per-file graph parents for key. Thats the graph that log FILENAME follows | 11:19 |
| lifeless | keir: key_list2 is always either empty or has a single entry | 11:20 |
| lifeless | keir: so [] - the text has not been delta compressed | 11:20 |
| lifeless | keir: or [(fileid, revisionid)] of the full text that the text has been delta compressed against | 11:20 |
| james_w | shirish: I believe it is that gutsy has frozen, so the process takes a little longer. | 11:20 |
| keir | lifeless, ok | 11:21 |
| keir | lifeless, i'm going to think about this for a minute | 11:21 |
| lifeless | ok, I'm ready to give you the use case now :) | 11:21 |
| shirish | james_w: right, but can't something like bzr have a freeze exception, this is kinda stuff that all developers would be looking forward to. a better tool. | 11:21 |
| james_w | shirish: I believe it might have a freeze exception, check launchpad. It doesn't mean that it goes in straight-away though. | 11:23 |
| lifeless | keir: oh, and VALUE contains the byte offset and length in the .pack file of the record (whether it is full text or delta) | 11:23 |
| lifeless | shirish: #ubuntu-motu please at this point. This is the upstream development channel. | 11:23 |
| keir | lifeless, ok | 11:24 |
| shirish | lifeless, cool :) | 11:24 |
| lifeless | keir: now the use case is 'bzr cat http://mozilla.org/bzr/trunk/ChangeLog'. This will need to do a number of index operations, starting with looking up the text for the inventory, which I'm going to gloss over | 11:25 |
| lifeless | keir: and once it has that it reads the inventory data to get the fileid and revision id of the text it wants to construct - the fileid of 'ChangeLog' and the revisionid of the lsat change made to it. | 11:25 |
| lifeless | keir: so then we query the .tix and follow the compression-tree upwards: | 11:26 |
| lifeless | nodes = [] | 11:26 |
| keir | aah, ok | 11:27 |
| lifeless | node = list(index.iter_entries([(changelog-id, last-modified-revid)] ))[0] | 11:27 |
| lifeless | nodes.append(node) | 11:27 |
| lifeless | while len(node[3] [1] ): | 11:27 |
| lifeless | node = list(index.iter_entries([node[3] [1] ] ))[0] | 11:28 |
| lifeless | nodes.append(node) | 11:28 |
| lifeless | # now nodes is a sorted list of compressed texts finishing with a fulltext | 11:28 |
| lifeless | and then we use the values in the nodes to calculate a readv (perhaps across multiple .packs - so perhaps multiple readvs), to get the fulltext and each delta and apply them to get the content of ChangeLog | 11:29 |
| keir | lifeless, i see. so it actually finds a series of diffs, then applys them | 11:29 |
| lifeless | right | 11:29 |
| lifeless | and thats using the second node-reference-list from the index | 11:29 |
| lifeless | which is where we cache that information for cheap access | 11:29 |
| keir | and what is in the packs? | 11:30 |
| lifeless | the deltas and full texts | 11:30 |
| lifeless | so | 11:31 |
| keir | yes, i see | 11:31 |
| lifeless | the mozilla .tix index, when its fully packed into a single pack, is 200MB | 11:31 |
| lifeless | but the data we need to decide what to readv from that pack is probably < 10K | 11:31 |
| lifeless | (say 200 bytes * 50 delta hunks in a run) | 11:32 |
| lifeless | and on average < 5K | 11:32 |
| keir | but if you know what parts to readv, don't you still have to linear scan from the start? | 11:32 |
| keir | from what i see with readv, you'd still have to read 100mb if one of the hunks was 100mb down the pack file (not the tix) | 11:33 |
| lifeless | keir: linear scan from the start of what ? | 11:33 |
| keir | i am a bit confused about terminology | 11:33 |
| lifeless | keir: readv only transfers the byte ranges asked for over the wire | 11:34 |
| keir | "the mozilla .tix index, when its fully packed into a single pack, is 200MB" <- are .tix files pack files? i thought packs were separate | 11:34 |
| lifeless | you supply a vector of (offset, length) pairs and you get back an iterator of (offset, bytes) | 11:34 |
| lifeless | keir: have a look at http://people.ubuntu.com/~robertc/baz2.0/repository | 11:34 |
| keir | lifeless, aah, right. i didn't read the readv manpage enough :) | 11:35 |
| lifeless | keir: the pack-names file there lists the packs | 11:36 |
| lifeless | keir: for each pack there are 4 indices: .six, .tix, .iix, .rix | 11:36 |
| lifeless | thats for signatures, texts, inventories and revisions | 11:36 |
| === yml [n=yml@put92-2-82-224-221-145.fbx.proxad.net] has joined #bzr | ||
| lifeless | each commit adds a single pack. | 11:36 |
| yml | Hello, | 11:36 |
| keir | lifeless, and 4 new indicies, ok. | 11:36 |
| lifeless | every l0 commits 10 single-commit packs are combined to 1 10-commit pack | 11:37 |
| lifeless | every 100 commits 10 10-commit packs are combined to 1 100-commit pack | 11:37 |
| lifeless | and so on | 11:37 |
| keir | ok | 11:37 |
| lifeless | and 4 new indices are written every time a new pack is added, and the indices are removed when the pack is | 11:37 |
| yml | bzr is dumping some very strange lines each time I run a command on the computer hosted by my provider. | 11:37 |
| lifeless | so for a given repository the 'text index' is the combination of all the .tix indices for all the packs listed in pack-names | 11:38 |
| lifeless | I think the CombinedGraphIndex is probably about right at the moment (but am completely open to being wrong on that). | 11:38 |
| lifeless | yml: pastebin or something please | 11:38 |
| yml | Here it is an example: http://dpaste.com/18596/ | 11:38 |
| yml | goodevning lifeless | 11:39 |
| keir | lifeless, thanks for the explanation. i am going to digest this a bit more | 11:39 |
| lifeless | yml: look in ~/.bzr.log | 11:39 |
| lifeless | yml: you are getting an IO error of some sort | 11:39 |
| yml | should I pastebin also? | 11:40 |
| lifeless | the NotImplementedError is strange | 11:40 |
| lifeless | keir: no probs | 11:41 |
| yml | here it is: http://dpaste.com/18597/ | 11:41 |
| lifeless | keir: but can you see now - there is a 200MB .tix, but we only want a tiny fraction of the total data | 11:41 |
| keir | lifeless, yes | 11:41 |
| keir | lifeless, we only want to extract the relevant ranges in the packs | 11:42 |
| lifeless | yml: file a bug please with that 18597 paste | 11:42 |
| lifeless | keir: yes, the goal of the index is to tell us what bytes in the packs are interesting for various use cases | 11:42 |
| yml | I will do this . what should be the title? | 11:43 |
| lifeless | yml: make one up | 11:44 |
| yml | ok thank you lifeless | 11:44 |
| === shirish [n=shirish@59.95.55.184] has left #bzr [] | ||
| lifeless | ok, deep hack time | 11:45 |
| === yml [n=yml@put92-2-82-224-221-145.fbx.proxad.net] has left #bzr ["Kopete] | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!