[00:00] <Odd_Bloke> LeoNerd: I'm going to bed now, if you want to discuss this in more detail, drop me an email at D.M.Watkins@warwick.ac.uk (or email the list). :)
[00:00] <Odd_Bloke> Night all!
[00:05] <mwhudson_> damn people in london and their sleeping habits
[00:25] <dash> Hi. someone remind me how to roll a working copy back to a previous revision? I seem to have svn brain today, I expected 'bzr up -r ...' to do it :)
[00:25] <LeoNerd> bzr revert -r ...
[00:25] <dash> hah, ok
[00:26] <LeoNerd> You're thinking in CVS-mode :)
[06:53] <alwyn> Hi everyone
[06:54] <alwyn> Anyone have success using bzr-svn against a svn repository with authentication?  The passwords are cached by my subversion client, but no joy on both gentoo and mac os x...
[07:44]  * mwhudson_ has been amusing himself this evening: http://people.ubuntu.com/~mwh/really_hacked_up_changelog_view.png 
[08:37] <asabil> anyone knows if there is a way to have bzr behave in a similar way to git ? concerning branches and repositories ?
[08:37] <asabil> I mean 1 folder contains many branches
[08:37] <Peng> Not yet.
[08:37] <Peng> Maybe in the future.
[08:47] <asabil> ans is there a way to rewrite the history ?
[08:52] <luks> rewrite in what way?
[08:53] <igc> morning
[08:53] <asabil> luks: change the commit log
[08:54] <asabil> or change the committed files
[08:54] <luks> uncommit + commit?
[08:57] <asabil> luks: something like : http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html
[08:58] <asabil> luks: maybe you would want to take a look at this: http://blogs.gnome.org/newren/2008/03/01/happenings-in-the-vcs-world/
[08:58] <asabil> it is quite biased toward git, but still contains interesting ideas and complains about bzr
[08:58] <luks> umm, I think I really don't want to :)
[08:59] <luks> no, bzr doesn't have anything like git-filter-branch, but I think that's good, not bad
[08:59] <asabil> luks: that's exactly his complain: the bzr devs don't want to listen:p
[08:59] <luks> I'm not a bzr dev, btw
[09:00] <luks> but I wouldn't listen anyway :)
[09:00] <asabil> luks: and honestly git-filter-branch can be really useful
[09:00] <luks> how so?
[09:00] <luks> isn't VCS about keeping your history?
[09:00] <luks> I can understand it's use for migrating or restructuring branches
[09:01] <luks> but not to change commit message or things like you mentioned
[09:01] <asabil> yes, but let me give you some use cases
[09:01] <asabil> let's say I work for a company A, that uses bzr
[09:01] <fullermd> There are many very good reasons to want to wipe out history   :)
[09:02] <asabil> I worked for a long time on a proprietay project for them , and some day they decided it should go open source
[09:02] <asabil> however, there are some files early in the history of the bzr branch, that are confidential
[09:02] <asabil> I still want to pusblish the whole branch with its history
[09:02] <asabil> how do I do ?
[09:02] <luks> yes, that's one valid use case
[09:03] <luks> but the first two you mentioned were not
[09:03] <asabil> which ones ?
 luks: change the commit log
 or change the committed files
