[08:31] <mgz> morning
[14:13] <BasicOSX> Is the bzr dev branch still at http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev? I've been at revision 6524 for what seems like months
[14:27] <mgz> BasicOSX: yup, a few things want mergin up from earlier series though
[14:28] <jml> jelmer: oh right, so, bzr-stats
[14:28] <jml> jelmer: I find myself working on similar stuff from time to time and am thinking of merging my similar stuff into it
[14:28] <jml> jelmer: but I don't think I understand the code in bzr-stats very well.
[14:31] <abentley> jelmer: I'd like to introduce my team-mates to native colocated branches.  Are there any docs?
[14:32] <jml> there are no docs, there is only pain.
[14:33] <abentley> jml: Is that specifically about colocated branches?
[14:34] <jelmer> jml: okay
[14:34] <jml> abentley: yes. I don't know of any docs.
[14:34] <jelmer> jml: Contributions are welcome, I can also give you pointers if that would help.
[14:34] <jelmer> abentley: I don't think they're ready for production use either yet; the API side is there, and some bits of the UI
[14:34] <jml> abentley: and while I really like using them, they are buggy enough that I personally wouldn't recommend them strongly to another team mate.
[14:34] <jml> jelmer: what's all this 'classify' stuff about?
[14:35] <mgz> misspelling of the day: Ununtu
[14:35] <jelmer> jml: In what way are they buggy? I would rather say they're unpolished
[14:35] <jelmer> jml: It classifies files as documentation, code, translations, etc
[14:35] <jml> jelmer: yeah, unpolished is better.
[14:36] <jelmer> jml: It's used for the About dialog in bzr-gtk to give people proper credit
[14:36] <jelmer> jml: See "bzr credits"
[14:36] <abentley> jelmer: the main pain point for me is the lack of config support.  I want a way to map file://foo,branch=$BAR to lp:~abentley/project/$bar.
[14:37] <jml> jelmer: ah ok.
[14:38] <jml> jelmer: how does the collapsing work? I sort of understand collapse_by_person, but I don't think I get collapse_email_and_users. Should they be used in conjunction?
[14:39] <jelmer> jml: I'm not sure, I think that was originally jam's code
[14:39] <jml> jelmer: my motivating use cases are getting things like number of mainline commits by person since a date, or finding out how many lines of code have been added / removed per person. duplicate records are a pain there.
[14:39]  * jelmer looks
[14:39] <jelmer> jml: IIRC it groups by both fullname and email
[14:41] <jml> jelmer: e.g. http://paste.ubuntu.com/1039164/ and the awful code in utilities/community-contributions.py in Launchpad.
[14:41] <jelmer> jml: ah, I see
[14:42] <jam> jml: the issue is that people often don't use the same user information over time. Especially in early bzr, and for people working on many different machines. So we try to figure out that john@arbash-meinel.com is the same as john@canonical.com or whatever. But also user's don't spell their name 100% the same, etc.
[14:42] <jelmer> jml: I think the collapse code could definitely be useful there
[14:42] <jam> like the jelmer in your example
[14:42] <jml> jam: right, I think I understand the issue
[14:42] <jelmer> maybe it would be worth putting into bzr core?
[14:42] <jelmer> I think it already has a fair amount of tests
[14:43] <jml> jam: but not how to go from "I have a list of usernames please make me something that maps them to a best guess of a list of people"
[14:43] <jam> jml: well bzr-stats was my attempt at it, but I wrote that code ~5 years ago. So I haven't been thinking about it as much recently.
[14:43] <jml> jam: heh, understood.
[14:43] <jam> I know empty strings were a problem, as it ended up linking everything to me
[14:44] <jam> since somewhere I committed with only an email address, or something like that.
[14:44] <jam> Probably doing it as a 'these are some known mappings, try to find more' might be an interesting way to do it.
[14:44] <jelmer> jam: I vaguely recall that was fixed since
[14:44] <jam> jelmer: it was, hence *were* a problem.
[14:44] <jam> I'm not sure if there were other edge cases that linked too much.
[14:45] <jelmer> jam: sorry, English reading fail
[14:45] <jam> but the "map username to all known email addresses" and "map email addresses to all known usernames", and then you can iterate that cycle until it converges.
[14:45] <jam> jml: ^^
[14:45] <jml> jam: thanks.
[14:46] <jml> the other thing I want to do a lot is work around PQM claiming to own the merge commit
[14:46] <jml> which is accurately done by assembling all of the authors of all the merged revisions
[14:46] <jam> jml: you can argue that the merge commit isn't significant, vs the actual commits, so just ignore the PQM done.
[14:47] <jam> jml: how do you get negative numbers in your list?
[14:47] <jam> or is that LoC ?
[14:47] <jml> jam: not if one of your metrics is 'how many changes landed on trunk' or if you want to answer 'what trunk changes have I landed since January'
[14:47] <jml> jam: net LoC. Lines added - lines removed.
[14:47] <jam> jml: sure, but then you should be ignoring all the individual commits, I think.
[14:47] <jml> jam: it's motivated by the LP LoC-neutral change policy.
[14:48] <jml> jam: I don't understand. How do you get "what trunk changes have I landed since January" without looking at individual commits in a PQM-managed branch?
[14:50] <jam> jml: so if the revision is in the history, it has landed on trunk, right?
[14:50] <jml> jam: I guess.
[14:51] <jam> so if you want to split out "how many commits" from "how many features/branches have landed".
[14:51] <jam> Then you probably want to go to each rev, and look at just the merged revisions. And attribute that to the individual authors (each gets +1 per pqm commit)
[14:51] <jam> merge_sort is your friend there
[14:52] <jam> while not mainline: authors.add(rev.authors)
[14:53] <jml> ok. that makes sense.
[15:08] <jam> jml: you're more than welcome to expand bzr-stats if it is doing what you want, and you are also welcome to propose merging it into bzr core (I think). It seems a bit waffley about accuracy of stats, which is why I would tend to put it in a plugin, but there has certainly been a move to put more in core.
[15:08] <jam> anyway, EOD here, you can always email if you want more info
[15:10] <jml> jam: thanks
[16:12] <tedg> It was suggested that I look at Bazaar Keywords plugin: http://wiki.bazaar.canonical.com/KeywordExpansion
[16:12] <tedg> But that seems kinda dead
[16:12] <tedg> Is that part of the main Bazaar now or was it considered not a good idea?
[16:18] <mgz> tedg: generally, there are nicer ways of doing what that kind of thing was used for in cvs/svn
[16:18] <mgz> invoking bzr in your build script to get version and so on.
[16:19] <tedg> The problem is I don't have a build script :-/  This is for getting a juju charm to have the same revno as the Bazaar repo it's in.
[16:19] <tedg> http://askubuntu.com/questions/149553/how-do-i-make-a-juju-charms-revision-match-the-bazaar-revision-of-its-repo
[16:20] <mgz> I did point hazmat at keywords for that kind of thing the other day
[16:21] <mgz> have you tried it and can't get it to work, or are just worried about it?
[16:22] <mgz> there may be juju-specific annoyances to work around, to do with how it deploys charms and what it installs on units
[16:24] <tedg> I haven't tried keywords, it doesn't seem to be in Ubuntu and has no releases... so that, in general, makes me uncomfortable :-)
[16:24] <tedg> Plus, I don't understand how things would work if someone didn't have the plugin.
[16:25] <tedg> It seems like I'd be making my repo "ted only"
[16:25] <tedg> So I was hoping the answer was "merged into mainline under a different name" :-)
[16:27] <mgz> well, I suspect it straight up won't work as juju wants to run from branch effectively, and doesn't install any bzr plugins
[16:27] <mgz> but having that and no way of pulling the revision from the charm is a little daft.
[16:29] <tedg> I honestly don't know why they have "revision" at all -- seems like it'd be better to always pull it from the VCS, what ever that may be.
[16:35] <jelmer> tedg: that doesn't necessarily work, since not all VCSes have sortable revision ids
[16:36] <tedg> jelmer, All the ones that I care about do ;-)
[16:37] <tedg> And, you *could* calculate it for others with some sort of plugin.  It'd be expensive, but eh.
[17:13] <Han> I just got an out of memory error while running "bzr branch bzr://bzr.savannah.gnu.org/emacs/emacs-24"
[17:14] <Han> This system has got 4Gb memory. What can I do to prevent that?
[17:29] <jelmer> Han: what version of bzr are you using?
[17:34] <Han> Bazaar (bzr) 2.4.2
[17:35] <Han> Hoi Jelmer. :-)
[17:36] <Han> It's a kind of a shame to download 120mb and to end up with nothing.
[17:59] <jelmer> I was wondering if it was /the/ Han :-) hi!
[17:59] <jelmer> 4Gb should be plenty; and AFAIK most of the memory improvements are already in 2.4
[18:00] <lifeless> Han: are you running 32-bit or 64-bit? If 32-bit, then individual processes cannot use all 4GB (not that we should need to in this case...)
[18:00] <Han> 64
[18:05] <Han> I'm going to try the same command with 2.5.1, see what happens.
[19:09] <jave> how can I revert all the changes to a file in a branch, so the file is same as upstream?
[20:15] <pikkachu> hi, I'm getting this error when I try to branch from launchpad: http://pastie.org/pastes/4082141/text
[20:16] <pikkachu> Bazaar 2.5.0, Python 2.7.3, Windows 7. Any help?
[20:17] <mgz> pikkachu: looks like you have ssh problems, try `ssh -vv yourlpusername@bazaar.launchpad.net`
[20:22] <pikkachu> mgz: I use PuTTY's plink (BZR_SSH=plink)
[20:24] <mgz> ah, in which case, manually run `plink you@bazaar.launchpad.net` and accept the fingerprint
[20:25] <jelmer> 'evening mgz, pikkachu
[20:25] <mgz> then try again (you have BZR_SSH set to the location of plink, right?)
[20:26] <pikkachu> good evening jelmer
[20:27] <pikkachu> mgz, I have the impression it was working before, and that in my old windows I didn't need to do that :(
[20:29] <mgz> ..just try it? I bet plink will complain about the fingerprint
[20:33] <pikkachu> thank you mgz, it worked!
[20:33] <pikkachu> not sure why it used to work before, but it's gone now
[20:37] <mgz> presumably putty learnt it before but then forgot it again recently
[20:38] <mgz> or you're being MITMed
[20:40] <pikkachu> maybe in older versions of bzr/putty, it used to ask to add the server right there in $bzr branch
[20:43] <mgz> nope, that never worked unfortunately
[20:47] <pikkachu> hmm, then it seems my feeling I could branch before is just wrong, and I just had added the host manually before in my old windows with plink/whatever but can't recall
[20:47]  * pikkachu searches for excuses to not think he's being mitmed
[20:49] <mgz> well, I can see what the fingerprint I have, then you can compare with what you got for bazaar.launchpad.net
[20:52] <mgz> $ ssh-keyscan bazaar.launchpad.net>/tmp/key && ssh-keygen -lf /tmp/key
[20:52] <mgz> # bazaar.launchpad.net SSH-2.0-Twisted
[20:52] <mgz> 1024 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89 bazaar.launchpad.net (RSA)
[20:52] <mgz> you had:
[20:52] <mgz> ssh-rsa 1024 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89
[20:52] <mgz> so you're fine :D
[20:58] <pikkachu> :)
[21:48] <pikkachu> thanks all
[22:33] <deepa> Hi, how does partial trees work?
[22:34] <deepa> does it differ to partial checkouts in some interesting ways that miht make me not want to use it?