[00:25] <james_w> lifeless: looms look pretty cool to me, thanks again.
[00:25] <james_w> lifeless: any direction you want to point me in to do a bit of hacking to start to understand the mechanics?
[00:27] <james_w> I think the only difference with what I was looking at was the order of the parents in the merge commits that result from up-thread.
[00:27] <james_w> and obviously that you have a working implementation :)
[04:24] <cjb> Hi!  Is there a way for a repository to specify its submit_to address, such that `bzr send` could send mail to a default address for a pulled repository?
[04:31] <Verterok>   
[04:47] <baijum> The "HistoryOfBazaar" wiki page says: "In early 2008, Bazaar became GNU Bazaar when release 1.2 was accepted as part of the GNU project." is there any news or more details available ?
[05:05] <abentley> baijum: Not yet.  I was expecting some kind of announcement, but it's just kind of leaked out gradually.
[05:06] <abentley> cjb: Not yet.
[05:33] <Peng> Wait, so that's true?
[05:33]  * bob2 watches bzr climb up to 1gb of ram to check out ikarus.dev
[05:34] <bob2> with a healthy 3MB of data in the branch so far
[05:39] <Peng> So, what's the point of being a GNU project? Canonical can provide all of the hardware bzr needs, and I doubt they'd want to give up any control over the project...
[05:39] <Basic> marketing
[05:39] <Peng> Advertising?
[05:39] <Peng> Heh.
[05:39] <NichardRixon> homestarrunner.com cool website
[05:39] <Basic> heh
[05:40] <Peng> So, the big thing for shareware in the 1990s was to be get a Download.com badge, and now FOSS projects are going to go after GNU badges?
[05:40] <Basic> my local repo is messed up, is there a way, other then do do a bzr pull of upstream to just suck down all of upstream and overwrite and conflicts in my local repo?
[05:41] <Peng> Basic: Conflicts? Like, you've committed things in the branch, or your repo is corrupt?
[05:41] <Basic> like I forgot to commit stuff in local (desktop), hacked code in my laptop, pushed the changes from laptop to upstream, now want local/desktop to be in-sync
[05:42] <Basic> bzr merge gives me 138 conflicts and I know upstream and laptop are the changes I want to keep
[05:42] <bob2> now hit 1.5GB, nice
[05:43] <Peng> Basic: Why can't you bzr pull from upstream?
[05:43] <Basic> trying
[05:44] <Peng> Basic: "bzr help pull" says "If you want to forget your local changes and just update your branch to  match the remote one, use pull --overwrite."
[05:44] <Peng> s/  / /
[05:44] <Basic> excellent, exactly what I want thanks
[05:44] <bob2> with giant red flashing lights "you may lose data"
[05:45] <Peng> Heh, right.
[05:45] <Peng> Basic: You can use "bzr missing" to see if you have anything important in your version of the branch.
[05:46] <Peng> Oogh, why do I feel sick?
[06:18] <Peng> jelmer: I'm being lazy and not doing research here, but the BzrPlugins page lists bzr-svn as beta. Is it still?
[06:41] <lifeless> bob2: 'bzr heads' can recover commits, at leat until a gc.
[06:41] <lifeless> 16:33  * bob2 watches bzr climb up to 1gb of ram to check out ikarus.dev
[06:41] <lifeless> woops, didn't mean to paste :|
[06:42] <Peng> lifeless: By gc you mean the revisions being removed from the repo? Does that ever happen automatically?
[06:42] <lifeless> Peng: not presently
[06:42] <Peng> Right.
[06:43] <Peng> Ok, I'm going to go take that nap I meant to take an hour ago. Bye. :)
[06:53] <jeremyb> Peng: it's at 0.4.x iirc
[06:53] <jeremyb> Peng: i need to try it...
[06:54] <jeremyb> Peng: recently saw a bug fixed where it made a remote svn repo unusable by *anyone* on commit fwiw
[06:54] <jeremyb> (not all commits)
[06:55]  * jeremyb needs to sleep as well
[07:39] <bob2> lifeless: ah, neato
[09:59] <Odd_Bloke> jelmer: I'm in the Debian room ATM.
[11:16] <jelmer> Odd_Bloke: ping
[11:17] <Odd_Bloke> jelmer: Pong.
[11:18] <jelmer> Odd_Bloke: still wandering around on FOSDEM?
[11:18] <Odd_Bloke> jelmer: Yeah, in the Debian room ATM.
[11:19] <jelmer> Odd_Bloke: ah, cool
[11:19] <jelmer> me too
[11:19] <jelmer> LarstiQ is the guy behind the big camera btw
[11:20] <Odd_Bloke> Yeah, I ran in to him last night.
[11:20] <Odd_Bloke> His hair was less blue at that juncture.
[11:21] <Odd_Bloke> jelmer: I'm kinda opposite the door, wearing a red T-shirt using a Thinkpad.
[11:21] <Odd_Bloke> A T60, if that helps narrow it down. :p
[11:24] <johnf> is there anyone about that understands the smart server code? I'm trying to fix a bug in it
[11:25] <Odd_Bloke> johnf: Asking your question makes it more likely that people will respond. :)
[11:25] <johnf> Odd_Bloke: ok let me go paste some stuff somewhere
[11:25] <jelmer> Odd_Bloke: ah, I think I know who you are then :-)
[11:26]  * jelmer is sitting close to the door with a Thinkpad X60 and wearing a black debian sweater
[11:27] <johnf> http://pastie.caboo.se/156526. Basically a change was made which meant bzr+https stopped working. I've fixed that but now it looks like _remote_is_at_least_1_2 needs to be set somewhere.
[11:28] <johnf> I think just setting it to true like is done in bzrlib/smart/client.py is correct but I'm not sure of the right place to do it
[11:28] <johnf> the transport/http/_urllib doesn't feel like it would be the right place to do it
[11:31] <jelmer> johnf: you may want to bring this up on the list
[11:31] <jelmer> I don't think there are any smart server ackers about
[11:31] <johnf> that was my next move :)
[11:32] <jelmer> *hackers
[11:42] <james_w> johnf: one moment
[11:44] <james_w> johnf: I thought this came up on the list the other day, but I can't find it now.
[11:44] <james_w> johnf: are you using latest bzr.dev?
[11:45] <johnf> james_w: opps too late. Just emailed the list with some potential fixes. Stupidly didn't check archives. I'm testing with latest bzr.dev
[11:45] <james_w> johnf: no loss, I just thought there was a tentative patch you could apply, but as I can't find it a mail to the list is best.
[11:47] <johnf> james_w: The patch I just email works. First part I know is right. Second part does the job but I'm not sure that its appropriate. As I learned while debugging it today there is a lot of codebase involved in getting the smart server to do stuff!
[11:50] <james_w> johnf: I can't confirm I'm afraid, but you should get a response either way tomorrow.
[16:39] <hsn_> someone with sf.net shell acount with installed bzr here? I need bzr path
[18:01] <ubotu> New bug: #195133 in bzr-loom "Please notify when a thread becomes empty" [Undecided,New] https://launchpad.net/bugs/195133
[18:05] <ubotu> New bug: #195134 in bzr-loom "Lots of up-threads are tiring" [Undecided,New] https://launchpad.net/bugs/195134
[20:18] <Janzert> does "bzr tag blah" tag the most recent revision committed or get applied to the next commit?
[20:19] <dato> Janzert: the most recent committed revision
[20:19] <Janzert> thanks
[20:30] <shagbag> Can anyone help me with bazaar.launchpad.net?    I'm trying to checkout some code but it's taking AGES to connect and then it gives me the error: bzr: ERROR: Connection error: Couldn't resolve host 'bazaar.launchpad.net' (-2, 'Name or service not known')
[20:34] <awmcclain> Hey all... can someone enlighten me why, when I try to push my changes back to my mainline, I get bzr: ERROR: No push location known or specified.
[20:34] <jdong> awmcclain: it doesn't know where to push?
[20:35] <awmcclain> jdong: How does that get set? I can pull fine
[20:35] <jdong> awmcclain: the first push has to have an explicit destination. Afterwards bzr will remember that destination. Also see push --remember
[20:35] <awmcclain> jdong: I see. So, the first time you have to specify.
[20:35] <jdong> awmcclain: right.
[20:35] <jdong> awmcclain: hte last paragraph in bzr help push explains it better than I can :)
[20:36] <awmcclain> jdong: Got it.
[20:36] <jdong> awmcclain: also, bzr info can show you the various remembered locations, if you forgot or need something to copy-paste from
[20:38] <awmcclain> jdong: Is there an easy way to convert a branch into a checkout w/o overwriting the files I've changed?
[20:38] <jdong> awmcclain: bzr bind
[20:38] <awmcclain> Done.
[20:39] <awmcclain> greart
[20:39] <jdong> awmcclain: any differences you've made will show up as a merge when you first bzr up
[20:42] <awmcclain> hrm
[21:28] <lifeless> shagbag: sounds like a dns error at your location
[21:28] <lifeless> shagbag: what does 'host bazaar.launchpad.net' say ?
[21:42] <lifeless> hi poolie
[21:57] <poolie> good morning lifeless
[21:58] <james_w> morning lifeless
[21:58] <james_w> morning poolie
[22:28] <james_w> lifeless: I might be being silly, but can you confirm that setting tree.branch.nick doesn't change the thread you are on?
[22:28] <james_w> I'm looking at test_up_thread_preserves_changes in blackbox.py
[22:30] <lifeless> james_w: it changes the pointer at the current thread
[22:30] <lifeless> james_w: in the TODO there is a note that this should be replaced by it renaming the current thread.
[22:47] <james_w> lifeless: thanks.
[22:48] <lifeless> james_w: most of TODO can be made bugs now
[22:48] <lifeless> james_w: for hopefully obvious reasons, using malone was a little tricky before the release.
[22:53] <james_w> lifeless: of course.
[22:53] <james_w> lifeless: you abandoned the rename to warps?
[22:56] <igc> morning all
[22:58] <lifeless> james_w: mixed minds
[22:58] <lifeless> I think the accuracy of warp and weft reference will be beyond most folk;
[22:58] <lifeless> that is not actually helpful
[22:59] <lifeless> but most everyone knows what a thread is in fabric terms
[23:00] <lifeless> OTOH warp and weft are a more detailed analogy with richer (and useful) implications
[23:00] <lifeless> poolie: today I am doing ui for shallow branches
[23:01] <igc> poolie: call now?
[23:07] <james_w> lifeless: I might spend some time sorting out the TODO and moving some stuff to Malone then.
[23:07] <james_w> patch sent anyway, that's all for tonight.
[23:07] <lifeless> that would be good
[23:07] <lifeless> thanks!
[23:08] <james_w> the code looks very clean from what I have seen, and the documentation is great as well, so thank you.
[23:09] <james_w> The only thing I am not that clear on is "record", but it seems that is a temporary solution according to the TODO.
[23:16] <lamont> I wonder if there's already a bug in the system about bzr not tracking file permissions
[23:16] <lamont> (git does)
[23:16] <james_w> lamont: git doesn't
[23:16] <james_w> lamont: which permissions would you like tracking?
[23:17] <lamont> git diff 8e16fa6ff4f1bd3e42febd166f3e1074c6f87bdb..7fca3ff2f2ab0774d4a92c2bd40bfc7c4d596e4c
[23:17] <lamont> diff --git a/cron.d/cache-git-status b/cron.d/cache-git-status
[23:17] <lamont> old mode 100755
[23:17] <lamont> new mode 100644
[23:17] <lamont> james_w: I beg to differ.
[23:18] <lamont> although just tracking the last 12 bits would be plenty.
[23:18] <lifeless> lamont: git doesn't track full modes; it just cheats for what it appears to record
[23:18] <lifeless> lamont: see git-fastexport's stream format for instance
[23:18] <lamont> while bzr just plain ignores mode
[23:18] <lifeless> bzr tracks exec
[23:18] <james_w> lamont: that just means executable, which bzr tracks as well.
[23:18] <lamont> ah, just not rw?
[23:18] <lifeless> anyhow, for sysadmins see the discussion I'm having with elmo & co about a plugin
[23:19] <james_w> lamont: make it 750 and try again.
[23:20] <lamont> james_w: hrm.. thanks
[23:21] <lifeless> lamont: score one for git...not :>
[23:21] <james_w> lamont: no problem. You can see etckeeper for some wrappers and stuff around git(?, maybe others) that tracks full (?) permissions for versioning /etc
[23:21] <fullermd> It's easy to make it 750; you just have to change your umask   ;)
[23:22] <james_w> lamont: but in general it is a headache to track them, so most systems don't.
[23:22] <lamont> right
[23:22] <lifeless> james_w: the canonical sysadmins would love a etckeeper for bzr; I have a spec
[23:24] <james_w> lifeless: you mean a plugin, rather than using etckeeper?
[23:24] <lifeless> yes
[23:24] <james_w> I doubt etckeeper is VCS specific, but a plugin may make for a better experience.
[23:25] <jelmer> lifeless: I have the implementation
[23:25] <jelmer> lifeless: see http://gitweb.samba.org/
[23:25] <james_w> right, that really is all from me. Thanks all, and good night.
[23:25] <jelmer> however, it hsn't been merged yet because bzr doesn't have a start-commit hook
[23:26] <jelmer> so it's not totally functional, which is why it hasn't been merged yet
[23:26] <lifeless> jelmer: could you be more specific; thats just a web page list
[23:26] <lifeless> jelmer: also, I'm talking about not using etckeeper but doing a plugin
[23:26] <jelmer> there's only one etckeeper repo there :-)
[23:26] <jelmer> http://gitweb.samba.org/?p=jelmer/etckeeper.git;a=summary
[23:27] <jelmer> it basically boils down to being a plugin since it requires a plugin that calls out to etckeeper
[23:27] <lifeless> is it just me or that web ui ugly?
[23:27] <jelmer> of git web?
[23:27] <jelmer> I like it better than loggerhead
[23:28] <lifeless> loggerhead is ugly too
[23:28] <lifeless> in differnet ways
[23:29] <lifeless> none of the web uis I've seen for vcs introspection feel nice
[23:29] <jelmer> yeah, there aren't any really good ones yet
[23:30] <mwhudson> if anyone can come up with a nice design for loggerhead, i'm permanently volunteered to do the coding to make it happen, btw
[23:31] <ubotu> New bug: #195245 in bzr-loom "'record' is too generic a name, and is possibly a conflict with another plugin" [Medium,In progress] https://launchpad.net/bugs/195245
[23:34] <lifeless> mwhudson: I think its basically too static and too slow
[23:34] <lifeless> mwhudson: the visuals aren't the issue, the coarseness of the interface is.
[23:34] <mwhudson> lifeless: 'too static' ?
[23:34] <lifeless> mwhudson: I'd like fast drill-downs, pivots between files/history/annotations
[23:35] <lifeless> google maps for the vcs data
[23:35] <mwhudson> oh right yes
[23:35] <lifeless> now theres an idea; if we built maps tiles from a  branch we could literally point maps at it
[23:35] <mwhudson> well, i see the point but don't really have a clue how this would work well
[23:36] <mwhudson> (even out of a browser, truth be told: 'bzr viz' is pretty nice, but not completely there)
[23:36] <awilkins> Is there a plugin which will allow you to commit selectively by deleting lines from your commit log "line below" section?
[23:37] <lifeless> I believe so
[23:37] <lifeless> selective commit I think its called
[23:38] <awilkins> Could also use gcommit I suppose, but not as vimtastic :-)
[23:58] <lifeless> jelmer: so when should I expect a patc to review for a commit start python hook ?
[23:59] <jelmer> lifeless: when I find the time :-(
[23:59] <jelmer> lifeless: My time for bzr is somewhat limited at the moment and the time I do have I spend on the plugins I'm maintainer for
[23:59] <lifeless> you're coming next week ?