| igc | morning | 00:00 |
|---|---|---|
| hersonls | poolie: hi | 00:03 |
| hersonls | poolie: where i found documentation of the loggerhead? | 00:04 |
| === yacc_ is now known as yacc | ||
| yacc | I just wonder, is it possible to push a branch to two different branches concurrently? | 00:05 |
| yacc | bzr push a in one terminal and bzr push b in another? | 00:06 |
| poolie | yacc: yes, it should work, the readlock is not exclusive | 00:06 |
| poolie | hersonls: in the branch for it i think | 00:06 |
| poolie | well, "it should work" sounds uncertain, i know it will work | 00:07 |
| yacc | Ok, if I've got bzr installed on the target, and ssh access, should I be able to do something that works faster than sftp:// ? | 00:08 |
| spiv | yacc: "bzr+ssh://" rather than "sftp://" | 00:12 |
| spiv | yacc: it's not much faster than sftp yet, but I'm working on that right at the moment :) | 00:12 |
| spiv | (Some other operations are already faster with bzr+ssh:// though) | 00:12 |
| yacc | spiv: well, I'm nailed to 1.3.1 on Hardy anyway (the PPA was missing bzr-svn last time I checked) | 00:13 |
| yacc | Hmmm, the stupid thing complains about not finding bzr, despite that it's installed via a .deb on the server *scratch-head* | 00:14 |
| spiv | yacc: Does "ssh host bzr --version" work? | 00:14 |
| yacc | Nope, isn't that beefy. | 00:15 |
| poolie | lifeless: hi, pqm seems to be having a lot of trouble | 00:15 |
| yacc | spiv: ok, found the problem. | 00:16 |
| yacc | It's not from a deb, it's in ~/bin :( | 00:16 |
| spiv | yacc: you can still use it | 00:16 |
| Rhamphoryncus | Anybody know of a grand trick to work around https://bugs.launchpad.net/bzr/+bug/150438? Right now I'm afraid to touch it. I'm thinking I should back up the whole repository, then probably end up recreating it all from my working tree :/ | 00:16 |
| yacc | Can I? | 00:16 |
| ubottu | Launchpad bug 150438 in bzr "AssertionError: Could not find target parent in wt in wt4 _process_entry" [High,Confirmed] | 00:17 |
| spiv | yacc: you just need to set bzr_remote_path in your locations.conf (or BZR_REMOTE_PATH as an environment variable) | 00:17 |
| beuno | ls | 00:17 |
| yacc | spiv: locations => ~/.bazaar? | 00:17 |
| beuno | er, wrong window :) | 00:17 |
| yacc | spiv: And as I have no such file, what's the format? | 00:18 |
| spiv | yacc: Right, ~/.bazaar/locations.conf | 00:18 |
| spiv | yacc: | 00:18 |
| spiv | [bzr+ssh://foo/] | 00:18 |
| spiv | bzr_remote_path=/home/blah/bin/bzr | 00:18 |
| yacc | Ok, ConfigParser with the URL as sections. | 00:18 |
| spiv | (Or maybe the URL needs to be the local path? I forget.) | 00:19 |
| yacc | Nope, it worked fine with the prefix of the remote url ;) | 00:20 |
| spiv | Ah, good. | 00:20 |
| yacc | And even an empty push is much faster than sftp: | 00:21 |
| yacc | 8 vs. 14 seconds. | 00:21 |
| yacc | wall time. | 00:21 |
| spiv | yacc: excellent | 00:21 |
| spiv | (though that's still a bit slower than necessary I suspect) | 00:21 |
| yacc | Well, both values are faster than bzr-svn ;) | 00:22 |
| yacc | But then I guess I shouldn't complain, be happy that I can work with upstream without svn or svk ;) | 00:22 |
| jelmer | yacc, empty push with bzr-svn should only be a few seconds - or is that not what you're doing | 00:23 |
| jelmer | ? | 00:23 |
| yacc | jelmer: well, actually the last time I did upstream it was 4 revisions. | 00:24 |
| hersonls | lifeless: you be here? | 00:24 |
| yacc | jelmer: Actually empty push seems to fine with 25s wall. | 00:25 |
| jelmer | yacc, I wouldn't call 25s fine :-) | 00:25 |
| yacc | jelmer: you are European too, so I would expect you better tuned to my cynism :-P | 00:25 |
| jelmer | heh, ok :-) | 00:26 |
| jelmer | yacc, are you running 0.4.10 ? | 00:26 |
| yacc | Nope, 0.4.9 | 00:26 |
| yacc | jelmer: the Hardy packages in this case. | 00:26 |
| jelmer | ok, 0.4.10 should be better in this regard | 00:26 |
| yacc | svn 0.4.9 | 00:26 |
| yacc | Support for Subversion branches | 00:26 |
| yacc | /usr/lib/python2.5/site-packages/bzrlib/plugins/svn | 00:26 |
| yacc | jelmer: as I said I don't really complain. As the sole developer I do batch upstream pushes and nobody complains ;) | 00:27 |
| jelmer | yacc: ah, ok :-) | 00:27 |
| jelmer | yacc: In any case, if you can still reproduce this at the time you upgrade to 0.4.10, please file a bug | 00:28 |
| yacc | jelmer: It's a bi-weekly operation more or less to me, usually when I ponder bzr log output for creative timesheet comments ;) => so the performance is really fine for me. | 00:29 |
| beuno | abentley, I've pinpointed the single quotes problem, all I need is a good regex to catch the exceptions, and I think we're in business :) | 00:55 |
| hersonls | poolie: to resolve a text conflicts, i need run bzr revert first? | 00:57 |
| beuno | hersonls, no, you have to actually resolve them. Take a look at the docs: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#resolving-conflicts | 00:59 |
| hersonls | beuno: tanks | 01:01 |
| beuno | hersonls, welcome' | 01:01 |
| hersonls | i dont understand, i need uncommit to resolve conflict ? | 01:08 |
| beuno | hersonls, no, why would you get that impression? | 01:09 |
| hersonls | beuno: i try, bzr resolve test.py | 01:10 |
| hersonls | beuno: and try merge again, and show me a message, "has uncommitted changes. " | 01:11 |
| beuno | hersonls, you resolved all the conflicts and ran "bzr resolve test.py"? | 01:12 |
| hersonls | beuno: after try bzr resolve, no showme any messages | 01:13 |
| spiv | hersonls: what does "bzr status" report? | 01:13 |
| ToyKeeper | beuno: Single quotes? As when escaping a command to run? | 01:14 |
| ToyKeeper | beuno: Can you use os.spawnvp() instead? | 01:14 |
| hersonls | spiv: modified: | 01:15 |
| hersonls | teste.py | 01:15 |
| hersonls | pending merges: | 01:15 |
| hersonls | hersonls 2008-05-22 Alteracao branch1 | 01:15 |
| beuno | ToyKeeper, this is for exporting sqlite and importing into mysql/postgre | 01:15 |
| ToyKeeper | Ah, okay. :) | 01:15 |
| spiv | hersonls: ok, so you have changes to commit. | 01:15 |
| hersonls | beuno: i need commit the resolv? | 01:15 |
| hersonls | spiv: :D | 01:15 |
| beuno | hersonls, yes, you need to commit every time you change the working tree | 01:16 |
| spiv | hersonls: a merge edits the working tree, very much like editing it with your text editor. Either way, you need to commit the changes to keep them. | 01:16 |
| hersonls | beuno: obviously :D | 01:17 |
| hersonls | spiv: i can edit the file with <<<<<< TREE? | 01:18 |
| spiv | hersonls: yes | 01:20 |
| spiv | hersonls: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#text-conflicts | 01:20 |
| === mw is now known as mw|out | ||
| hersonls | spiv: i dont undersand, im brazilian and my english is bad | 01:48 |
| sidnei | niemeyer: oi? | 01:49 |
| hersonls | spiv: i edit the test.py or teste.py.THIS ? | 01:49 |
| niemeyer | sidnei: Yo! | 01:49 |
| sidnei | niemeyer: hey there! | 01:49 |
| niemeyer | sidnei: How're things in the chimarrão land? | 01:49 |
| sidnei | niemeyer: don't know, im in houston right now :) | 01:49 |
| spiv | hersonls: test.py | 01:50 |
| niemeyer | sidnei: Oh, yeah.. might be hard to get good chimarrão there ;) | 01:50 |
| sidnei | indeed | 01:50 |
| sidnei | niemeyer: btw, you've been talked about a lot this week over here | 01:50 |
| niemeyer | sidnei: Oh, good to head, I guess :-) | 01:50 |
| niemeyer | hear even | 01:50 |
| sidnei | niemeyer: just introduced some folks to geohash yesterday to solve a problem | 01:50 |
| spiv | hersonls: the THIS/BASE/OTHER files are just for reference if you want to look at them. You can ignore them if you like, and they'll go away when you run "bzr resolve" | 01:50 |
| niemeyer | sidnei: Nice! | 01:51 |
| niemeyer | sidnei: What was it about? | 01:51 |
| hersonls | spiv: ok, i edit, and save file, and bzr resolve and finaly i commit, and push again. | 01:51 |
| hersonls | spiv: correct? | 01:51 |
| spiv | hersonls: right | 01:51 |
| sidnei | niemeyer: trying to locate greek orthotodox churches within a certain range of a user-specified location | 01:52 |
| niemeyer | sidnei: Aha, I see | 01:52 |
| hersonls | spiv: i update in brach, when i see test.py, "<<<<<<< TREE" this thera | 01:52 |
| niemeyer | sidnei: It's good to see it being useful in diverse situations | 01:52 |
| spiv | hersonls: you need to remove that yourself | 01:52 |
| spiv | hersonls: that's the conflict that bzr can't do automatically | 01:53 |
| sidnei | niemeyer: so, i just pushed that storm-mssql branch, long overdue | 01:53 |
| spiv | hersonls: so you need to fix it manually | 01:53 |
| spiv | hersonls: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#text-conflicts gives an example | 01:53 |
| hersonls | spiv: removing ? | 01:53 |
| sidnei | niemeyer: now, im not very experienced with bzr, so i am wondering if i should run bzr merge and do another push or what | 01:54 |
| niemeyer | sidnei: Ah, I just got the mail about it. Thanks a lot for sending it. We're lucky that you didn't end up killing it thinking it was safe indeed. | 01:54 |
| spiv | hersonls: the two branches have both made different changes to the same part of the file | 01:54 |
| hersonls | spiv: ok | 01:54 |
| spiv | hersonls: generally, what you want to do is have *both* changes after the merge | 01:54 |
| niemeyer | sidnei: That'd be terrific. It shouldn't have bad conflicts since we haven't changed pretty much anything in the area of backends. | 01:55 |
| sidnei | niemeyer: got only one conflict apparently | 01:56 |
| hersonls | spiv: more I corrected in one branch, I would not have to correct in the other after to make bzr push? | 01:56 |
| sidnei | niemeyer: so if i solve that i can just do another push? | 01:56 |
| niemeyer | sidnei: Right, solve conflict/test/commit/push | 01:57 |
| spiv | hersonls: once you've committed the merge, other branches that branch/merge from your branch will tend to reuse your conflict resolution. Is that what you were asking? | 01:57 |
| sidnei | niemeyer: great, thank you | 01:58 |
| niemeyer | sidnei: Thank you! | 01:58 |
| sidnei | niemeyer: i have to go now, if you have some time later or tomorrow, i have a different subject to talk to you about | 01:58 |
| hersonls | spiv: yes | 01:58 |
| niemeyer | sidnei: Sure thing, I'll certainly be around tomorrow.. just ping me | 01:59 |
| sidnei | thanks. cya | 01:59 |
| hersonls | poolie: i can import another branch in one branch? | 02:44 |
| hersonls | spiv: i can Commit an unversioned file or tree into the repository. | 02:52 |
| hersonls | ? | 02:52 |
| poolie | hersonls: by definition if it is unversioned you cannot commit it | 02:56 |
| poolie | you must add then commit | 02:56 |
| poolie | not sure what you mean about imports | 02:56 |
| hersonls | poolie: i import of athoner branch unversioned, for a new branch, for new versioned | 02:58 |
| hersonls | poolie: you understand? | 02:59 |
| poolie | sorry no | 03:05 |
| poolie | can you explain more in smaller steps? | 03:06 |
| hersonls | yes | 03:06 |
| hersonls | i have one branch with skel versioned | 03:06 |
| hersonls | and i create another branch, and need a copy of skel, in this new branch for new versioned | 03:07 |
| hersonls | poolie: ? | 03:10 |
| hersonls | poolie: you understand | 03:23 |
| hersonls | ,w | 03:23 |
| hersonls | ? | 03:23 |
| Verterok | moin | 03:48 |
| beuno | hey Verterok | 03:48 |
| Verterok | hi beuno | 03:48 |
| poolie | hersonls: you can branch the skel underneath it if that's what you mean | 03:53 |
| hersonls | poolie: one exemple of this, can be maked use: bzr export, and bzr add in new branch | 03:54 |
| * igc lunch | 04:24 | |
| poolie | hersonls: you could do that | 04:28 |
| bob2 | http://bramcohen.livejournal.com/52148.html | 05:07 |
| mwhudson | some of those things make sense | 05:09 |
| mwhudson | he doesn't have "use PQM" or anything like that on there though | 05:09 |
| === i386__ is now known as i386 | ||
| lifeless | hersonls: I am now | 06:45 |
| lifeless | poolie: will inevestigate | 06:45 |
| lifeless | abentley: hi; might be able to this afternoon, otherwise travel will obliterate theweekend | 06:45 |
| poolie | lifeless: hello | 07:01 |
| poolie | did you mean investigate pqm? | 07:01 |
| lifeless | yes | 07:02 |
| lifeless | after breakfast :P | 07:02 |
| poolie | :) | 07:04 |
| poolie | how's czech breakfast? | 07:04 |
| lifeless | good and bad :) | 07:05 |
| lifeless | lots of food | 07:05 |
| lifeless | nice eggs, but shell too often | 07:05 |
| lifeless | http://advogato.org/person/robertc/diary/83.html | 07:07 |
| lifeless | /wave | 07:09 |
| spiv | Ah, "bzr push -r NNN --overwrite" is broken with bzr.dev (but not my branch where I've rearranged some of the involved code). | 08:07 |
| liw | lifeless, the big pack file, ETA in 15 hours :( | 08:08 |
| spiv | That had me confused for a bit, I was expecting bugs to be the other way around :) | 08:08 |
| lifeless | liw: Not to worry, I shall play next week | 08:08 |
| lifeless | poolie: web ui wasn't running | 08:09 |
| lelit | jelmer: hi! I tried using bzrlib.missing.find_unmerged() to get the list of missing revision as suggested by jam, but it still takes a *lot* of time, with 100% cpu... | 08:41 |
| igc | night all - have a good weekend | 08:49 |
| spiv | igc: g'night | 08:51 |
| poolie | lifeless: was it just lost in a reboot | 08:53 |
| lifeless | yes, I think | 08:53 |
| lifeless | we replaced the kernel after all | 08:53 |
| poolie | thanks | 08:54 |
| poolie | steve told me what you discovered re socket performance | 08:54 |
| poolie | how odd | 08:54 |
| spiv | Oh, what's the news there? | 08:55 |
| * spiv calls it day | 08:59 | |
| lifeless | poolie: I think it was thread starvation | 08:59 |
| lifeless | spiv: the slow tests on pqm were the reader thread in remote* tests spinning on recv | 09:00 |
| lifeless | spiv: I postulate that some threading quirk in the dapper kernel combined with the GIL to lead to a priority inversion situation with the writer never activating | 09:00 |
| spiv | lifeless: oh, funky. So it seems to be gone now? | 09:01 |
| lifeless | we replaced the kernel | 09:01 |
| lifeless | its reproducible on other datacentre machines | 09:01 |
| spiv | Interesting! | 09:01 |
| spiv | G'night. | 09:02 |
| lifeless | gnight | 09:02 |
| lifeless | see you folk mondayish | 09:02 |
| poolie | lifeless: are you still in prague? | 09:15 |
| poolie | have a good/safe flight back | 09:15 |
| poolie | hope you avoid heathrow :) | 09:15 |
| lifeless | yes, avoiding heathrow :) | 09:18 |
| poolie | well i think i'll call it a week too | 09:23 |
| === emgent_ is now known as emgent | ||
| alienbrain | Can bzr read users from LDAP? Or is it possible to do by writing a plugin? | 09:28 |
| poolie | alienbrain: interesting idea | 09:30 |
| poolie | alienbrain: for what purpose? | 09:31 |
| poolie | probably putting it into your systemwide nsswitch isbest | 09:32 |
| alienbrain | poolie: usually organizations have centralized LDAP directories where departments are projects and people are recorded there. And the idea is that everything else should read from there. | 09:32 |
| alienbrain | s/are/and/ | 09:32 |
| poolie | sure but what in particular do you want it to read? | 09:32 |
| alienbrain | poolie: which users has access to which repositories :) | 09:33 |
| poolie | oh i see | 09:33 |
| poolie | could you send mail about this to bazaar@lists.canonical.com? | 09:33 |
| poolie | i have to go... | 09:33 |
| alienbrain | poolie: sure, be aware I'm not a bzr user yet! :) | 09:33 |
| alienbrain | poolie: thanks | 09:33 |
| Jc2k | hey guys | 09:39 |
| Jc2k | am i right in thinking if i'm using bzr+ssh to push to server, that invokes the copy of bzr installed on the server? | 09:39 |
| awilkins | Jc2k: Yes, although you can tell it which copy to use by setting the correct env variable | 09:40 |
| Jc2k | awilkins: cool. can i use commit hooks to control where people can push to? | 09:41 |
| awilkins | I don't know the hooks that well | 09:42 |
| Jc2k | ok | 09:42 |
| alienbrain | poolie: done | 09:42 |
| lifeless | Jc2k: we tend to use file system permissions, because branches are direcotires | 11:41 |
| lifeless | *directories* | 11:41 |
| lifeless | Jc2k: its certainly possible to add hooks to the bzr server to allow such control | 11:41 |
| Jc2k | lifeless: file system perssions seems like a better idea | 11:42 |
| Peng | Does 'bzr pack' optimize the pack in any way? | 11:42 |
| lifeless | Peng: yes; it orders the revision texts topologically | 11:47 |
| === yacc__ is now known as yacc | ||
| sabdfl | spiv: fixing bugs before you even know they exist? that's neat | 12:49 |
| liw | the default bzr storage format now supports tags; is there any reason not to convert existing branches/repos? I assume that's doable with bzr upgrade | 13:13 |
| lifeless | yes, just bzr upgrade in each branch | 13:14 |
| lifeless | for network, do bzr upgrade sftp://url | 13:14 |
| liw | ack | 13:14 |
| lifeless | repo's do not need to change to supoprt tags | 13:15 |
| lifeless | just the branch object | 13:15 |
| liw | find / -type dir -name .bzr | ... | 13:15 |
| lifeless | liw: 'bzr branches' | 13:27 |
| liw | lifeless, bzr: ERROR: Transport error: [Errno 107] Transport endpoint is not connected: u'/home/liw/.gvfs/.bzr/branch-format' [Errno 107] Transport endpoint is not connected: u'/home/liw/.gvfs/.bzr/branch-format | 13:28 |
| lifeless | liw: interesting | 13:28 |
| lifeless | liw: is your gvfs session active? | 13:28 |
| liw | lifeless, I've no idea, how do I check? | 13:29 |
| lifeless | i dunno | 13:29 |
| lifeless | sabdfl: ping | 13:30 |
| sabdfl | lifeless: pong | 13:30 |
| lifeless | can rob savoye and I get together with you now ? | 13:30 |
| sabdfl | sure, meet you at the reception desk in 5 | 13:30 |
| lifeless | where the admins are? | 13:31 |
| sabdfl | yes | 13:31 |
| lifeless | kk | 13:31 |
| === mw|out is now known as mw | ||
| lifeless | abentley: ping | 14:14 |
| abentley | lifeless: pong | 14:15 |
| lifeless | make_mpdiffs | 14:15 |
| lifeless | if I read this correctly, all it needs from the internals of a versionedfile is the _extract_blocks facility | 14:15 |
| abentley | I would think so. | 14:15 |
| lifeless | I'm thinking of putting _extract_blocks as a method on the objects yielded by the get_record_stream interface | 14:16 |
| lifeless | how does that sound to you? | 14:16 |
| lifeless | I think one problem is that it would actually get the content before checking that it can extract blocks from it | 14:17 |
| lifeless | so for 1/200 (the delta chain length) we'd do more work | 14:17 |
| lifeless | alternative, I can keep it where it is if you'd prefer | 14:18 |
| abentley | Well, I wonder if it would be extra handling vs getting the blocks from the versionedfile. | 14:18 |
| lifeless | (but migrated to the new api) | 14:18 |
| lifeless | so what I was thinking is that the get_texts is going to iterate the contents *anyway* | 14:18 |
| lifeless | because its going to be getting the contents of every version it wants to emit, plus the basis texts for the exit points of the dag | 14:19 |
| abentley | And then extract_blocks only gives output against the build parent? | 14:19 |
| lifeless | right | 14:19 |
| lifeless | (as it does today) | 14:19 |
| abentley | And then you have to figure out whether the build parent is the ancestor you want to diff against. | 14:20 |
| lifeless | fulltext.extrct_blocks -> None | 14:20 |
| lifeless | somedelta.extract_blocks -> delta_parent, blocks | 14:20 |
| abentley | I don't think it makes a huge difference to me. | 14:21 |
| lifeless | cool | 14:21 |
| lifeless | I think I'll leave it where it is in order to port code; then see how it fits in the location I proposed | 14:22 |
| abentley | There were two things about looms. | 14:23 |
| lifeless | shoot | 14:23 |
| abentley | One was the outstanding queue of patches. I was wondering if you'd forgotten about them. | 14:23 |
| lifeless | I had; I wish there was a bb instance to remember them for me | 14:23 |
| gour | lifeless: nice post on the planet ;) | 14:24 |
| lifeless | gour: :) | 14:24 |
| abentley | lifeless: Well, I'll see what I can do about that. | 14:24 |
| gour | lifeless: it's very encouraging | 14:24 |
| lifeless | abentley: you could file 'merge requests' in launchpad for them into https://code.edge.launchpad.net/~bzr-loom-devs/bzr-loom/trunk | 14:25 |
| abentley | The other is that I fear my practical desires and your design ideas are in conflict re: record. | 14:25 |
| abentley | Basically, I don't want to record. | 14:25 |
| lifeless | ok | 14:25 |
| abentley | I especially don't want to have an extra step be required for push to work properly. | 14:25 |
| lifeless | there is room to use the working-loom to avoid needing to record, though it obviously costs in the ability to collaborate on ooms because of the loos of 3-way mergeing | 14:26 |
| lifeless | *or* | 14:26 |
| lifeless | auto-record at commit, which will incur a cost in storage/depth | 14:26 |
| lifeless | (and conflicts rather adly with handling merges and conflict resolution at the loom scale) | 14:27 |
| abentley | I still don't understand when someone should record. Doing it at push time sounds like you really should have done it earlier, but you're fixing it before it goes public. | 14:28 |
| lifeless | you should record when you want people to be able to merge from you/before you merge from them (so you can revert) | 14:30 |
| lifeless | just like in a branch you commit at the same points | 14:30 |
| lifeless | anyhow, I'm very open to finding some compromise that works; a pure tool with no users -> fail | 14:30 |
| abentley | It seems like I would want to record at every commit, more or less. | 14:31 |
| abentley | Perhaps if I was merging from upstream, I would commit to all threads and then record. | 14:32 |
| lifeless | right | 14:32 |
| lifeless | I think if you bzr merge of looms actually did something it would be more obvious | 14:32 |
| lifeless | there is room in the working-loom to do merge, but noone has written the code | 14:32 |
| lifeless | it basically needs to zip from the bottom up, doing a pull where possible or merge otherwise | 14:33 |
| lifeless | letting users resolve conflicts etc | 14:33 |
| abentley | I would only want pull if the current revision was a lefthand ancestor of the other tip. | 14:34 |
| abentley | But basically I was agreeing with the notion of auto-record at commit. | 14:35 |
| lifeless | I'd like to get merge doing the right thing before doing that | 14:36 |
| lifeless | because at the moment noone is really collaborating on a stack of threads | 14:37 |
| lifeless | so its kind of like very early bzr where we didn't have merge :) | 14:37 |
| lifeless | I agree that there are some possible options in the implementation of merge; they mainly seem to be policy related | 14:37 |
| abentley | Every time I try to share a loom with someone, it doesn't work properly. I haven't investigated. | 14:37 |
| lifeless | I'm -> coding again | 14:38 |
| jml | is there a doc (or a good example) for extending an existing bzr command in a plugin? | 14:43 |
| matkor | What I have to do to have my patches sent Wensday to bzr-gtk@lists.canonical.com to be visible in http://bundlebuggy.vernstok.nl/bzr-gtk/ ? As I understand it is right way of submiting patches for olive-gtk... | 14:47 |
| matkor | Who can vote for patches BTW ? | 14:47 |
| awilkins | matkor: If you're not a list member, your posts will languish in limbo on that mailing list | 14:51 |
| awilkins | I had to subscribe to get my patches to arrive in the bundlebuggy in a timely fasion | 14:51 |
| phanatic | matkor: the people who are considered the core contributors. like jelmer, beuno, abentley, schierbeck, vila... | 14:51 |
| phanatic | matkor: but you could also request voting rights, since you contributed quite a lot in the past | 14:52 |
| matkor | awilkins: I think I am subscribed, as I get e-mails form list ... | 14:54 |
| phanatic | matkor: it could be the temporary brokenness of bb as well | 14:55 |
| phanatic | matkor: did you send patches or bundles, erm merge requests? | 14:55 |
| matkor | phanatic: I used bzr send <list> using kmail | 14:55 |
| phanatic | then it should be fine | 14:56 |
| tale_ | I've created a local branch of a project on launchpad. I've made some commits to my local branch, but I haven't pushed them back to the main branch. Now I see that the main branch has some new commits. What command should I use to update my branch with the main branch's commits? | 15:26 |
| Peng | "bzr merge"? | 15:27 |
| tale_ | so i don't need to specify the main branch? | 15:27 |
| radix | yes, "cd local-branch; bzr merge <main branch URL>" | 15:30 |
| radix | "bzr commit" (after reviewing them or running the unit tests or whatever) | 15:30 |
| === vila_ is now known as vila | ||
| bob2 | (bzr remembers where you branches from and considers that the parent url, by default, for pull and merge) | 15:32 |
| vila | phanatic: thanks for promoting me as a gtk core dev :) What do I need to do to log into gtk-BB ? | 15:32 |
| phanatic | vila: oh, sorry, i thought you were one :) please ask jelmer for credentials, he runs the server. | 15:33 |
| tale_ | thanks. That worked. I'm loving the capabilities of bzr. I wish I didn't have to use Clear Case at work! :-) | 15:34 |
| radix | hmm. if I used --fixes, how do I later find out what tickets a revision fixes? It seems it doesn't show up in 'bzr log' like --author does, which would be ideal. | 15:35 |
| jelmer | radix: "bzr viz" can show you, I'm not sure if there's a way to do so on the command line | 15:37 |
| radix | jelmer: I don't see it, maybe I don't have a recent enough version | 15:42 |
| jelmer | there should be a "bugs" tab | 15:42 |
| jelmer | but it's been added pretty recently | 15:42 |
| matkor | jelmer: Any idea why my tiny patches sent Wensday to bzr-gtk@lists.canonical.com to be visible in http://bundlebuggy.vernstok.nl/bzr-gtk/ ? | 15:47 |
| matkor | jelmer: "to be visible" -> "are not yet visible" | 15:54 |
| lifeless | elmo: vostok; loggerhead; swapping? | 15:57 |
| CardinalFang | "bzr revid", like "bzr revno", would be very useful. | 16:05 |
| CardinalFang | Any takers? It should be easy, I'd think. | 16:05 |
| Odd_Bloke | CardinalFang: File a bug if one doesn't exist. :) | 16:06 |
| jelmer | matkor, hmm, odd | 16:06 |
| jelmer | matkor, I'll see if I can find what causes it to break | 16:06 |
| bob2 | heh, bzr lookup-revision $(bzr revno) | 16:06 |
| fullermd | CardinalFang: bzr revision-info | cut -f1 -d' ' | 16:07 |
| fullermd | Er, -f2. | 16:08 |
| luks | bzr version-info --custom --template {revision_id} | 16:17 |
| jelmer | matkor, should be fixed now | 16:30 |
| matkor | jelmer: Thank you - should I bzr send <list> again both patches ? | 16:52 |
| matkor | Oh I see them :) | 16:52 |
| Pieter | Hi. I'm trying to use bzr fast-export on the bzr repository, but it fails when trying to find revision john@arbash-meinel.com-20050711051006-2d11704675600e95 | 16:55 |
| Pieter | when doing a bzr log --show-ids, it can find a commit with that revision as parent, but not the revision itself | 16:55 |
| Pieter | how is that possible? :) | 16:56 |
| Peng | Pieter: Same results here. | 17:03 |
| Peng | (For anyone else, it's r897, which does have two parents.) | 17:03 |
| Peng | Pieter: Maybe bzr made more ghosts in 2005. I dunno. | 17:04 |
| === yacc_ is now known as yacc | ||
| abentley | Pieter: Bazaar supports revisions like that. They're called "ghost revisions". | 17:12 |
| jelmer | lifeless, ping | 17:15 |
| jelmer | lifeless, just wondering if you have an eta on when you'll be updating your shallow-branch branch to bzr.dev | 17:17 |
| Pieter | abentley, Peng: ah, I didn't know that.. thanks :) | 17:17 |
| Pieter | dato: any chance on an easy fix to support ghost revisions in bzr fast-export? :) | 17:18 |
| lifeless | jelmer: EUDS | 17:24 |
| lifeless | jelmer: maybe on the plane | 17:24 |
| Pilky | anybody here who could explain in a nutshell what it is that makes bzr slower than other systems? | 17:24 |
| jelmer | lifeless: k | 17:24 |
| lifeless | Pilky: broadly; its mainly bugs | 17:25 |
| gour | Pilky: it's not optimized yet, that's all ;) | 17:25 |
| Pilky | heh | 17:25 |
| lifeless | Pilky: in some cases we do do more work deliberately, to get a nicer user experience, but the delta in performance should be small once bugs etc are fixed | 17:25 |
| lifeless | Pilky: we started with 'good ui' rather than 'fast performance' | 17:26 |
| * gour likes such approach and that's why he migrated to bzr recently | 17:26 | |
| Pilky | just started thinking about it as I was talking to a friend who uses mercurial and he can do a log on 1000 revisions in 0.25s, took me 1.9s to do a log on 5 revisions :P | 17:26 |
| Pilky | lifeless: much easier to improve bad performance than a bad UI ;) | 17:26 |
| lifeless | Pilky: 'log --line' is more approximately what hg log does | 17:26 |
| * pickscrape likens it to why Postgres is better than MySQL | 17:27 | |
| lifeless | bbiab | 17:27 |
| gour | Pilky: i never 'understood' hg, but bzr 'just clicked' | 17:27 |
| Pieter | why doesn't bzr log use a pager by default? | 17:27 |
| Pilky | gour: I never fully looked into hg | 17:27 |
| Pilky | I started looking at git and then glanced over hg before bzr took my attention | 17:28 |
| gour | Pilky: i use(d) darcs for long time, but have chosen bzr as the next one | 17:28 |
| Pilky | yeah, I used svn for half a year, used nothing for half a year then half used Xcode's snapshots feature for half a year | 17:29 |
| gour | Pilky: git is, imho, too complex to invest lot of learning to understand its mechanisms...DVCS is just a tool, and bzr 'just works' | 17:29 |
| Pilky | yeah agreed | 17:29 |
| gour | hg could be ok, but it does not match my mind :-) | 17:29 |
| Pilky | in my normal use bzr's speed isn't too much an issue, more speed would be a nicety | 17:29 |
| gour | that's why i liked darcs, but it has problems which are not so easy solved | 17:30 |
| gour | i agree. i do not need to handle linux kernel's history | 17:30 |
| Pilky | but as I'm running unit tests against some code that calls bzr now, it starts to get a little bit painful | 17:30 |
| gour | Pilky: the best it to play with bzr and see how it feels | 17:30 |
| gour | Pilky: have you read http://www.advogato.org/person/robertc/ | 17:31 |
| Pilky | yeah, I've been using bzr for over a month now, it's just the speed annoys me slightly in my "not very usual" use case | 17:31 |
| gour | bzr's speed is constantly improving | 17:32 |
| gour | 'cause it gets lot of attention lately | 17:32 |
| gour | soon it will be 'good enough' for all the tasks.. | 17:32 |
| Pieter | I hope bzr log path/ will get somewhat faster | 17:33 |
| * fullermd hopes more that bzr log path/ will get somewhat useful. | 17:35 | |
| lelit | speaking of speed: jelmer, did you read my comment about find_unmerged() not being any faster than old way for me? | 17:40 |
| Pilky | gour: yeah, bzr seems to be getting new versions pretty frequently | 17:41 |
| lelit | it took 1h23min to fetch the missing changeset between an empty branch and bzr.dev (a local clone) | 17:41 |
| Pilky | though I still haven't updated to 1.5 yet because the Leopard installer package hasn't been made yet (and I don't like going through MacPorts) | 17:42 |
| gour | Pilky: right. another good reason to stay with bzr - regular (monthly) releases, active herd of devs and friendly #bzr community...what else you want? | 17:42 |
| pickscrape | It doesn't make coffee for me yet | 17:42 |
| Pilky | heh, a GUI, but I'm working on that one ;) | 17:42 |
| fullermd | A marshmallow-pooping unicorn. | 17:42 |
| gour | lelit: hi lelit. optimizing tailor? | 17:42 |
| Pilky | a pony would be nice too :P | 17:42 |
| lelit | gour, no, just making it more powerful :) | 17:43 |
| gour | Pilky: there are two guis gtk+ & qt | 17:43 |
| Pilky | gour: a native Mac GUI | 17:43 |
| gour | lelit: testing with fallback VCS, nice ;) | 17:43 |
| lelit | yep! | 17:43 |
| gour | Pilky: there is, afaik, native gtk+ port | 17:43 |
| Pilky | by native I mean, designed for the Mac | 17:43 |
| gour | i see...no experience with Mac here | 17:44 |
| lelit | gour: and now it seems that tailor has first class support for either VCS! | 17:44 |
| lifeless | lelit: bzr --lsprof-file foo.callgrind | 17:45 |
| gour | lelit: keeping the whole history? have you seen my reply to DVC ml? | 17:45 |
| lifeless | lelit: post foo.callgrind somewere bzr devs can look at | 17:45 |
| lelit | lifeless: but I'm not using the bzr frontend | 17:45 |
| * gour recommends tailor to everyone for the migrating csets tasks | 17:45 | |
| Pilky | gour: well this is the mock up we have for bzr status in our OS X client: http://dropbox.mcubedsw.com/bazaarx/images/screenshot.png | 17:45 |
| lelit | but I think that the bzr missing is using the same code path... | 17:46 |
| lelit | I'll try that | 17:46 |
| gour | Pilky: looks nice & clean | 17:46 |
| lifeless | lelit: import bzrlib.lsprof | 17:47 |
| lifeless | lelit: retvalue, stats = bzrlib.lsprof.profile(thing, args etc) | 17:47 |
| Pilky | gour: yeah, it's what we're aiming for, plus we're hoping to integrate some Mac only stuff to make it better for Mac devs | 17:47 |
| lifeless | stats.calltree(open('foo.callgrind', 'wb')) | 17:47 |
| gour | Pilky: keep up the good job | 17:47 |
| lifeless | lelit: you can look at it with kcachegrind yourself too; it will likely show something obvious:P | 17:48 |
| Pilky | gour: will do :) | 17:48 |
| lelit | lifeless: uhm, "bzr missing" is actually very fast, so I'm obviously doing something wrong... | 17:50 |
| lifeless | :P | 17:52 |
| lifeless | Well, time for the after conference event now | 17:52 |
| lifeless | so ciao! | 17:52 |
| gour | lifeless: take care ;) | 17:52 |
| lamalex | Hi bzr folks, I'm trying to use bzr-svn, how does it handle authenticated checkouts? | 17:56 |
| jelmer | lamalex, see the FAQ | 17:57 |
| lamalex | er, any specific question? | 17:58 |
| lamalex | the bzr-svn wiki page it links to doesn't exist | 17:58 |
| jelmer | lamalex, http://samba.org/~jelmer/bzr-svn/FAQ.html | 17:58 |
| jelmer | lamalex, Maybe there's a broken link somewhere - where did you find it? | 17:59 |
| lamalex | http://bazaar-vcs.org/FAQ#head-563231e3f43f95a0e818d54ed945fd7c72a32faa | 18:00 |
| jelmer | ah, sorry - I meant the bzr-svn FAQ | 18:00 |
| lamalex | :P | 18:01 |
| lamalex | np | 18:01 |
| lamalex | thanks for the link | 18:01 |
| lelit | uhm, I found what seems a "no way out" condition with the tailor bzr backend :-| | 18:41 |
| lelit | it broke on http://pastebin.com/d8f22c27: what a strange patch indeed! | 18:42 |
| lelit | how should one interpret the "xml6.py" life? was it added? removed? renamed? | 18:44 |
| fullermd | xml6 existed before that branch. In that branch, it was renamed to xml8 and a new xml6 was created. Later in the branch, xml8 was deleted, and a new xml8 was created via a move from xml5 (and a new xml5 was created) | 18:49 |
| fullermd | It shows removed on the old xml6 because the xml6->xml8, rm(xml8) was collapsed away so the move doesn't get shown. | 18:49 |
| fullermd | Showing the file-id's makes it clearer. | 18:50 |
| fullermd | removed: | 18:50 |
| fullermd | bzrlib/xml6.py xml6.py-20060823042456-dbaaq4atrche7xy5-1 | 18:50 |
| fullermd | added: | 18:50 |
| fullermd | bzrlib/xml6.py xml6.py-20080327235607-1skmbg4o9cd1o636-1 | 18:50 |
| lelit | fullermd: thnx, but how is that "bzr log" on that file does not brings up the previous (2006-08-23) patch? | 18:51 |
| fullermd | Presumably, because you're `bzr log`'ing from now, which means you're actually logging the file xml6.py-20080327235607-1skmbg4o9cd1o636-1 | 18:52 |
| fullermd | So you only coincidentally see the changes to xml6.py-20060823042456-dbaaq4atrche7xy5-1 when they happen to have occured in the same revisions. | 18:53 |
| fullermd | 3311.3.1 was the first rev where that [new] file existed, so it's the first you see. | 18:53 |
| === hersonl1 is now known as hersonls | ||
| catlee | Hello | 19:06 |
| catlee | I'm trying to use bzrlib to inspect a bzr repo | 19:07 |
| catlee | I'm using repo = BzrDir.open(pathToRepo), and then repo.revision_tree(rev) to get a Tree object | 19:08 |
| catlee | I want get a directory listing of one directory in the tree | 19:09 |
| catlee | without walking the whole tree | 19:09 |
| catlee | is there a way to do that? | 19:09 |
| lelit | lifeless: solved! the problem was that the code needs to be wrapped by a lock! | 19:54 |
| === mw is now known as mw|food | ||
| === hersonl1 is now known as hersonls | ||
| === mario_ is now known as pygi | ||
| abentley | catlee: Are you trying to avoid listing subdirectories of the directory you are listing? | 21:13 |
| catlee | abentley, yes, I just want a shallow directory listing | 21:14 |
| abentley | I don't know if we have provide a way to do that directly. You could just look at InventoryDirectory.children, though. | 21:15 |
| oly | I have been looking in the docs for an overwrite local type command, basically i want to re pull the remote overwritting my local changes and resolving conflicts | 21:16 |
| oly | what command should i use for such a task ? | 21:16 |
| abentley | oly: pull --overwrite ? | 21:17 |
| === mw|food is now known as mw | ||
| oly | i tried that but it says no revisions to pull | 21:18 |
| abentley | Are you sure you're not up to date? | 21:18 |
| oly | i think because i did a pull, and it created a load of conflcits | 21:18 |
| oly | i am uptodate, its just a mess basically, hence why i want the latest version from the server | 21:19 |
| abentley | Oh, so you want "revert". | 21:19 |
| abentley | It sounds like your branch is up-to-date, but you have local, uncommitted changes. | 21:20 |
| oly | not sure is that a local revert ? | 21:20 |
| abentley | Yes. It just changes the tree contents. | 21:20 |
| oly | probably not what i want then | 21:20 |
| oly | i dont want a previous version, just all the files to match the online ones | 21:21 |
| oly | i did a commit at work of my very latest changes and want to pull them to this machine, but i must of made change here at some point and taken them to work on a memory stick instead of committing them | 21:22 |
| abentley | When you run log, what's the latest commit? | 21:22 |
| abentley | Is it the online one? | 21:23 |
| oly | yes | 21:23 |
| abentley | So like I said before, your branch is up to date with the online one. You just need to revert the changes in your tree. | 21:24 |
| oly | lol, im confused now | 21:26 |
| oly | bzr revert looks like its taking changes locally, so i thought i could then bzr pull --overwrite | 21:27 |
| oly | but it still says im upto date | 21:27 |
| oly | aha, i think its worked though thanks | 21:28 |
| oly | even though i dont understand how | 21:28 |
| abentley | The first time you pulled, you had local, uncommited changes in your tree. | 21:28 |
| abentley | So it updated your branch and left you with a dirty tree. | 21:29 |
| abentley | Then you reverted, and it changed your tree to match the latest revision in your branch, i.e. the online revision. | 21:29 |
| oly | okay so its reverting to the latest online branch | 21:30 |
| oly | that makes more sense, thanks for clarifying that | 21:30 |
| abentley | It's the latest revision in your local branch. | 21:33 |
| abentley | It happens to be the same as the latest revision in your online branch. | 21:33 |
| oly | okay, | 21:35 |
| === j-dizzle is now known as jdong | ||
| lelit | yay! http://pastebin.com/d263128ed | 23:08 |
| Pieter | bzr log --line only show commits on the mainline? | 23:38 |
| beuno | Pieter, yeap | 23:42 |
| Pieter | ah, that's unexpected.. I'd thought it would just display each commit on a line | 23:46 |
| === emgent is now known as emgent`UDS | ||
| === emgent`UDS is now known as emgent | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