[09:03] <asabil> luks: sometimes there are typos in the commit log
[09:04] <luks> typo in the commit message is IMO part of the history and should stay there
[09:04] <asabil> and sometimes there is a morron in your project who would put crappy commit logs
[09:04] <luks> otherwise you break the branch for everybody else
[09:04] <asabil> and you want to fix that
[09:04] <luks> it's part of the history, don't change the history :)
[09:05] <fullermd> Down, boy!  Keep your dogma on its leash!
[09:05] <asabil> :)
[09:06] <luks> I guess I just don't like git too much, so I'm not the right person do discuss this :)
[09:06] <asabil> luks: I don't like git at all, and for good reasons
[09:06] <fullermd> In a lot of cases, breaking the branch is totally acceptable.  In a lot of cases, I know exactly where every copy of the branch is, so remaking them all is a bloody inconvenience, but entirely possible.
[09:06] <asabil> but many people like git, and if you really like bzr, you should listen to their critics and improve
[09:07] <luks> I'm not saying filtering shouldn't be possible
[09:07] <luks> but in git it' a common operation
[09:07] <luks> *it's
[09:08] <luks> btw, I don't like bzr either :)
[09:08] <asabil> ...
[09:08] <luks> but it's the only acceptable one
[09:08] <asabil> I think there are many things to improve in bzr, maybe also change its name
[09:09] <fullermd> "All mail clients suck.  This one just sucks less."
[09:09] <asabil> many people still confuse bzr with bazaar
[09:10] <Odd_Bloke> asabil: That's going to be fixed soon.
[09:11] <asabil> oh really ?
[09:11] <Odd_Bloke> The Debian 'bazaar' package will install both bzr and baz.
[09:11] <Odd_Bloke> And eventually just bzr.
[09:11] <asabil> that would be better
[09:11] <Peng> Typos are one thing, but sometimes I really do want to change the commit message when it's wrong.
[09:12] <johnny> version the changelogs lol
[09:12] <johnny> err commit messages
[09:13] <Peng> That could work.
[09:13] <Odd_Bloke> johnny: The commit messages _are_ versioned, with the content of the trees.
[09:13] <Peng> It would, of course, be too complicated, but would be useful.
[09:14] <johnny> i mean seperately Odd_Bloke
[09:14] <johnny> but i personally don't need such a thing..
[09:14] <johnny> you could find a way to replay the history tho
[09:14] <luks> Peng: then uncommit it and commit again
[09:15] <luks> if you notice it later and the branch is already published, rewriting is IMO the wrong thing to do
[09:16] <Verterok> morning
[09:18] <asabil> I still think that rewriting the history and filtering a branch can be a really neat fature for bzr
[09:18] <asabil> also bzr could improve its handling of Limbo files
[09:18] <asabil> maybe by adopting an interactive ui like darcs
[09:19] <asabil> or having an ibzr command that is fully interactive
[09:34] <Peng> luks: The only time I can remember it bothering me was with a personal, non-code branch that isn't published. There had also been commits since it.
[09:44] <LarstiQ> asabil: handling of Limbo files?
[09:46] <asabil> LarstiQ: unknown files
[09:47] <asabil> LarstiQ: you know the "Oh sh*t i forgot to add those files before committing"
[09:49] <LarstiQ> asabil: ah. You confused me since limbo has a specific meaning in bzr, and I have never heard of this use before.\
[09:49] <LarstiQ> jam: are you running bzr serve or somesuch?
[09:50] <dato> LarstiQ: http://blogs.gnome.org/newren/2007/12/08/limbo-why-users-are-more-error-prone-with-git-than-other-vcses/, presumably
[09:51] <Odd_Bloke> asabil: There's 'bzr shell', in bzrtools I think.
[09:51] <jam> LarstiQ: I am now :)
[09:51] <asabil> Odd_Bloke: and ?
[09:52] <asabil> Odd_Bloke: ever used darcs ?
[09:52] <LarstiQ> asabil: maybe you are looking for commit --strict?
[09:53] <asabil> LarstiQ: rather something like darcs record
[09:53] <Odd_Bloke> asabil: 'bzr shell' is similar to an interactive bzr command, but I should have read more context.
[09:54] <Odd_Bloke> asabil: Didn't you write the 'record' plugin?
[09:54] <asabil> Odd_Bloke: yes, the record plugin should be renamed btw into bzr make-patch
[09:54] <asabil> or something like that
[09:54] <Odd_Bloke> asabil: Ah, yes, I recall now.
[09:54] <asabil> I wanted it to become like darcs record, but never had time to finish it
[09:55]  * LarstiQ is a bit low on cycles
[09:55] <Odd_Bloke> I'd have thought it would be fairly trivial to switch from creating a patch to creating a commit.
[09:55] <LarstiQ> asabil: I don't know darcs well, what about record is it that you are looking for?
[09:55]  * Odd_Bloke doesn't have any motivation to do it himself, because he wouldn't ever use it.
[09:55] <Odd_Bloke> I'd be happy to help someone who does have some motivation though.
[09:58] <asabil> LarstiQ: basically darcs is fully interactive, so when you issue a darcs record (the commit equivalent), it will prompt you about the hunks to record
[09:59] <asabil> (in a similar manner to bzr shelve), then it will ask you for a record name (commit message), before finishing the record
[09:59] <asabil> iirc it will also warn you about unknown files
[09:59] <LarstiQ> asabil: right, which --strict will also do
[10:00] <asabil> LarstiQ: --strict is interactive ?
[10:00] <LarstiQ> asabil: no
[10:00] <asabil> Odd_Bloke: maybe can we cook up something together ?
[10:00] <asabil> Odd_Bloke: I want to make the record plugin add a --interactive command to commit
[10:01]  * LarstiQ doesn't think interactivity is desirable in the general case, so if there are useful features of record that can also work non-interactive, that would be nice to factor out
[10:01] <asabil> s/command/option/
[10:01] <LarstiQ> or rephrased, not only the interactive users should benefit
[10:02] <asabil> make the interactive users benefit until you find a way to make the non interactive users benefit as well
[10:02] <LarstiQ> fair enough :)
[10:02] <jelmer> dudes!
[10:02] <LarstiQ> jelmer!
[10:02] <jelmer> how is the sprint today?
[10:03] <LarstiQ> jelmer: they just did a firealarm test
[10:03] <LarstiQ> but announced it so we could just sit and not do the entire evac thing
[10:04] <Odd_Bloke> asabil: There was someone in here last night who was also interested in that exact thing.
[10:05] <Odd_Bloke> It was, in fact, LeoNerd (implicit ping). :)
[10:14] <jelmer> LarstiQ: ah, that's nice for a change
[10:15] <vila> yeah, there were nice enough when I explained why *I* prefer it to be a lighter test...
[10:17] <LarstiQ> jelmer: do you have anything to say on file copies/path tokens?
[10:18] <jelmer> LarstiQ: I'm not sure I entirely remember how they were supposed to work
[10:18] <LarstiQ> ah :)
[10:19] <Odd_Bloke> jelmer: abentley and lifeless are probably about to have a discussion regarding file copies, hence the question. :)
[10:22] <spiv> Odd_Bloke: Any chance of you adding a "mirror-update" command to that plugin today? :)
[10:23] <jelmer> Odd_Bloke/LarstIq: The wiki page on path tokens doesn't appear to have any actual design details, just use cases :-(
[10:23] <Odd_Bloke> spiv: That's my next step. :D
[10:23] <LarstiQ> jelmer: rob's comment was that pathtokens may be a implementation strategy for filecopies, but they don't need to be the way to do it.
[10:24] <spiv> Odd_Bloke: I have a use-case of a sort
[10:24] <jelmer> LarstiQ: makes sense
[10:25] <Odd_Bloke> spiv: Cool.
[10:25] <spiv> Odd_Bloke: I have just made a "bzr svn-import" of Twisted's SVN on my laptop, and when I update it (by running bzr svn-import again in the same dir), I'd like a way to update the copy of the import I've put at http://people.ubuntu.com/~andrew/twisted/
[10:25] <spiv> Odd_Bloke: rsync works atm, but isn't exactly ideal...
[10:50] <asabil> Odd_Bloke: let's say I have a patch, how do I commit it (working on --interactive)
[10:50] <jelmer> too bad there's no video feeds
[10:50] <jelmer> but at least there is the BrainStorms page
[10:51] <Odd_Bloke> asabil: Well, apply it to the tree and then commit as normal, I guess.
[10:51] <LarstiQ> jelmer: we could do a conference call I suppose
[10:52] <asabil> oki
[10:52] <Odd_Bloke> spiv: I've just pushed an initial implementation of mirror-update to mirror.dev.
[10:53] <spiv> Odd_Bloke: thanks!
[10:58] <jelmer> LarstiQ: it's being discussed right now?
[10:59] <Odd_Bloke> jelmer: Nope, plugins ATM.
[11:00] <Odd_Bloke> spiv: So I'm finding some slightly odd behaviour in that the mirror-update command is pulling the revisions and the history into the branches appropriately but 'bzr log' complains about logging the null revision.
[11:00] <Odd_Bloke> 'bzr log -r1' shows the right thing, however.
[11:01] <spiv> Odd_Bloke: hmm, mirroring a rich-root-pack repo doesn't work
[11:01] <spiv> It creates pack-0.92 at the destination then barfs.
[11:02] <jelmer> hmm, is bundle-buggy down or just being slow
[11:03] <james_w> Odd_Bloke: are you using tree.pull() or branch.pull()
[11:03] <Odd_Bloke> I get "bzr: ERROR: Repository KnitPackRepository('file:///var/tmp/foo/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///var/tmp/blah/.bzr/repository/')" when doing that.
[11:03] <Odd_Bloke> spiv: ^
[11:03] <Odd_Bloke> james_w: branch.pull()
[11:03] <spiv> Odd_Bloke: right.
[11:03] <james_w> Odd_Bloke: you want tree.pull() anyway.
[11:03] <Odd_Bloke> jelmer: abentley was using it earlier, but I don't know about ATM.
[11:04] <Odd_Bloke> james_w: How's that going to cope with branches without trees, which is probably what we want from this (as the eventual use-case is switching into the mirrored branches)?
[11:05] <james_w> Odd_Bloke: well, use open_tree_or_branch() and then you know whether there is a tree there already, and then switch between tree.pull() and branch.pull()
[11:06] <james_w> Odd_Bloke: and I guess you have to solve that branch.pull() problem.
[11:06] <james_w> I can show you some code that does the former if you like.
[11:06] <Odd_Bloke> james_w: Sure, please. :)
[11:06] <Odd_Bloke> jelmer: BundleBuggy WFM ATM TLA.
[11:07] <jelmer> Odd_Bloke: hmm, looks like it's just being very slow to me
[11:08] <Odd_Bloke> spiv: Yeah, it'll be fun. :p
[11:11] <jelmer> Peng: Do you have pqm access or should I submit the branch for "http://bundlebuggy.aaronbentley.com/request/%3C47C5D9C0.5080702@mattnordhoff.com%3E" ?
[11:13] <jamesh> jelmer: the debian/watch files for bzr-email and bzr-pqm in Debian seem to be pointing at the wrong LP pages
[11:13] <jamesh> according to http://qa.debian.org/developer.php?login=pkg-bazaar-maint@lists.alioth.debian.org
[11:14] <jelmer> jamesh: as far as I know there is no watch file for bzr-email and bzr-pqm
[11:15] <jamesh> jelmer: maybe that site creates automatic watches then.  My mistake :)
[11:16] <jelmer> jamesh: I wonder how though
[11:17] <jelmer> since it seems to be using launchpad urls
[11:17] <dato> igc: ayt?
[11:17] <LarstiQ> heya dato
[11:17] <dato> hey LarstiQ
[11:18] <jamesh> jelmer: the home page from the package metadata
[11:20] <ubotu> New bug: #199440 in bzr "Traceback if authentication.conf contains section without password " [Undecided,New] https://launchpad.net/bugs/199440
[11:22] <igc> hi dato
[11:22] <jelmer> jamesh: and it then makes assumptions about the releases being on launchpad as well?
[11:22] <igc> dato: spoke to abentley re the best way to do fast-export ...
[11:22] <dato> aha
[11:22] <igc> two revision-trees and changes_from is fine
[11:23] <igc> abentley also mentioned iter_changes
[11:23] <igc> and had some idea down the track
[11:24] <dato> I saw iter_changes, but only as a _underscore_method, so I went with public stuff
[11:25] <abentley> changes_from is a bit ugly and lossy.
[11:25] <igc> s/idea/ideas/
[11:25] <igc> re more efficient ways
[11:25] <igc> I imagine that two rev-trees + changes_from is fast enough for any projects though ...
[11:25] <igc> so we ought to stick with that initially I feel
[11:25] <igc> s/any/many/
[11:25] <dato> abentley: lossy?
[11:25] <LarstiQ> Odd_Bloke: one of the log messages of bisect we looked at mentioned working with merged revisions, what was that about then?
[11:26] <ubotu> New bug: #199442 in bzr "every command twice encode sys.stdout?" [Undecided,New] https://launchpad.net/bugs/199442
[11:26] <Odd_Bloke> LarstiQ: I dunno, I thought it coped with them too.
[11:26] <Odd_Bloke> I may have screwed the test up. ^_^
[11:26] <dato> igc: now, I have bzr-crude-export.py in a state that does everything I'd need, so I'm not sure how much more time I'd like to put into it. otoh, I'd like to release it. so, how about I drop a mail about it in bazaar@ and git@, and mention that it'll probably need a new home in the future, possibly bzr-fastimport?
[11:27] <abentley> dato: There are some combinations with kind changes that aren't recorded properly by changes_from.
[11:27] <dato> abentley: ok. my script doesn't look at kind_changes atm, so...
[11:28] <igc> dato: I definitely want it in fastimport and I'm happy to own it
[11:29] <dato> abentley: btw kind_changed seems missing in TreeDelta's __doc__
[11:30] <Odd_Bloke> spiv: I'm not going to work that mirror bug out now, as I think the git-style branches discussion will have some bearing on it.
[11:30] <dato> igc: ok. shall I keep calling it -crude, or would be -fast ok with you? I'll mention in __doc__ that later on it'll live in launchpad.net/bzr-fastimport
[11:32] <igc> dato: fast is ok. If you send me the code or link, I'll include it real soon now
[11:32] <igc> bbiab
[11:33] <asabil> Odd_Bloke: ok, done I will publish my interactive commit crack
[11:34] <Odd_Bloke> asabil: Cool. :)
[11:35] <asabil> Odd_Bloke: any name to suggest ?
[11:35] <asabil> bzr_interactive ?
[11:36] <Odd_Bloke> asabil: interactive-commit, or somesuch.
[11:36] <asabil> Odd_Bloke: it also contains a record-patch command
[11:36] <Odd_Bloke> asabil: I dunno then.
[11:36] <Odd_Bloke> It can always be changed later. :p
[11:44] <asabil> abentley: what do you think about adding the record-patch command to bzrtools ?
[11:45] <beuno> LarstiQ, *ahem*debconf*ahem*
[11:47] <abentley> I'm not keen on making it easy for people to do partial commits.
[11:53] <LeoNerd> It's already easy... bzr ci some files here
[11:53] <LeoNerd> The hunk selection only extends a bit further, to do changes -within- files.. It's really no worse in principle
[11:54] <LeoNerd> It just depends on the (fairly-arbitrary) way that the user has split their content across files
[11:57] <abentley> LeoNerd: Different-in-degree is good enough for me.
[11:59] <asabil> abentley: oO record-patch is about creating patches manageable with quilt
[12:02] <LarstiQ> beuno: yes, thank you :)
[12:12] <abentley> asabil: You should really look into looms, then.
[12:13] <abentley> That should be a much more reliable way of generating quilt-compatible patches.
[12:14] <dato> igc: ok, I CCed you. I'm sorry is a git repo, but feel free to use git-fast-export! :-P
[12:14] <asabil> oh, oki didn't know aboutit
[12:14] <asabil> thanks
[12:20] <spiv> Odd_Bloke: makes sense
[12:21] <Odd_Bloke> spiv: That's what I thought.  However, it seems like the discussion may not happen after all...
[12:23] <spiv> Odd_Bloke: we'll see...
[12:23] <Odd_Bloke> *ominous music*
[12:43] <jml> how do I list all commands provided by a plug in?
[12:47] <spiv> jml: "bzr help commands | grep PLUGIN-NAME
[12:47] <beuno> jml, or use lifeless' plugin-info plugin: https://launchpad.net/bzr-plugin-info
[12:48] <jml> spiv: doesn't work
[12:48] <jml> <-- still not stupid
[12:48] <Odd_Bloke> abentley: http://pastebin.slackadelic.com/426 is a patch that removes a couple of Python-2.5isms from your LP directory service patch.
[12:48] <jml> spiv: because help wraps
[12:52] <abentley> Odd_Bloke: tx
[12:52] <Odd_Bloke> abentley: NP.
[12:56] <spiv> jml: "grep -1 PLUGIN_NAME" ;)
[12:57] <jml> spiv: wrath
[12:59] <jml> spiv: and violence.
[13:08] <LarstiQ> jml: :)
[13:12] <jml> spiv: (it doesn't always wrap)
[13:56] <VSpike> i'm using bzr to control a web application.  My hosting co only gives me access to the webspace by ftp.  Can I use bzr to push changes up to the hosting space?
[13:57] <james_w> VSpike: yes. You can push over ftp.
[13:57] <VSpike> i tried "bzr init ftp://user:pass@hosting.com" but I get an error "File exists: '/.bzr': 550 /. bzr: access is denied"
[13:57] <james_w> VSpike: that doesn't look good.
[13:57] <VSpike> I'm using bzr 1.2.0 on Windows
[13:58] <james_w> VSpike: also, bzr will not create a working tree on the ftp server, so I don't think it will do what you want.
[13:59] <beuno> VSpike, and also, it will have the bzr repository online, making it easy to download the source
[13:59] <beuno> VSpike, we are working an a plugin to tackle the website-uploading workflow
[13:59] <beuno> so keep an eye out for it  ;)
[14:00] <VSpike> bueno the whole source is always in the webspace anyway, and I can specifically block access to .bzr
[14:02] <VSpike> Hmm I don't think even rsync can do ftp
[14:02] <VSpike> rats
[14:03] <beuno> VSpike, right, well, you still have the working tree issue, which is the actualy files
[14:03] <beuno> but, again, a solution to that is very close by
[14:03] <beuno> just not today
[14:04] <VSpike> I'm not sure i understand the working tree issue?
[14:04] <beuno> VSpike, the working tree is the actual files
[14:04] <hmeland> The "bzr push" will only push the repository part, i.e. stuff under ".bzr".
[14:04] <beuno> so when you push, you just send the repository files, which are the ones under .bzr
[14:05] <VSpike> ah right
[14:05] <beuno> VSpike, so you would need ssh access on the other end to do this now
[14:05] <beuno> (if you're willing to block the .bzr directory via htaccess or something)
[14:06] <VSpike> Understood
[14:06] <VSpike> Timestamps never seem to match either so probably the easiest/safest thing to do it use a sledgehammer and just write a script to ftp everything up
[14:07] <beuno> VSpike, right, at the moment
[14:07] <VSpike> okay.  thanks!
[14:07] <hmeland> Any ftp mirroring tool should be able to do the job.
[14:07] <beuno> (I'm personally doing php magic to do it on top of bzr, but that's not available yet either :p)
[14:07] <awilkins> Is this stuff convered in the FAQ? Because it's sure as heck a FAQ in here.
[14:08] <awilkins> Oh, and while we're talking about timestamps, was it a conscious design decision for timestamps in working trees not to match the timestamp of the files last revision?
[14:09] <beuno> awilkins, we're aiming at solving the actual problem, so I suppose a FAQ wouldn't make any sense at the moment
[14:09] <hmeland> I seem to recall there being a bug on the file-timestamp issue; don't know the status, though.
[14:10] <LarstiQ> awilkins: What are they instead and what case are you thinking of?
[14:10] <awilkins> I find the timestamp thing annoying because my tree compare tool is time sensitive
[14:10] <awilkins> LarstiQ: The timestamps are "time of writing to disk" from the build phase
[14:10] <LarstiQ> awilkins: ah right, so clean checkout you mean.
[14:11] <awilkins> LarstiQ: Yup
[14:11] <LarstiQ> awilkins: Doesn't sound like a desing decision, but rather a bug I think.
[14:11] <awilkins> It feels like a bug to me :-)
[14:11] <awilkins> ALthough AFAIR it's optional behaviour in TSVN... I'll look at the settings dialogue
[14:11] <hmeland> Of course, in a distributed system, using the "commit time" for file timestamps could lead to clock skew related problems.
[14:12] <awilkins> Yech, there is that
[14:12] <awilkins> Ok, it's optional default to "off" in TSVN
[14:13] <awilkins> But I find myself comparing local file trees a lot more with bzr because branching is much more frequent
[14:14] <hmeland> Out of interest, which timestamp-sensitive tree compare tool are you using?
[14:14] <awilkins> Beyond Compare 2
[14:15] <LarstiQ> awilkins: any chance that could use bzrlib?
[14:15] <awilkins> It has a rules-based compare as well, which gives more accurate results, but it still marks the "newer" file if they are different
[14:15] <lifeless> awilkins: timestamps are not set to time of last revision deliberately
[14:15] <lifeless> awilkins: /away
[14:16] <awilkins> Would you be against an option to do so?
[14:16] <lifeless> awilkins: without a good reason, yes. :). We do have an open bug that the times should all be identical
[14:18] <awilkins> Is this because it's expensive to determine the last revision of individual files?
[14:19] <awilkins> Oh, anyone who does BzrGtk here?
[14:19] <hmeland> I've never used "Beyond Compare", but according to http://diablopup.blogspot.com/2007/07/product-recommendation-beyond-compare.html it would seem that it has an "ignore timestamp differences" option?
[14:19] <beuno> awilkins, jelmer and phanatic
[14:20] <phanatic> what did i wrong this time? :)
[14:20] <beuno> phanatic, bzr-gtk, apparently  :p
[14:21] <awilkins> phanatic: Nothing, I just have a suggestion to make tool shelling a bit more flexible ; I'm currently operating with a very crude custom hack so I can use my 3-way merger of choice
[14:22] <awilkins> Using subprocess with a list of args isn't compatible because it uses an arg format that isn't MFC flavoured
[14:22] <awilkins> I've just hacked in a custom line for the tool I'm using using a % format string, but that obviously isn't portable to anyone else
[14:24] <awilkins> hmeland: Thanks for that, it's nice to learn new things about your favourite tools (even thought they are blindingly obvious)
[14:24] <hmeland> awilkins: No problem, glad to help :-)
[14:26] <awilkins> I just wish it did 3-way merge (have to wait for v3 to do that....)
[14:41] <lifeless> awilkins: several reasons.
[14:42] <lifeless> awilkins: one is that different machines have datestamp skew
[14:42] <lifeless> awilkins: another is that datestamp of commit is not sufficient to ensure correctness for build systems it in fact makes things worse than what we do today)
[14:42] <awilkins> Yes, I can see that too ; different platforms with different timezone behaviours too.
[14:43] <lifeless> awilkins: that too
[14:43]  * awilkins curses Win32 for having stupid TZ behaviour and has for many years
[14:44] <awilkins> Do the dates in bzr try to be UTC internally, btw?
[14:46] <luks> awilkins: they are in local time + timezone
[14:46] <lifeless> Ng: want to stab loggerhead btw?
[14:46] <Ng> lifeless: sure
[14:47] <lifeless> awilkins: anyhow, what would settingthe datestamp for you buy you?
[14:47] <Ng> lifeless: done
[14:47] <awilkins> lifeless: the red "newer" highlights in my compare tool would be on the right side
[14:59] <lifeless> awilkins: ah; so the tool is broken ? :>
[14:59] <LarstiQ> well, if it's just a general tree compare tool, where else would it get the information from?
[14:59] <lifeless> LarstiQ: newer from datestamps is inherently meangingless in the presence of diff & patch
[15:00] <lifeless> awilkins: a plugin to 'reset' a tree timestamp state should be easy enough to write
[15:00] <awilkins> lifeless: I thought the same myself
[15:01] <awilkins> lifeless: "newer" has value if you are (e.g.) uploading content to an FTP with limited bandwidth and youre target FTP server does not support CRC
[15:06] <ubotu> New bug: #103199 in bzr-gtk "diff window should not block typing in gcommit" [Medium,Fix released] https://launchpad.net/bugs/103199
[15:18] <Odd_Bloke> igc: I'm pretty happy with the 'mirror' command available at https://code.edge.launchpad.net/~daniel-thewatkins/bzr-mirror/mirror.dev .  If you want to have a play around with it and give me some feedback, that'd be good. :)
[15:36] <ubotu> New bug: #118461 in bzr-gtk "symlinks not handled correctly" [Low,Confirmed] https://launchpad.net/bugs/118461
[15:36] <ubotu> New bug: #120524 in bzr-gtk "Fold arrow in commit dialog serves no purpose" [Low,Fix released] https://launchpad.net/bugs/120524
[15:42] <ubotu> New bug: #120526 in bzr-gtk "Not possible to specify an external diff viewer to use" [Low,Confirmed] https://launchpad.net/bugs/120526
[16:28] <beuno> Verterok, https://bugs.launchpad.net/bzr/+bug/86652
[16:28] <ubotu> Launchpad bug 86652 in bzr "commit option to set revision properties" [Undecided,New]
[16:29] <beuno> would your patch fix that?
[16:36] <jelmer> Peng: ping
[16:38] <jelmer> beuno: No, that only supports registering custom revision property displayers if we're talking about the same patch
[16:38] <Verterok> beuno: nope, I'm working on showing the properties
[16:38] <beuno> jelmer, right, but that would be a start, wouldn't it?
[16:38] <Verterok> jelmer: thanks ;)
[16:39]  * beuno pokes ponders asigning the bug to Verterok
[16:40]  * Verterok hides, and run away :)
[16:40]  * beuno stops bug triaging and goes back to coding
[16:41] <Verterok> beuno: but I can put some time in adding the option, but I need someone to review my code
[16:41] <ubotu> New bug: #131471 in bzr-gtk "bzr gconflicts outputs error messages when pushing green button and no files are in conflict" [Low,Fix committed] https://launchpad.net/bugs/131471
[16:41] <ubotu> New bug: #199513 in olive "gcommit crashes: ERROR: dbus.exceptions.DBusException" [Undecided,New] https://launchpad.net/bugs/199513
[16:41] <beuno> Verterok, right, just kidding (not really)
[16:42] <jelmer> beuno: I actually think #86652 would be a bad idea
[16:42] <jelmer> beuno: I've just commented
[16:42] <Verterok> ok
[16:46] <ubotu> New bug: #147011 in bzr-gtk "[viz] date format is too verbose" [Wishlist,Fix released] https://launchpad.net/bugs/147011
[16:53] <fredreichbier> hello
[16:54] <phanatic> squashing bugs is fun
[16:55] <fredreichbier> i have a problem: i and another developer use launchpad+bazaar for the code. now he did some changes and pushed them as revision 11. i did some changes, too, and so i committed by own changes in my own branch and then merged his and my changes together. but after pushing it to launchpad, his revision disappears and is replaced by my revision. what's wrong? :)
[16:56] <LarstiQ> fredreichbier: It didn't disappear but is merged in, have a lookg at bzr log, it should show his commit indented
[16:57] <fredreichbier> right, but it disappeared in launchpad
[16:58] <beuno> fredreichbier, well, launchpad doesn't show sub-revisions
[16:58] <beuno> you will probably see it with "code browse"
[16:58] <beuno> jml, ^   :p
[16:58] <fredreichbier> ah
[16:59] <fredreichbier> ah yes in 'browse code' it's visible. thank you :)
[16:59] <beuno> fredreichbier, welcome
[17:07] <beuno> jam, https://code.launchpad.net/landscape  == no code. I'm I looking in the wrong place?
[17:21] <ubotu> New bug: #199527 in bzr-gtk "viz tracebacks when refreshing on an uncommitted and recommitted branch" [Undecided,New] https://launchpad.net/bugs/199527
[17:23] <tro> how would i uninstall bzr 1.2 if i installed it from source (ie. python setup.py install) into the default directory?
[17:24] <Verterok> tro: in what OS?
[17:24] <tro> linux
[17:25] <Verterok> tro: as root?
[17:25] <tro> i have bzrlib in /usr/lib/python.2.5/site-packages
[17:25] <tro> ya
[17:25] <Verterok> rm bzrlib, and the bzr executable
[17:25] <Verterok> that's all
[17:25] <tro> o ok. thanks
[17:25] <phanatic> tro: manually remove the bzrlib directory there + bzr executable + bzr manpage -- that's pretty much all i guess
[17:25] <beuno> Odd_Bloke, would you take a look at: https://bugs.edge.launchpad.net/bzr/+bug/190512
[17:25] <Verterok> phanatic: thanks
[17:25] <ubotu> New bug: #199539 in bzr "plugins command crashes complaining about "verbose"" [Undecided,New] https://launchpad.net/bugs/199539
[17:25] <ubotu> Launchpad bug 190512 in bzr ""bzr: ERROR: No such file" on bzr push" [Undecided,New]
[17:25] <beuno> it might be realted to the bug you just posted
[17:26] <tro> man, you'd think setup.py would be able to record where it installed the files and have an "uninstall" command or something
[17:29] <Odd_Bloke> tro: That's what your package manager is for. :)
[17:30] <tro> Odd_Bloke: yeah, i guess. i wonder if checkinstall can handle setup.py installations
[17:31] <fredreichbier> tro: as far i know it can
[17:38] <awilkins> Anyone know if the capability for symlink on Vista (NTFS 6) has shown up in CPython?
[17:38] <Odd_Bloke> Verterok: beuno: ISTR https://bugs.edge.launchpad.net/bzr/+bug/199539 being something to do with xmloutput.  Am I just inventing that?
[17:38] <ubotu> Launchpad bug 199539 in bzr "plugins command crashes complaining about "verbose"" [Undecided,New]
[17:40] <beuno> Odd_Bloke, I'd like to go for the "inventing" bit, but I can change my mind if you point me to what makes you think that
[17:41] <Verterok> Odd_Bloke: thanks, the xmloutput it's fixed, maybe it's a old version?
[17:41]  * awilkins discovers that symlinks for Vista have not shown up yet
[18:12] <batoms> i had asked this a while back but is it possible with bazaar to branch from one remote tree to another remote tree without going through the local machine
[18:12] <batoms> e.g. can i branch from a launchpad tree to another launchpad tree without first downloading the first tree and reuploading it
[18:13] <awilkins> batoms: You could probably do it if you had ssh access to the target machine, but otherwise, no
[18:15] <awilkins> How does run the tests from inside a python console?
[18:15]  * awilkins is testing IronPython to see how lacking it is to run BZR
[18:15] <LarstiQ> awilkins: os.system('./bzr selftest')? ;)
[18:16] <LarstiQ> awilkins: I think we looked at IronPython yesterday and got a bit scared at the differences.
[18:16] <awilkins> Heh, I don't think the win32 "os" has system
[18:16] <LarstiQ> awilkins: you should be able to do the same thing as cmd_selftest from bzrlib/builtins to kick off the testsuite.
[18:16] <LarstiQ> awilkins: I'm rather sure it does.
[18:17] <awilkins> I tried import bzrlib
[18:17] <awilkins> then bzrlib.test_suite()
[18:17] <awilkins> Ran into an error :-
[18:17] <awilkins> Ah, I need to chdir to where bzr is
[18:18] <awilkins> LarstiQ: Maybe the IPY implementation of "os" has no .system() call.
[18:18] <LarstiQ> awilkins: from bzrlib.tests import selftest; selftest()
[18:18] <LarstiQ> awilkins: hmm, could be
[18:19] <awilkins> No module named fcntl
[18:19] <LarstiQ> http://www.codeplex.com/IronPython/Wiki/View.aspx?title=Differences&referringTitle=Home iir
[18:19] <LarstiQ> awilkins: oh bother
[18:19] <LarstiQ> awilkins: you have some work cut out for you
[18:19] <awilkins> I'm testing with IP 2.08 A which is a bit closer
[18:20] <awilkins> It's mostly idle interest and the promise of 1.8x performance (which is probably not true beacuse the performance critical stuff should be C)
[18:20]  * LarstiQ wasn't aware there was a 2.x line?
[18:20]  * awilkins didn't bother with the 1.1 line
[18:21] <awilkins> One problem is that it completly foobars most of your platform capability detection by reporting that sys.platform == 'cli'
[18:22] <awilkins> Most of your code uses osutils which could be patched, but most of the tests directly check sys.platform
[18:22] <awilkins> And of course, sys.platform is still 'cli' even when you run IPY on Mono/Linux
[18:23]  * awilkins has a bzr.iron branch with comments on each platform check.
[18:23] <LeoNerd> http://changelog.complete.org/posts/698-If-Version-Control-Systems-were-Airlines.html   <== Quite favourable to bzr, I think :)
[18:23] <awilkins> Heh, that's the third time I've seen that here today
[18:26] <awilkins> Heh, this first error is a problem with the CPython platform detection ; subprocess thinks it's running on something posix
[18:37] <awilkins> Where's the msvcrt module? Builtin?
[18:37] <fredreichbier> msvcrt is a builtin module
[18:38]  * awilkins has now discovered this
[18:38] <awilkins> Darn
[18:41] <lifeless> tchau, see you on the flipside
[19:02] <batoms> could anyone ssh to launchpad for me and branch a tree for me
[19:02] <batoms> my connection is too slow
[19:02] <batoms> i've been waiting on a branch for hours
[19:24] <phanatic> beuno: http://www.ubuntu.com/news/landscape
[19:45] <beuno> phanatic, yeah, but jam mentioned the client was open source
[19:45] <phanatic> beuno: it seem it's "just free"
[19:59] <phanatic> for my fellow "beer hackers": http://xkcd.com/323/
[20:01] <LarstiQ> Odd_Bloke: http://thedailywtf.com/Articles/SQL-Sentences.aspx
[20:06] <Odd_Bloke> LarstiQ: A true WTF.
[20:12] <Vantage> hi all, is bzr cvsps import working with bzr 1.1/1.2?
[20:13] <Vantage> i know it worked with 0.18 and broke with 0.96.  I'm just wondering what the current status is
[20:14]  * LarstiQ doesn't know, but it should obviously
[20:17] <Stavros1> hello
[20:18] <Stavros1> i would like a setup where i review changes made by people before committing to the master repo, how would i do that with bzr?
[20:20] <LarstiQ> Stavros1: you can do that in a multiple of ways. bzr.dev development does that with a combination of pqm and bundlebuggy
[20:20] <Stavros1> hmm, i don't know what any of those are
[20:20] <LarstiQ> :)
[20:21] <LarstiQ> Stavros1: bzr.dev can only be committed to by pqm, which is a bot that you send a merge requested, it merges your branch when it gets to it in it's queue and  enforces policy (in our case, it runs the testsuite)
[20:22] <LarstiQ> Stavros1: if it succeeds, it commits, otherwise, it rejects the merge
[20:22] <Stavros1> oh hey, that's great
[20:22] <Stavros1> does it notify you as well?
[20:22] <LarstiQ> Stavros1: bundlebuggy is a tool to help the review process, you send bundles to a mailing list, and it tracks if it's merged or not
[20:22] <LarstiQ> Stavros1: yes
[20:22] <Stavros1> awesome
[20:22] <LarstiQ> Stavros1: see http://bundlebuggy.aaronbentley.com/
[20:23] <Stavros1> hmm i just looked at that, but i don't know how i can roll stuff back if it doesn't pass the code review
[20:23] <Stavros1> (or something equivalent)
[20:23] <LarstiQ> Stavros1: roll stuff back?
[20:23] <Stavros1> roll the commit back, if it shouldn't be in the repo
[20:24] <Stavros1> i want to sort of check the commits to see if they should be committed to the main repo
[20:24] <Stavros1> like pqm, only manual
[20:24] <LarstiQ> Stavros1: that would be a classical gatekeeper workflow methinks
[20:24] <Stavros1> ah, i saw some info on that but i couldn't find the page now
[20:25] <Stavros1> oh found it, workflows
[20:25] <Stavros1> yes, that's it
[20:25] <Stavros1> i don't want to set up an entire system for that though, it's going to be just me and someone else at first
[20:26] <Stavros1> so what can i do? create a branch and always have them push there?
[20:26] <Stavros1> and rebranch if i don't want to include the commit?
[20:27] <LarstiQ> Stavros1: well, they can publish their own branch, and you then merge from it, review, accept/reject by committing or reverting
[20:27] <LarstiQ> Stavros1: or, get the other person to use `bzr send`
[20:28] <Stavros1> bzr send sounds nice
[20:28] <Stavros1> it sends me mail and then what do i do?
[20:29] <LarstiQ> Stavros1: you can read the diff and see if you want to have it, then bzr merge it
[20:29] <Vantage> how do you guys deal with having large quantities of binary files that are versioned (e.g. images and flash files for a website) along with your code.  These would make branches fairly large.  Is there a way to have make having multiple branches on a machine a little less disk space expensive?
[20:29] <LarstiQ> Stavros1: or merge it and then do some checks, you have options :)
[20:30] <LarstiQ> Vantage: yes
[20:30] <weigon> can you see in a bzr push which revno I got on the remote-tree ?
[20:30] <LarstiQ> Vantage: you can use a shared repository to share revisions between branches
[20:30] <LarstiQ> Vantage: and if it's about working trees, see link-tree from bzrtools
[20:30] <Vantage> LarstiQ:  and just use bzr switch to switch between them?
[20:31] <LarstiQ> Vantage: that's an option, yes
[20:31] <Vantage> LarstiQ: that was the one I thought of. Any other options?  I'm googling link-tree right now...
[20:32] <LarstiQ> Vantage: I don't know right now
[20:33]  * LarstiQ gets back to hacking for a while
[20:33] <Vantage> LarstiQ: ok, thanks.  When you said "an option" I thought you meant you knew of others :)
[20:40] <jelmer> Odd_Bloke: What exactly does "owner" on the brainstorm page mean?
[20:44] <Odd_Bloke> jelmer: Person in charge of making it happen, I guess.
[20:44] <Odd_Bloke> igc added it.
[20:45] <jelmer> ah, ok
[20:52] <LarstiQ> jelmer: xp style terminology I think
[20:55] <Stavros1> i have a server running linux, what are my options for a read-only bzr repo?
[20:56] <Odd_Bloke> Stavros1: HTTP. :)
[20:56] <Stavros1> Odd_Bloke: oh, with apache? does it also support auth?
[20:56] <jelmer> Odd_Bloke: and contributors? The people who contributed to the discussion @ the sprint or the people interested in contributing?
[20:56] <Odd_Bloke> Stavros1: I'm not sure about auth, I'm afraid.
[20:57] <Stavros1> does it use apache?
[20:57] <Odd_Bloke> jelmer: People who are anticipated to help out in the implementation (I guess).
[20:57] <Vantage> couldn't you just set permissions on the tree and use ssh?
[20:58] <Odd_Bloke> Stavros1: Posting to the ML or asking a question is probably the best thing to do, most of the Bazaar guys are heading to the pub right now (end of sprint :D).
[20:58] <james_w> jelmer: I think the "owner" is the person that you should talk to if you are interested in the feature. Contributors are those that are interested in it.
[20:58] <Stavros1> Odd_Bloke: ah :p
[20:58] <james_w> Though the owner are the ones that are probably going to drive it if it is going to happen.
[20:58] <Stavros1> Vantage: i probably could... i don't want to give people access to the machine, though
[20:59] <Vantage> Stavros1: you could put that copy on a separate machine (or virtual machine) and just push to it when you do releases
[21:00] <Stavros1> ah, i don't have another machine (even virtual) to spare...
[21:00] <Vantage> Stavros1: well they'll have to access somewhere ;)
[21:01] <Stavros1> they can access the server, just not all of it :P
[21:01] <Stavros1> i wonder if i can chroot it
[21:08] <Vantage> Stavros1: I remember something called scponly which might work
[21:08] <Stavros1> aha, i'll check it out, thanks
[21:08] <igc> jelmer: owner means "I'll guide/monitor this"
[21:08] <Vantage> Stavros1: you can also do lighter virtual servers with linux-vserver or openvz I believe.  They don't do hardware vm
[21:09] <jelmer> Odd_Bloke, james_w, igc: Thanks!
[21:09] <igc> jelmer: Contributor means "I'll  do the work if the owner doesn't" :-)
[21:09] <Stavros1> Vantage: well the apache solution sounds nice, do you have any info on that?
[21:09] <beuno> jelmer, so being the owner is where you want to be
[21:09] <Stavros1> or actually i can just use ftp on another branch, i guess
[21:09] <LarstiQ> beuno: unless you have zero contributors.
[21:10] <igc> s/if/IF/
[21:10] <beuno> LarstiQ, that just means you have to blog a lot
[21:10] <Vantage> Stavros1: well apache is just putting it up on a publically accessible webserver, not sure about authentication support for bzr with that though, probably...
[21:10] <Stavros1> Vantage: oh duh, you're right :/
[21:10] <Stavros1> bzr has http access...
[21:10] <Vantage> Stavros1: yup :)
[21:10] <Stavros1> so i can just point apache to the repo
[21:10] <Stavros1> well that's simple enough
[21:12] <Stavros1> actually i have trac with the bzr plugin, does that expose the functionality?
[21:12] <Stavros1> i mean the repo
[21:14] <Vantage> Stavros1: they can browse it, but I don't think they can branch from it (but I could be wrong)
[21:15] <Stavros1> hmm, i was wondering if it has a url that points to the bare directory
[21:17] <zepard> hi
[21:18] <Vantage> Stavros1: it might.  Shouldn't be hard to set one up if it doesn't though
[21:20] <LarstiQ> jelmer: oi, you added me to Line Endings ;P
[21:20] <jelmer> LarstiQ: Yeah, I initially assumed this was about who contributed to the actual discussion
[21:20] <jelmer> LarstiQ: You shouldn't be there any more now
[21:21] <Stavros1> Vantage: indeed, i'm doing it as we speak
[21:21] <Stavros1> it would just be nicer if it had one
[21:21] <Stavros1> i'll open a ticket
[21:22] <igc> night all
[21:22] <james_w> fooooooood!
[21:22] <beuno> food+1
[21:22] <LarstiQ> fair enough
[21:23] <phanatic> food++
[21:24] <Odd_Bloke> http://icanhascheezburger.files.wordpress.com/2008/01/funny-pictures-pandas-eating-noms.jpg
[21:28] <Stavros1> it works! thanks for your help
[21:28] <Stavros1> auth works too, since it's a normal directory
[22:19] <dato> oh, no james_w
[22:34] <abentley> dato: They were off to the pub last I heard.
[22:34] <dato> ok, thanks
[22:35] <blueyed> Can you query the last "push" to a repo (or "commit" for a checkout)? Is this "latest revision" in "bzr info -v"?
[22:38] <bpeterson> blueyed: yes
[22:45] <blueyed> well.. unfortunately "bzr info" is probably slower than "bzr commit". is there a shorter path for getting this info?
[22:46] <dato> blueyed: sorry, I did not understad your problem very well?
[22:47] <dato> maybe you want `bzr log -r -1 | grep timestamp` ?
[22:47] <dato> gotta go now
[22:47] <blueyed> dato: I'm thinking about optimizing the add-5-a-day tool: only commit if the last commit is older than 1h.
[22:48] <blueyed> yes.. makes sense and is faster.
[22:48] <bpeterson> blueyed: I'd try bzr log
[23:14] <awilkins> blueyed: how about bzr revision-info
[23:15] <awilkins> blueyed: forget it, that doesn't have the TZ offset in the time
[23:15] <awilkins> But it is UTC though....
[23:21] <blueyed> awilkins: it's quite some faster.. There is probably something better even in bzrlib though, which does not require using the email module to parse the output of a subprocess.. ;)
[23:28] <awilkins> Email module? Just take the split between the first and second "-"
[23:29] <awilkins> Or a regexp of 14 digits beginning with "20"
[23:29] <blueyed> awilkins: yes, from rev-info, but not from log.. a subprocess it bad though, isn't it - if I'm already in python.. can't I use bzrlib for this?
[23:29] <awilkins> blueyed: Yes, of course you can
[23:29] <ubotu> New bug: #199654 in baltix "bzr on fat32/ntfs from ubuntu  works only with sudo init/commit" [Undecided,New] https://launchpad.net/bugs/199654
[23:29] <ubotu> New bug: #199655 in bzr "bzr status shows pending merges with incorrect indentation" [Undecided,New] https://launchpad.net/bugs/199655
[23:30] <ubotu> New bug: #199659 in bzr "editor backup file left over after bzr commit" [Undecided,New] https://launchpad.net/bugs/199659
[23:34] <blueyed> awilkins: any hints where to look in bzrlib?
[23:34] <awilkins> branch.py is where I'm looking
[23:37] <awilkins> from bzrlib import branch ; b = branch.Branch.open(branchRoot) ; b.last_revision_info() ; # that seems to work
[23:41] <awilkins> Doesn't work for alternative revid formats like bzr-svn though
[23:42] <jelmer> There is no guarantee that standard revids follow that format either
[23:44] <awilkins> How do you make a python object tell you what members it contains?
[23:45] <awilkins> I can't be arse to pick through all the source looking for what revision_history() emits
[23:46] <Odd_Bloke> Evening all.
[23:46] <blueyed> awilkins: I use ipython and tab for that..
[23:47] <blueyed> ipython is really awesome wrt to tab-completion.. in fact it's also a shell replacement I've heard.. ;)
[23:48] <awilkins> bah, theyre just strngs anyway
[23:48] <blueyed> awilkins: yes, b.last_revision() seems to be the closest so far..
[23:49] <awilkins> blueyed: But you can't rely on the format and it's just a string
[23:51] <jelmer> b = Branch.open("foo")
[23:51] <jelmer> b.repository.get_revision(b.last_revision())
[23:51] <Odd_Bloke> jelmer: o/
[23:52] <jelmer> that last line will return a revision object which contains the commit timestamp among other things
[23:52] <jelmer> hey Daniel
[23:52]  * awilkins discovers __dict__
[23:53] <blueyed> jelmer: thanks, r.timestamp is it..
[23:54] <Odd_Bloke> jelmer: LarstiQ, Verterok, beuno, phanatic and I are sitting in the bar at the hotel with our laptops out. \o/
[23:54] <jelmer> Odd_Bloke: Which is why you're currently talking with me on IRC ? ;-)
[23:54] <beuno> Odd_Bloke, with girls, of course (?)
[23:54] <jelmer> *without laptop* >-)
[23:55] <jelmer> ah
[23:55] <jelmer> out as in you have them in front of you
[23:55] <jelmer> not as in you have them turned off
[23:56] <jelmer> well, I'm getting some sleep
[23:57] <jelmer> slept a total of 8 hours in total in the last two days and not much during the sprint either
[23:57] <jelmer> Say hi to the other folks over there for me!
[23:57] <beuno> jelmer, how was your exam?
[23:57] <jelmer> beuno: It went ok, but not brilliant.
[23:58] <jelmer> with a bit of luck, I'll pass it
[23:58] <beuno> jelmer, well, bzr-gtk got better, so that might help for your conscious
[23:58] <jelmer> :-)
[23:59] <james_w> hi jelmer. Sorry I missed you at the sprint.
[23:59] <james_w> Sleep well.