[00:00] <igc> morning
[00:03] <hersonls> poolie: hi
[00:04] <hersonls> poolie: where i found documentation of the loggerhead?
[00:05] <yacc> I just wonder, is it possible to push a branch to two different branches concurrently?
[00:06] <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:07] <poolie> well, "it should work" sounds uncertain, i know it will work
[00:08] <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:12] <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:13] <yacc> spiv: well, I'm nailed to 1.3.1 on Hardy anyway (the PPA was missing bzr-svn last time I checked)
[00:14] <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:15] <yacc> Nope, isn't that beefy.
[00:15] <poolie> lifeless: hi, pqm seems to be having a lot of trouble
[00:16] <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: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:18] <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:19] <spiv> (Or maybe the URL needs to be the local path?  I forget.)
[00:20] <yacc> Nope, it worked fine with the prefix of the remote url ;)
[00:20] <spiv> Ah, good.
[00:21] <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:22] <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:23] <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:24] <yacc> jelmer: well, actually the last time I did upstream it was 4 revisions.
[00:24] <hersonls> lifeless: you be here?
[00:25] <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:26] <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:27] <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:28] <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:29] <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:55] <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:57] <hersonls> poolie: to resolve a text conflicts, i need run bzr revert first?
[00:59] <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
[01:01] <hersonls> beuno: tanks
[01:01] <beuno> hersonls, welcome'
[01:08] <hersonls> i dont understand, i need uncommit to resolve conflict ?
[01:09] <beuno> hersonls, no, why would you get that impression?
[01:10] <hersonls> beuno: i try, bzr resolve test.py
[01:11] <hersonls> beuno: and try merge again, and show me a message, "has uncommitted changes. "
[01:12] <beuno> hersonls, you resolved all the conflicts and ran "bzr resolve test.py"?
[01:13] <hersonls> beuno: after try bzr resolve, no showme any messages
[01:13] <spiv> hersonls: what does "bzr status" report?
[01:14] <ToyKeeper> beuno: Single quotes?  As when escaping a command to run?
[01:14] <ToyKeeper> beuno: Can you use os.spawnvp() instead?
[01:15] <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:16] <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:17] <hersonls> beuno: obviously :D
[01:18] <hersonls> spiv: i can edit the file with <<<<<< TREE?
[01:20] <spiv> hersonls: yes
[01:20] <spiv> hersonls: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#text-conflicts
[01:48] <hersonls> spiv: i dont undersand, im brazilian and my english is bad
[01:49] <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:50] <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:51] <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:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <niemeyer> sidnei: Sure thing, I'll certainly be around tomorrow.. just ping me
[01:59] <sidnei> thanks. cya
[02:44] <hersonls> poolie: i can import another branch in one branch?
[02:52] <hersonls> spiv: i can Commit an unversioned file or tree into the repository.
[02:52] <hersonls> ?
[02:56] <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:58] <hersonls> poolie: i import of athoner branch ﻿unversioned, for a new branch, for new versioned
[02:59] <hersonls> poolie: you understand?
[03:05] <poolie> sorry no
[03:06] <poolie> can you explain more in smaller steps?
[03:06] <hersonls> yes
[03:06] <hersonls> i have one branch with skel versioned
[03:07] <hersonls> and i create another branch, and need a copy of skel, in this new branch for new versioned
[03:10] <hersonls> poolie: ?
[03:23] <hersonls> poolie: you understand
[03:23] <hersonls> ,w
[03:23] <hersonls> ?
[03:48] <Verterok> moin
[03:48] <beuno> hey Verterok
[03:48] <Verterok> hi beuno
[03:53] <poolie> hersonls: you can branch the skel underneath it if that's what you mean
[03:54] <hersonls> poolie: ﻿one exemple of this, can be maked use: bzr export, and  bzr add in new branch
[04:24]  * igc lunch
[04:28] <poolie> hersonls: you could do that
[05:07] <bob2> http://bramcohen.livejournal.com/52148.html
[05:09] <mwhudson> some of those things make sense
[05:09] <mwhudson> he doesn't have "use PQM" or anything like that on there though
[06:45] <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
[07:01] <poolie> lifeless: hello
[07:01] <poolie> did you mean investigate pqm?
[07:02] <lifeless> yes
[07:02] <lifeless> after breakfast :P
[07:04] <poolie> :)
[07:04] <poolie> how's czech breakfast?
[07:05] <lifeless> good and bad :)
[07:05] <lifeless> lots of food
[07:05] <lifeless> nice eggs, but shell too often
[07:07] <lifeless> http://advogato.org/person/robertc/diary/83.html
[07:09] <lifeless>  /wave
[08:07] <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:08] <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:09] <lifeless> poolie: web ui wasn't running
[08:41] <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:49] <igc> night all - have a good weekend
[08:51] <spiv> igc: g'night
[08:53] <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:54] <poolie> thanks
[08:54] <poolie> steve told me what you discovered re socket performance
[08:54] <poolie> how odd
[08:55] <spiv> Oh, what's the news there?
[08:59]  * spiv calls it day
[08:59] <lifeless> poolie: I think it was thread starvation
[09:00] <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:01] <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:02] <spiv> G'night.
[09:02] <lifeless> gnight
[09:02] <lifeless> see you folk mondayish
[09:15] <poolie> lifeless: are you still in prague?
[09:15] <poolie> have a good/safe flight back
[09:15] <poolie> hope you avoid heathrow :)
[09:18] <lifeless> yes, avoiding heathrow :)
[09:23] <poolie> well i think i'll call it a week too
[09:28] <alienbrain> Can bzr read users from LDAP? Or is it possible to do by writing a plugin?
[09:30] <poolie> alienbrain: interesting idea
[09:31] <poolie> alienbrain: for what purpose?
[09:32] <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:33] <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:39] <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:40] <awilkins> Jc2k: Yes, although you can tell it which copy to use by setting the correct env variable
[09:41] <Jc2k> awilkins: cool. can i use commit hooks to control where people can push to?
[09:42] <awilkins> I don't know the hooks that well
[09:42] <Jc2k> ok
[09:42] <alienbrain> poolie: done
[11:41] <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:42] <Jc2k> lifeless: file system perssions seems like a better idea
[11:42] <Peng> Does 'bzr pack' optimize the pack in any way?
[11:47] <lifeless> Peng: yes; it orders the revision texts topologically
[12:49] <sabdfl> spiv: fixing bugs before you even know they exist? that's neat
[13:13] <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:14] <lifeless> yes, just bzr upgrade in each branch
[13:14] <lifeless> for network, do bzr upgrade sftp://url
[13:14] <liw> ack
[13:15] <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:27] <lifeless> liw: 'bzr branches'
[13:28] <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:29] <liw> lifeless, I've no idea, how do I check?
[13:29] <lifeless> i dunno
[13:30] <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:31] <lifeless> where the admins are?
[13:31] <sabdfl> yes
[13:31] <lifeless> kk
[14:14] <lifeless> abentley: ping
[14:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <abentley> I don't think it makes a huge difference to me.
[14:21] <lifeless> cool
[14:22] <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:23] <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:24] <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:25] <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:26] <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:27] <lifeless> (and conflicts rather adly with handling merges and conflict resolution at the loom scale)
[14:28] <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:30] <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:31] <abentley> It seems like I would want to record at every commit, more or less.
[14:32] <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:33] <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:34] <abentley> I would only want pull if the current revision was a lefthand ancestor of the other tip.
[14:35] <abentley> But basically I was agreeing with the notion of auto-record at commit.
[14:36] <lifeless> I'd like to get merge doing the right thing before doing that
[14:37] <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:38] <lifeless> I'm -> coding again
[14:43] <jml> is there a doc (or a good example) for extending an existing bzr command in a plugin?
[14:47] <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:51] <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:52] <phanatic> matkor: but you could also request voting rights, since you contributed quite a lot in the past
[14:54] <matkor> awilkins: I think I am subscribed, as I get e-mails form list ...
[14:55] <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:56] <phanatic> then it should be fine
[15:26] <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:27] <Peng> "bzr merge"?
[15:27] <tale_> so i don't need to specify the main branch?
[15:30] <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:32] <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:33] <phanatic> vila: oh, sorry, i thought you were one :) please ask jelmer for credentials, he runs the server.
[15:34] <tale_> thanks.  That worked.  I'm loving the capabilities of bzr.  I wish I didn't have to use Clear Case at work!  :-)
[15:35] <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:37] <jelmer> radix: "bzr viz" can show you, I'm not sure if there's a way to do so on the command line
[15:42] <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:47] <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:54] <matkor> jelmer: "to be visible" -> "are not yet visible"
[15:57] <lifeless> elmo: vostok; loggerhead; swapping?
[16:05] <CardinalFang> "bzr revid", like "bzr revno", would be very useful.
[16:05] <CardinalFang> Any takers?  It should be easy, I'd think.
[16:06] <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:07] <fullermd> CardinalFang: bzr revision-info | cut -f1 -d' '
[16:08] <fullermd> Er, -f2.
[16:17] <luks> bzr version-info --custom --template {revision_id}
[16:30] <jelmer> matkor, should be fixed now
[16:52] <matkor> jelmer: Thank you - should I  bzr send <list> again both patches ?
[16:52] <matkor> Oh I see them :)
[16:55] <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:56] <Pieter> how is that possible? :)
[17:03] <Peng> Pieter: Same results here.
[17:03] <Peng> (For anyone else, it's r897, which does have two parents.)
[17:04] <Peng> Pieter: Maybe bzr made more ghosts in 2005. I dunno.
[17:12] <abentley> Pieter: Bazaar supports revisions like that.  They're called "ghost revisions".
[17:15] <jelmer> lifeless, ping
[17:17] <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:18] <Pieter> dato: any chance on an easy fix to support ghost revisions in bzr fast-export? :)
[17:24] <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:25] <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:26] <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:27]  * 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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <Pieter> I hope bzr log path/ will get somewhat faster
[17:35]  * fullermd hopes more that bzr log path/ will get somewhat useful.
[17:40] <lelit> speaking of speed: jelmer, did you read my comment about find_unmerged() not being any faster than old way for me?
[17:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:50] <lelit> lifeless: uhm, "bzr missing" is actually very fast, so I'm obviously doing something wrong...
[17:52] <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:56] <lamalex> Hi bzr folks, I'm trying to use bzr-svn, how does it handle authenticated checkouts?
[17:57] <jelmer> lamalex, see the FAQ
[17:58] <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:59] <jelmer> lamalex, Maybe there's a broken link somewhere - where did you find it?
[18:00] <lamalex> http://bazaar-vcs.org/FAQ#head-563231e3f43f95a0e818d54ed945fd7c72a32faa
[18:00] <jelmer> ah, sorry - I meant the bzr-svn FAQ
[18:01] <lamalex> :P
[18:01] <lamalex> np
[18:01] <lamalex> thanks for the link
[18:41] <lelit> uhm, I found what seems a "no way out" condition with the tailor bzr backend :-|
[18:42] <lelit> it broke on http://pastebin.com/d8f22c27: what a strange patch indeed!
[18:44] <lelit> how should one interpret the "xml6.py" life? was it added? removed? renamed?
[18:49] <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:50] <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:51] <lelit> fullermd: thnx, but how is that "bzr log" on that file does not brings up the previous (2006-08-23) patch?
[18:52] <fullermd> Presumably, because you're `bzr log`'ing from now, which means you're actually logging the file xml6.py-20080327235607-1skmbg4o9cd1o636-1
[18:53] <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.
[19:06] <catlee> Hello
[19:07] <catlee> I'm trying to use bzrlib to inspect a bzr repo
[19:08] <catlee> I'm using repo = BzrDir.open(pathToRepo), and then repo.revision_tree(rev) to get a Tree object
[19:09] <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:54] <lelit>  lifeless: solved! the problem was that the code needs to be wrapped by a lock!
[21:13] <abentley> catlee: Are you trying to avoid listing subdirectories of the directory you are listing?
[21:14] <catlee> abentley, yes, I just want a shallow directory listing
[21:15] <abentley> I don't know if we have provide a way to do that directly.  You could just look at InventoryDirectory.children, though.
[21:16] <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:17] <abentley> oly: pull --overwrite ?
[21:18] <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:19] <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:20] <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:21] <oly> i dont want a previous version, just all the files to match the online ones
[21:22] <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:23] <abentley> Is it the online one?
[21:23] <oly> yes
[21:24] <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:26] <oly> lol, im confused now
[21:27] <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:28] <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:29] <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:30] <oly> okay so its reverting to the latest online branch
[21:30] <oly> that makes more sense, thanks for clarifying that
[21:33] <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:35] <oly> okay,
[23:08] <lelit> yay! http://pastebin.com/d263128ed
[23:38] <Pieter> bzr log --line only show commits on the mainline?
[23:42] <beuno> Pieter, yeap
[23:46] <Pieter> ah, that's unexpected.. I'd thought it would just display each commit on a line