[00:42] <gotgenes> I've made some local, uncommitted changes but decided they would be better suited to be put into their own branch. Is there an easy way I can branch, keeping the local changes?
[00:42] <jelmer> gotgenes: "bzr branch thisdir otherdir; cd ../otherdir; bzr merge --uncommitted ../thisdir"
[00:43] <gotgenes> jelmer: awesome, let me try that
[00:43] <bob2> if you're using checkouts, make a new branch, and 'bzr switch' the working copy to the new branch
[00:43] <gotgenes> bob2: no checkouts in this case
[00:44] <EnCuKou> Or commit --local, branch, and uncommit
[00:48] <gotgenes> jelmer: Brilliant!
[00:49] <gotgenes> EnCuKou: that would also work, too.
[01:04] <mwhudson> merge --uncommitted is cool
[01:15] <jml> yeah
[01:27] <igc> mwhudson: did that TODO for revnocache prove interesting?
[01:27] <mwhudson> igc: yes
[01:28] <igc> mwhudson: lifeless has some thoughts he'd like to share on how best to use btrees so be sure to ping him before hacking on that bit
[01:28] <mwhudson> igc: i'm hip-deep in reviewing launchpad code today though
[01:29] <igc> mwhudson: np. Just making sure I didn't forget to tell you :-)
[01:29] <mwhudson> igc: ok, i saw, i cogitated, but no more than that :)
[02:35] <LaserJock> any ETA on working ~bzr PPA for Intrepid?
[02:43]  * igc lunch
[04:31] <poolie> lifeless: ping?
[04:31] <poolie> lifeless: i got a pqm failure full of lines like this:
[04:31] <poolie> merge http://sourcefrog.net/bzr/remove-sftplock http://bazaar-vcs.org/bzr/bzr.dev
[04:31] <poolie> Command failed!
[04:31] <poolie> All lines of log output:
[04:31] <poolie> Executing pre-commit hook /home/pqm/bin/kill-chroot-processes.sh /srv/pqm.ubuntu.com/chroot-amd64 && /home/pqm/bin/dchroot-run make check at Thu Feb  5 04:26:46 2009
[04:31] <poolie> Scanning for processes to kill in chroot /srv/pqm.ubuntu.com/chroot-amd64
[04:31] <poolie> Scanning for processes to kill in chroot /srv/pqm.ubuntu.com/chroot-amd64
[04:31] <poolie> removed directory: `/srv/pqm.ubuntu.com/chroot-amd64/tmp/bzr-limbo-011qkx'
[04:31] <lifeless> spm: ^
[04:32] <spm> hrm
[04:32] <spm> tom did some changes there this morning....
[04:32] <lifeless> my guess
[04:32] <lifeless> the commit before left dirt
[04:33] <lifeless> and the kill-checker found that dirt and exited non-zero as a result
[04:33] <lifeless> so -- resubmit your merge
[04:33] <lifeless> and file a bug that we aren't cleaning up bzr-limbo-011qkx during test runs
[04:33] <lifeless> and tell everyone to submit every merge twice until we do :P
[04:33] <poolie> :/
[04:34] <lifeless> or we can roll the clean-checker back
[04:34] <lifeless> but we had a bunch of stale bzr test processes yesterday, from months back
[04:34] <lifeless> and the sysadmins pinged me
[04:34] <lifeless> this is an existing tool written for lp
[04:36] <spm> lifeless: would it be worthwhile reverting tom's change to pqm-config, till you guys get this stuff sorted?
[04:36] <poolie> the second request i sent just failed too
[04:36] <lifeless> spm: things without motivation often don't get sorted
[04:36] <lifeless> poolie: interesting, hang a tick
[04:36] <poolie> lifeless: what's it supposed to do?
[04:37] <lifeless> spm: can you check if there is other dirt left behind?
[04:37] <lifeless> spm: perhaps the check is not fully cleaning
[04:37] <spm> poolie: basically is doing: for ROOT in /proc/*/root; do [04:37] <spm> lifeless: sure, one sec
[04:37] <lifeless> poolie: it finds processes and temporary directories created in the chroot, and zaps em
[04:37] <poolie> as part of the *next* merge?
[04:37] <lifeless> poolie: so that old test runs that left cruft don't cause spurious success||failure to new ones
[04:38] <lifeless> poolie: that part seems odd to me too :P
[04:38] <lifeless> spm: I'd be inclined to run it before and after, FWIW
[04:38] <poolie> ok and the third one just failed too
[04:38] <spm> lifeless: a prehook as well?
[04:38] <poolie> istr that pchroot or dchroot handles this as a standard feature
[04:39] <lifeless> spm: /home/pqm/bin/kill-chroot-processes.sh /srv/pqm.ubuntu.com/chroot-amd64 && /home/pqm/bin/dchroot-run make check && /home/pqm/bin/kill-chroot-processes.sh /srv/pqm.ubuntu.com/chroot-amd64
[04:39] <lifeless> spm: for lp too IMO, but thats a different discussion. Lets find out the cause of this problem, and then unblock poolie
[04:40] <spm> sure - fixing - one tick
[04:41] <spm> poolie: try now
[04:42] <poolie> ok sent
[04:50] <poolie> spm: still sucks
[04:51] <spm> lifeless: I think we're picking up procs from another chroot on that box
[04:51] <lifeless> spm: better disable it for now then
[04:51] <lifeless> spm: if you would be so kind
[04:51] <spm> 2/2 then? :-P
[04:52] <poolie> yes, please disable it
[04:52] <lifeless> well, 2/1 for zings, and $help-each-other-whenever ;)
[04:52] <poolie> 2/2 what?
[04:52] <spm> hahahahha
[04:52] <poolie> 100% of my submissions have failed
[04:52] <poolie> it sounds like a useful feature but only if it works :)
[04:54] <LaserJock> poolie: you happen to know if bzrtools is gonna get updated in ~bzr PPA any time soonish?
[04:54] <poolie> yes, soon
[04:54] <poolie> LaserJock: what do you use from bzrtools btw?
[04:55] <spm> poolie: go for it. btw did I ever mention that bzr rocks for doing config file management?
[04:55] <LaserJock> poolie: I have no idea but I can't upgrade bzr-svn I don't think
[04:55] <poolie> ?
[04:55] <poolie> spm, trying again
[04:56] <LaserJock> I don't know, but I can' do a clean upgrade, I've gotta remove something, let me check
[04:57] <LaserJock> ok, so I can upgrade bzr and bzr-svn but bzrtools gets removed
[04:57] <LaserJock> I don't know what all is in bzrtools but I've always been told it's pretty important to have
[05:01] <poolie> spm, ok, i got a real failure, yay
[05:01] <spm> poolie: cool - progress of sorts :-)
[06:07] <lifeless> night all
[06:07] <lifeless> poolie: were you going to reply to that mail ?
[06:14]  * spiv heads off to SyPy
[06:19] <thumper> how do I get bzr to show me the revision id of the last revision from the commandline?
[06:20] <mwhudson> thumper: bzr revision-info
[06:21] <thumper> ta
[06:56] <vila> hi all
[07:12] <poolie> hello vila
[09:22] <fullermd> me blinks.
[09:22] <fullermd> I thought autopack only did its thing when we got up to 10 packs (or various farther iterations)
[09:39] <ronny> moin
[11:54] <bartzitz> hello, i'm affected by this bug https://bugs.launchpad.net/bzr/+bug/319790 (can't unshelve my changes)
[11:54] <bartzitz> someone suggests restoring the shelf manually, but how do i do it?
[11:58] <ronny> jelmer: say - are there any plans to have some kind of content-addressing in bzr?
[13:06] <igc> night all
[13:18] <beuno> ugh
[13:18] <beuno> mac and windows encoding are not getting along
[13:18] <beuno> does anyone know how I can avoid getting into this situation?  http://paste.ubuntu.com/114010/
[13:19] <Tak> ouch
[13:24] <Peng_> igc: You're probably gone now, but the "log multiple files and directories" merge directive you just sent has an incorrect target_branch, so BB won't track it.
[13:26] <verterok_> beuno: playing with the encoding options when mounting the sshfs?
[13:26] <verterok_> beuno: hi!, btw
[13:27] <beuno> verterok_, hai!
[13:27] <beuno> verterok_, no sshfs involved  :(
[13:27] <beuno> blain branching back and forth
[13:29] <verterok_> :/
[13:29] <Tak> jelmer: ping?
[14:07] <Lo-lan-do> Hi all
[14:07] <Lo-lan-do> jelmer: I guess subvertpy is in NEW... is the package available somewhere in the meantime?
[14:10] <ronny> pypi?
[14:12] <Lo-lan-do> ?
[14:12] <ronny> python package index
[14:13] <Lo-lan-do> I'll have a look, thanks.
[14:13] <ronny> its easy-install able
[14:13] <Lo-lan-do> Oh.  No go then, I need dpkg-able :-)
[14:13] <ronny> hmm
[14:14] <ronny> maybe there is a ppa on launchpad
[14:14]  * Lo-lan-do rebuilds from the source package available in the PPA
[14:14] <ronny> jelmer: btw, how does one do a commit with message from a wc/client in subvertpy?
[14:15] <ronny> client.commit seems to be without message
[14:16] <james_w> are the messages done with callbacks?
[14:16] <ronny> i have no idea
[14:20] <jelmer> ronny, you need to specify a callback for the message
[14:20] <jelmer> ronny, client_ctx.log_msg_func = lambda items: "bla"
[14:20] <ronny> yikes
[14:21] <jelmer> items is the list of things being committed
[14:21] <ronny> jelmer: is it possible to tell it the author?
[14:21] <jelmer> ronny, the callback ? no, the author isn't known at that point
[14:22] <jelmer> svn sends back the author only once the commit is done
[14:23] <ronny> what where they thinking?
[14:27] <Tak> jelmer: I was looking at the md-bzr debian branch - ironpython shouldn't be in the build-depends
[14:39] <tedg> Hello, I thought there was a way to attach metadata to a file in bzr, but I can't seem to figure out to do it.  Can I do that from the command line?
[14:41] <Tak> new version will depend on bzrtools, though, and xmloutput (once there's a deb package)
[14:43] <gnomefreak> is there a way to use bzr to generate an upstream tarball using the version in the debian/changelog?
[14:43] <jelmer> Tak, right now, it does depend on ironpython, see the mdp file
[14:43] <jelmer> gnomefreak, bzr builddeb --export-only . IIRC
[14:43] <ronny> jelmer: btw, do you guys have any plans for content-addressing?
[14:43] <gnomefreak> jelmer: thanks ill try it
[14:43] <ronny> i need a git-alike object db soon that can handle more than just blob/tree/commit/tag
[14:44] <ronny> however i need it content-addressed
[14:44] <gnomefreak> that failed :(
[14:44] <Tak> I can remove the reference, but it's not being used anyway
[14:45] <jelmer> gnomefreak, it works fine here, what error do you get?
[14:45] <gnomefreak> jelmer: http://pastebin.mozilla.org/616311
[14:46] <jelmer> ronny: I'm not sure I follow
[14:46] <jelmer> ronny: What do you mean by content-addressing? Being able to fetch revisions/texts by their checksum?
[14:47] <jelmer> gnomefreak, you're not exporting upstream from bzr, any reason for not just using uscan?
[14:47] <ronny> jelmer: yeah
[14:47] <jelmer> ronny, I don't think there are any plans for that
[14:47] <ronny> ok
[14:47] <gnomefreak> jelmer: not sure how would be the biggest reason
[14:47] <ronny> then i'll reimlement git's object db soon
[14:48] <ronny> git cant be extended with new types
[14:49] <gnomefreak> maybe ill just get the most recent and update change as needed
[14:50] <bialix> hi, any bzrlib hackers here?
[14:50] <jelmer> gnomefreak: uscan already parses debian/changelog, I think if you use the right magic options for it it can download the appropriate tarball
[14:50] <jelmer> hi bialix
[14:50] <bialix> I have question about test
[14:50] <bialix> hi jelmer
[14:50] <gnomefreak> jelmer: thanks ill look at man page
[14:51] <bialix> my question is: how can I test that some method I call write rnings?
[14:51] <bialix> warnings
[14:51] <bialix> I'd like to avoid write black-box test
[14:52] <bialix> any ideas?
[14:59]  * bialix looks at TestCase attributes
[15:00] <bialix> or maybe I need to use bzrlib.trace.push_log_file?
[15:19] <bialix> push_log_file is fine
[15:57] <santagada> something missing from the bazaar user guide is if using bazaar server by itself provides any form of security
[15:59] <Peng_> santagada: It does not. That's what running it through ssh is for. :)
[15:59] <Peng_> Or http.
[16:01] <MattCampbell> Or SMB if you're on an all-Windows LAN.
[16:04] <santagada> but http is not using the smart server right?
[16:05] <MattCampbell> The smart server can be used over HTTP.
[16:06] <santagada> MattCampbell: really? that is not on the user guide I think
[16:07] <santagada> MattCampbell: Great! that was one of the problems I thought when moving from subversion to bazaar...
[16:07] <MattCampbell> santagada: What's wrong with bzr+ssh?
[16:08] <santagada> MattCampbell: firewalls, stupid firewalls, and windows users
[16:09] <Lo-lan-do> What's wrong with bzr send + email?  Surely even Windows users can send mails...
[16:09] <santagada> MattCampbell: and it is far easier to connect a subtree of a web server to ldap than to change a whole system login to suport a dev team
[16:09] <santagada> Lo-lan-do: :)
[16:10] <MattCampbell> Hmm, let me double-check that you can run the bzr smart server over HTTP; I may be confusing bzr with Mercurial.
[16:15] <MattCampbell> Now I'm curious; does Launchpad even support authenticated bzr access over HTTP?
[16:15] <MattCampbell> I know Launchpad supports bzr+ssh via a custom SSH server using twisted.conch.
[16:16] <Lo-lan-do> And as for firewalls, surely they don't block HTTPS, do they?
[16:17] <MattCampbell> I'd hope not, though some especially anal ones may require you to use a proxy with the CONNECT command.
[16:17] <Lo-lan-do> http://sam.zoy.org/blog/2007-04-23-use-sshd-and-httpd-on-the-same-port-almost is your friend
[16:18] <Tak> most "especially anal" ones don't support CONNECT at all
[16:18] <Tak> in my experience
[16:18] <santagada> there is a firewall on some machines on my university that blocks some http verbs that mod_svn uses
[16:18] <MattCampbell> Then I suppose they allow direct access to port 443.
[16:18] <Lo-lan-do> In my experience, these ones are more of a hindrance to work getting done than anything else, so the problem becomes a human problem that technical solutions won't help solve.
[16:18] <santagada> so you can update/checkout from http but not commit
[16:19] <santagada> MattCampbell: yes, using https solves the problem
[16:20] <MattCampbell> Does anyone know of a firewall that monitors the traffic on outgoing connections to port 443 to make sure it's really SSL?
[16:20] <santagada> still as I don't have the custom ssh server lp uses I prefer https with ldap for repo comunication
[16:21] <santagada> MattCampbell: yes, the traffic shappers used by some ISPs does this
[16:21] <MattCampbell> santagada: You could probably do a good imitation of Launchpad's ssh server if you know Python and Twisted.
[16:21] <Lo-lan-do> You can still tunnel SSH over SSL then.
[16:21] <santagada> MattCampbell: yep... but still, http and ldap can be used by non python programmers
[16:22] <MattCampbell> I assume Launchpad's custom SSH server is part of the code-hosting component which will be kept proprietary.
[16:22] <santagada> Lo-lan-do: double the encryption for double the security? :)
[16:23] <Lo-lan-do> No, double the encryption so these proxies can only see an SSL stream without knowing it's really SSH inside.
[16:23] <santagada> Lo-lan-do: I got it, but it still doesn't solve the problem of having a ssh server that uses ldap for authentication, without messing with the system one
[16:24] <Lo-lan-do> I'm not sure I follow...
[16:24] <Lo-lan-do> Why do you want two sshds?
[16:25] <santagada> Lo-lan-do: if your set of bzr users are not the same as your unix users
[16:25] <santagada> Lo-lan-do: or for example if you have a windows server
[16:25] <Lo-lan-do> Oh, *ugh*
[16:26] <santagada> Lo-lan-do: both of the situations happen
[16:27] <Lo-lan-do> I bet they do.  Poor guys...
[16:27] <bialix> no, they're not poor, because bzr gave them rich-roots!
[16:29] <bialix> hi garyvdm
[16:29] <garyvdm> Hi
[16:29] <bialix> I've looked at the bug about UI factory
[16:29] <bialix> but did not find solution quickly
[16:30] <bialix> it seems there was big change recently
[16:30] <garyvdm> bialix: I'm looking at it atm.
[16:30] <bialix> old code rely on self.stdout/self.stdin
[16:30]  * bialix nods
[16:30] <garyvdm> Yhea that was me - but stdout/stdin should be there
[16:31] <bialix> I've tracked it down to bzrlib
[16:31] <garyvdm> I'm getting a different traceback
[16:31] <bialix> you've changed the base class, there I'm stopping
[16:31] <bialix> I'm running bzr.exe 1.11
[16:31] <bialix> I guess you're using bzr.dev
[16:32] <garyvdm> I have the same problem on 1.11 and bzr.dev
[16:35] <garyvdm> This is the traceback I'm getting
[16:36] <garyvdm> I get it from any q* command. Ones that use the subprocess ui factory like qpull, and ones that use in process ui factory, like qlog.
[16:36] <garyvdm> I don't get it if I just run bzr pull
[16:37] <garyvdm> I get it if I revert back to rev 575 of qbzr
[16:37] <garyvdm> which is before I started changing the ui factories
[16:38] <bialix> hmmm
[16:38] <bialix> can you pastebin your traceback
[16:39]  * bialix reverts to 575 too
[16:39] <garyvdm> http://pastebin.com/d7f36feaa
[16:39] <garyvdm> Sorry - I pastebined it a while ago and forgot to send the url <-- silly me
[16:40] <bialix> you've got completelly different error
[16:40] <garyvdm> Same problem with rev 549
[16:40] <bialix> can you try with lp: url? without ssh key
[16:41] <bialix> I don't have the problem with 575
[16:41]  * garyvdm tries to figure out how to disable his ssh key on ubuntu
[16:42] <bialix> oops
[16:42]  * bialix has no idea
[16:42] <garyvdm> Got it
[16:42] <MattCampbell> santagada: BTW, you *can* run the bzr smart server over HTTP; it's documented in the user guide.  You can use either FastCGI or Apache 2 with mod_python.
[16:45] <garyvdm> bialix: Going to boot Windows
[16:45] <santagada> MattCampbell: I was at section 7.4... thanks
[16:45] <bialix> garyvdm: no problem with r576 too
[16:45]  * bialix waits for gary to rebbot
[16:46] <santagada> MattCampbell: I think there should be a link to the appendice about it... or a more proiminent one
[16:46] <garyvdm> Ahh - bialix - can I give you a bundle to test
[16:46] <bialix> of course
[16:48] <MattCampbell> santagada: Or sinze the smart server's HTTP transport is a WSGI application, you can run it as a separate HTTP server (using e.g. wsgiref or paste.httpserver) and have Apache proxy to it.
[16:49] <MattCampbell> There are actually very many options for deploying a WSGI app, as I recently learned.
[16:49] <bialix> garuvdm: btw, there is another bug introduced in r579. when I click Cancel in password dialog the subprocess cannot stops
[16:49] <bialix> garyvdm: sorry ^^
[16:51] <santagada> MattCampbell: yep, if it is a wsgi app it is very very flexible
[16:52] <santagada> MattCampbell: my latest idea is use cherokee web server + scgi
[16:53] <MattCampbell> santagada: Why Cherokee?
[16:54] <santagada> MattCampbell: Cherokee is very light, like lighttpd but seems even simpler to configure
[16:55] <santagada> maybe ngix is also a good idea... or lighttpd
[16:57] <bialix> garyvdm: you're still here?
[16:57] <garyvdm> Yhea
[16:57] <bialix> r576-581 (including) have no problem for me
[16:58] <bialix> offending revision is 582
[16:58] <garyvdm> bialix: I've just sent you bundle.
[16:58] <bialix> Gary, why you need to change base class? I'm curious
[17:00] <garyvdm> Because TextUIFactory expects to be able to prompt the user and get a response from stdin
[17:01] <garyvdm> The only situation qbzr can handle that is for passwords.
[17:02] <bialix> hmmmmmmmmmmmmmmmmmmmmm
[17:02] <bialix> I cannot reproduce the bug on the netbook with English XP
[17:03] <bialix> but can on Russian Windows
[17:03] <MattCampbell> I don't even know what this bug is, but it smells like a Unicode problem.
[17:03] <garyvdm> I think the problem my be with using super - so maybe python version.
[17:04] <MattCampbell> Well, my comment is based on bialix's one statement about the bug happening on Russian Windows but not English Windows.
[17:04] <garyvdm> MattCampbell: The error: AttributeError: 'SubprocessUIFactory' object has no attribute 'stdout'
[17:05] <garyvdm> bug 324758
[17:05] <bialix> weird
[17:06] <bialix> but there different plugins set
[17:07] <bialix> garyvdm: different traceback now
[17:07] <bialix> bzr: ERROR: exceptions.TypeError: __init__() takes exactly 1 argument (4 given)
[17:08] <bialix>   File "C:\work\Bazaar\plugins\qbzr\lib\subprocess.py", line 617, in __init__
[17:08] <garyvdm> bialix: ok - let me boot into windows
[17:09] <bialix> garyvdm: http://pastebin.com/m27669343
[17:11]  * bialix waits
[17:12] <bialix> garyvdm: http://pastebin.com/m27669343
[17:13] <bialix> garyvdm: it seems in the older bzr versions CLIUIFactory constructor has only self argument
[17:14] <Lo-lan-do> How recognizable is the bzr crowd?
[17:14] <Lo-lan-do> For the sake of example, let's assume the context of a large beer-oriented pub filled to the brim with geeks.
[17:15] <LeoNerd> I find I quite often use 'bzr shelve' etc.. in svn checkouts. If I haven't used it for a while, it has to spend a while pulling changes from the SVN repo. Is there some command I can schedule via cron, maybe, so that my local bzr-svn cache is kept up to date?
[17:15] <Necoro> Lo-lan-do: the guys prasing Linus Torvalds as a (semi)god are probably git-fanatics ...
[17:16] <Lo-lan-do> LeoNerd: I think that's a bug I reported already, and jelmer said it would be fixed for 0.5.1.
[17:16] <GaryvdM> bialix: Got to do some work related stuff - but I'll return shortly
[17:16]  * bialix going to home soon
[17:16] <LeoNerd> Lo-lan-do: Oh.. I don't think it's a bug... it works well enough.. I just would like it to keep its cache up to date while I'm not using it. Say, overnight.
[17:17] <bialix> GaryvdM: if I'm commenting out extra args from constructor I'm get the same traceback
[17:18] <Lo-lan-do> LeoNerd: Five minutes for a bzr update when there's only one revision to pull qualifies as a bug for me, but YMMV.  Anyway, just run "bzr update" at night, and you should be fine.
[17:18] <bialix> I guess we can simply set stdout attribute from our code if bzr < 1.12
[17:19] <bialix> GaryvdM: I'm heading to home, will try to check the trick with stdout at home
[17:20] <bialix> GaryvdM: but it seems we should override CLIUIfactory constructor in the way similar to TextUIFactory
[17:21]  * bialix bbl
[17:21] <LeoNerd> Lo-lan-do: Oooh.. Well, if there really is only one revision then mine is quick. It's just our repo is massive, it gets the order of 5 commits a minute. If I haven't used bzr-svn in a few weeks, it has to spend many minutes catching up. I'd like to have a daily cron task that keeps the cache fresh, as of that morning
[17:22] <Lo-lan-do> LeoNerd: Apparently (from the logs) something scans all SVN revisions after having fethed the new ones.
[17:23] <Lo-lan-do> If I'm up-to-date, a bzr update takes ~10 seconds.
[17:23] <Tak> ditto, at least
[17:23] <Lo-lan-do> If I need to pull revs, then it's ~15 seconds doing useful stuff followed by ~5 minutes spent doing "something" to every revision in the cache.
[17:24] <Lo-lan-do> In my case we have ~7000 revs in SVN.
[17:24] <Tak> mine is like 130k
[17:25] <Lo-lan-do> Tak: And it's still fast?
[17:25] <Lo-lan-do> I must be doing something wrong then...
[17:25] <Tak> ...fast?
[17:26] <Lo-lan-do> Sorry, I may have misunderstood.  Do you also see delays of several minutes when doing a bzr update?
[17:27] <kfogel> terminology question: in bzr, do people tend to refer to the mainline as "mainline", "trunk", "master", or something else?
[17:29] <Lo-lan-do> I tend to use trunk because that's what people coming from SVN know.
[17:30] <Lo-lan-do> Also, because it sits well with the concept of branches.
[17:30] <LeoNerd> kfogel: "what mainline" ?
[17:30] <Lo-lan-do> The one with the Holy Penguin Pee, of course.
[17:31] <kfogel> LeoNerd: "mainline" == "the branch that developers of the project socially agree contains the latest code that is ultimately destined for release"
[17:31] <LeoNerd> kfogel: But such a concept doesn't always exist
[17:31] <Lo-lan-do> I would s/release/the next release/
[17:31] <LeoNerd> That's surely the point of decentralised working, no?
[17:32] <kfogel> LeoNerd: no, I don't think it is.  The concept always exists, as a concept :-).  Whether it exists in a given project is usually not a matter of controversy, but can sometimes be.
[17:32] <kfogel> LeoNerd: another way to think of it is "the place where a change needs to land to be taken seriously by the group of people who call that place 'mainline'".
[17:33] <kfogel> LeoNerd: So you see, it's not less decentralized, it's just that the term can be relative.  As indeed it can be with a centralized VC system too.
[17:34] <clemente> kfogel: I call it the „official“ branch or refer to it by name; for instance „In bzr.dev ...“
[17:35] <Lo-lan-do> (I still don't know how to find you guys tomorrow night at the Delirium Café...)
[17:36] <kfogel> clemente: that works, though not equally well in all writing contexts
[17:36] <kfogel> I guess I'll go with trunk for the generic term, for now.
[17:37] <Tak> Lo-lan-do: yeah, I see long delays when updating, pulling, merging, even when there are no changes
[17:37] <Lo-lan-do> Tak: Ah.  Reproducibility is always good :-)
[17:45] <GaryvdM> bialix: I can reproduce the problem now.
[17:46] <benrometsch> sorry if this is a ridiculously stupid question, but I'm trying to figure out whether bzr or git is better for me, and I cant find a way of creating a local branch in bzr - am I missing something?
[17:46] <benrometsch> \]
[17:46] <Peng_> benrometsch: Bzr doesn't support git-like local branching. You only get one branch per directory.
[17:46] <benrometsch> right that's what I thought
[17:47] <benrometsch> is there a philosophical reason for this?
[17:47] <Lo-lan-do> "Not implemented yet".  Not very philosophical :-)
[17:47] <benrometsch> lol
[17:47] <Lo-lan-do> Well, it depends on what you call a local branch, actually.
[17:48] <Necoro> Lo-lan-do: is there really a plan to have something like this?
[17:48] <Lo-lan-do> Necoro: Apparently there is.  The keyword is "colocated branches".
[17:48] <Necoro> ah ok
[17:48] <Necoro> I thought, that it was really avoided as of "we do not want this"
[17:48] <Lo-lan-do> benrometsch: "bzr branch $remote" gives you a branch that is local, doesn't it?
[17:49] <Tak> I have never understood the "need" for colocated branches
[17:49] <benrometsch> but I mean you cant switch branches within the same directory
[17:49] <Lo-lan-do> Necoro: I think it's "we do not want this unless implemented properly", which is slightly different.
[17:49] <benrometsch> so if I have a project with files/dirs in it I cant create a local brach, make changes and then if required quickly revert back to the original branch
[17:49] <Lo-lan-do> benrometsch: Correct, although you can simulate that with a shared repo and a lightweight checkout.
[17:50] <benrometsch> yeah but that's just like SVN...
[17:50] <benrometsch> and we already use SVN
[17:50] <Necoro> benrometsch: Oo - bzr branch $remote b; cd b; code ...; cd ..; rm -rf b
[17:50] <Lo-lan-do> I don't have a good answer for you then I'm afraid :-/
[17:51] <Necoro> benrometsch: or I am not really understanding your point ;)
[17:51] <Necoro> as the branch you get with "bzr branch" is _local_ as in: the remote branch does not notice any changes you do here
[17:51] <benrometsch> i just like the way in git you can easily create branches locally without having to create a seperate directory structure
[17:51] <Lo-lan-do> Necoro: "in the same directory"
[17:51] <benrometsch> and then flick between then with a simple command
[17:52] <Necoro> well ... I have a shell alias for sth like this ;P
[17:52] <Necoro> "cdp branch"
[17:52] <Necoro> ^^
[17:52] <Lo-lan-do> That's what colocated branches are about, and they're at the discussion stage.
[17:52] <benrometsch> tbh the experience of playing with bazaar vs git - bzr is much nicer
[17:52] <benrometsch> cleaner OSX install, better documentation
[17:53] <benrometsch> git has been problematic for us here esp in windows
[17:54] <benrometsch> so is $remote a special keyword when branching>?
[17:54] <Necoro> eh no
[17:54] <Necoro> it is just a placeholder for the remote branch URL
[17:54] <Necoro> ;)
[17:54] <benrometsch> ok I see
[17:54] <benrometsch> just wanted to check
[17:55] <Lo-lan-do> "bzr branch <remote>", if you prefer
[17:55] <Necoro> benrometsch: btw: have you had a look at mercurial ... just to give you another option at hand in case neither bzr nor git are what you are looking for
[17:55] <Necoro> though I do not know if hg has "local branches"
[17:56] <benrometsch> yeah I just downloaded it a moment ago
[17:57] <Necoro> (the one thing I really prefer from bzr over hg and git are "revision numbers" ... not having stupid SHA-hashes one has to deal with)
[17:57] <Peng_> Necoro: Hg does have local branches, but you can't delete them once you create them. (Recently it became possible to hide them though.)
[17:58] <Necoro> Peng_: well ... not being able to delete them could be an issue ...
[17:58] <Peng_> Indeedy.
[17:59] <Peng_> Generally people use separate clones for short-lived branches, just like in bzr.
[18:00] <santagada> benrometsch: this local branch thingie might be what I was looking for
[18:00] <Necoro> and not having local branches has one advantage: you clearly see on what branch you are working on ;) - w/o having to do "git branch" or tweak your shell prompt ;)
[18:00] <santagada> keep the directory I'm working with but change the branch
[18:00] <Peng_> Though you can tweak your shell prompt if you want to.
[18:01] <Peng_> Who doesn't want "cd" to take 300ms?
[18:01] <santagada> probably just moving things around would do also
[18:01] <Necoro> Peng_: my shell prompt shows me the current bzr revno and whether there are uncommited changes ;)
[18:01] <Necoro> on larger repos I have to turn it off ^^
[18:02] <benrometsch> yeah santagada local branches are one of the things I think would really speed stuff up but I take other people's points that having directories explicitly defining branches can be useful
[18:02] <Necoro> with git it could be less problematic as it is way faster
[18:02] <santagada> the problem I see is with dev tools
[18:03] <santagada> for example textmate has the concept of project wich is a directory
[18:03] <benrometsch> yep that's what would help us - being able to just update changed files rather than having a whole new directory
[18:03] <santagada> ahh forget it... it is just an "mate ./" anyway
[18:04] <santagada> benrometsch: what ide/editor do you use?
[18:04] <jelmer> Lo-lan-do: Hi!
[18:04] <Lo-lan-do> Hi jelmer :-)
[18:04] <jelmer> Lo-lan-do, We don't really stand out from the rest of the FOSDEM crowd I think..
[18:04] <Necoro> benrometsch: if you just want to overwrite the current dir w/ another branch and do not care about local changes, "bzr pull" is your frient
[18:04] <benrometsch> intellij idea
[18:04] <Necoro> s/frient/friend/
[18:04] <jelmer> Lo-lan-do: I'll try to wear my Bazaar t-shirt at the beer event on friday
[18:05] <Lo-lan-do> 'kay
[18:06] <Necoro> (well "bzr pull --overwrite" this is actually)
[18:06] <benrometsch> Necoro: yeah that's ok but it still means I have to create another directorym then work in that, then pull back
[18:07] <benrometsch> which doesn't follow the workflow of our IDE that well
[18:07] <Necoro> benrometsch: eh no
[18:07] <benrometsch> so is hg more like git or bzr?
[18:07] <Necoro> suppose you branched URL_A - worked on it ... and then want to pull in URL_B and overwrite everything you just did
[18:07] <Necoro> bzr branch URL_A b; cd b; code ... ; bzr pull URL_B --overwrite
[18:08] <benrometsch> Yeah that's the problem tho - the cd b;code
[18:08] <benrometsch> that's not good for me
[18:08] <Necoro> but even in git, you have to create a directory in which the code exists
[18:08] <Necoro> this is not ClearCase ;P
[18:09] <benrometsch> but in git I can just say
[18:09] <benrometsch> branch <branch name>
[18:10] <benrometsch> then carry on in my IDE
[18:10] <Necoro> well ... do "bzr pull <branch name> --overwrite" (with restrictions as noted above)
[18:10] <Necoro> which does the same - replacing the current branch by another branch
[18:11] <benrometsch> what about creating a new branch
[18:11] <Necoro> well ok
[18:11] <Necoro> your point
[18:12] <benrometsch> ha ;)
[18:12] <benrometsch> ho well I'll give hg a run and see
[18:12] <benrometsch> that has local branching right>
[18:12] <benrometsch> ?
[18:13] <Necoro> according to Peng_
[18:14] <jelmer> there's a proof-of-concept plugin for bzr that provides local branching support
[18:27] <benrometsch> thanks for the help anyway
[18:30] <GaryvdM> bialix: Fixed both problems :-)
[18:30] <santagada> benrometsch: tell us what you discover... I'm interested at least
[18:30] <ronny> jelmer: does dulwitch give complete access to git via bzr apis?
[18:30] <jelmer> ronny, no, that's bzr-git (which is built using dulwich)
[18:30] <jelmer> dulwich is generic, not specific to bzr
[18:31] <jelmer> (a bit similar to bzr-svn / subvertpy)
[18:31] <ronny> jelmer: ah, so dullwich gives git ?
[18:31] <jelmer> ronny, yep
[18:32] <ronny> jelmer: its really nice how you gradually implement everything i need for anyvc
[18:32] <jelmer> ronny, :-)
[18:32] <kfogel> If anyone wants to proofread this, I'd be grateful:
[18:32] <kfogel> http://www.emacswiki.org/emacs/BzrForEmacsDevs#Regulars
[18:32] <kfogel> Trying to get those people prepared for the Big Day.
[18:33] <ronny> jelmer: does dulwich use any of git, or is ir completely independ
[18:33] <ronny> jelmer: and of course - how is the performance ;P
[18:48] <bialix> garyvdm: thanks
[18:49] <bialix> garyvdm: but it's better to not use bencode improvements
[18:49] <bialix> I have another regression with bzr 1.11
[18:50] <garyvdm> Sorry - I don't understand
[18:52] <bialix> wait a sec
[18:53] <Tak> kfogel: looks good to me
[18:54] <bialix> garyvdm: http://pastebin.com/m20409afe
[18:54] <kfogel> Tak: thank you!
[18:57] <bialix> garyvdm: I'm fixing this
[18:57] <garyvdm> bialix: Ok - Thanks
[18:57] <jelmer> ronny, it's pretty bad at the moment, but I'm working hard on fixing that
[18:58] <bialix> but another one problem bother me
[18:58] <jelmer> ronny, as is the author of pyrite (we're merging some of the code we have in common)
[18:58] <bialix> garyvdm: try to simply press OK in te password dialog when accessing lp:
[18:58] <ronny> pyrite?
[18:58] <ronny> jelmer: btw, can it be possible to add custom object types later?
[18:59] <jelmer> ronny, a Python re-implementation of Git
[18:59]  * ronny needs more than commit/tag/blob/tree
[18:59] <jelmer> ronny, completely (including command-line, etc)
[18:59] <jelmer> ronny, yeah, sure
[18:59] <bialix> I'm every time got: http://pastebin.com/m2f2d9bdd
[18:59] <bialix> spiv is not here I guess
[19:00] <jelmer> ronny, they're already separate classes at the moment, the only thing left to fix would be allowing registration of new types (type int -> class is in a dictionary at the moment)
[19:00] <bialix> spiv: when you awake, can you comment on this: http://pastebin.com/m2f2d9bdd
[19:00] <ronny> hmk
[19:00] <bialix> spiv: it's when we passing empty string instead of password while accessing lp branches
[19:01] <bialix> garyvdm: but when I do the same in the console I don't have such traceback
[19:01] <jelmer> ronny: what sort of custom objects are you looking at adding?
[19:04] <ronny> jelmer: want to split up mime messages and stuff like vcs checkouts
[19:04] <ronny> also i need object lists
[19:05] <bialix> garyvdm: what is your unfinished plans for 0.9.7? bzr 1.12 should be released next week, I need to be ready to release 0.9.7 in time wit rc1
[19:06] <garyvdm> bialix: just regression fixing.
[19:07] <garyvdm> bialix: I'm spending alot of time on lp:~qbzr-dev/qbzr/graph-refactoring - That can land after 0.9.7
[19:07] <bialix> yes please
[19:08] <bialix> garyvdm: we have something urgent?
[19:08] <ronny> jelmer: basically i want more object tpyes to deal with backups on a higher semantic level
[19:09] <jelmer> ronny: For anyvc, or is this for something entirely different?
[19:09] <ronny> jelmer: different
[19:09] <ronny> jelmer: i want a nice neat backup tool and remote syncable mailbox
[19:09] <jelmer> ronny: Ahh
[19:09] <garyvdm> bialix: what is that?
[19:10] <ronny> jelmer: ald blobs alone aint nice enough
[19:10] <bialix> sorry, do we have something urgent to be done before bzr 1.12 released?
[19:10] <garyvdm> bialix: no.
[19:10] <bialix> good
[19:11] <jelmer> ronny: new object types won't be propagated by "regular" git though (not sure if that's what you intended to do)
[19:11] <garyvdm> bialix: sorry : bug 325873
[19:11] <garyvdm> I'll squash it now.
[19:11] <bialix> um, ah
[19:12] <bialix> it has one duplicate https://bugs.launchpad.net/qbzr/+bug/323535
[19:13] <ronny> jelmer: i dont care for regular git in that case
[19:14] <ronny> jelmer: btw, does the implementation allow for multiple concurrent writers?
[19:15] <jelmer> ronny, in theory, yes (all writes should be atomic)
[19:17] <ronny> in practice ?
[19:20] <bialix> garyvdm: re your extdiff patch. what branch/version of extdiff plugin you're using/testing on?
[19:20] <garyvdm> difftools plugin?
[19:20] <jelmer> ronny, haven't stress-tested it yet
[19:21] <bialix> yep
[19:21] <ronny> jelmer: the code looks slow
[19:21] <ronny> jelmer: im thinking about implementing it in vala
[19:22] <garyvdm> bialix: lp:bzr-difftools rev 41
[19:22] <jelmer> ronny, the code hasn't been optimized yet, that's what I'm working on now. The delta resolving / delta basis cache is the main thing that needs to be fixed
[19:22] <bialix> ok
[19:23] <jelmer> ronny, if you're going to work in vala, libgit is probably a better choice
[19:23] <garyvdm> bialix: ver 0.91 if that means anything.
[19:23] <bialix> I need to write something in the news
[19:24] <ronny> jelmer: not so sure - need to see if it actually can handle object types
[19:24] <bialix> I mean for announce
[19:24] <LarstiQ> evening
[19:25] <jelmer> ronny, I think it would require some trivial patch, that could go upstream
[19:25] <jelmer> yo LarstiQ
[19:25] <LarstiQ> yo jelmer, ronny, bialix
[19:25] <bialix> yo LarstiQ!!!
[19:26]  * bialix hopes "yo" is respectable word
[19:26] <AmanicA> yo is cool
[19:26] <bialix> yo AmanicA!!!
[19:27] <AmanicA> yo yo alexander
[19:27] <bialix> :-D
[19:27] <ronny> yo LarstiQ
[19:27] <ronny> jelmer: i think a gobject based implementation of git would help
[19:28] <jelmer> ronny, what's stopping you ? :-P
[19:28] <ronny> i would be able to use thigns like quarks, dataches and other fun things
[19:28] <ronny> quarks = atomic strings reduced to a unique integer
[19:28] <LarstiQ> bialix: I doubt it is fit to address the queen with, but it's perfectly fine for me :)
[19:29] <Lo-lan-do> Depends on the queen maybe.
[19:29]  * jelmer away for food, back later
[19:29] <santagada> kfogel: theres a lather on your BzrForEmacsDevs
[19:29] <ronny> bbl
[19:29] <kfogel> santagada: "lather"?
[19:29] <santagada> yep
[19:29] <kfogel> santagada: er, do you mean a sort of froth?
[19:30] <jelmer> Lo-lan-do, I figured out the bug you reported wrt slowness
[19:30] <kfogel> Because that's not good for my computer :-).
[19:30] <Lo-lan-do> jelmer: \o/
[19:30] <santagada> kfogel: I never saw that before... It was supposed to be a later I think
[19:30] <bialix> LarstiQ: fine
[19:30] <kfogel> santagada: wow, I'm totally not understanding
[19:31] <ronny> jelmer: i need any docs availiable on the git repo format evolution
[19:31] <ronny> brb
[19:32] <santagada> kfogel: wasn't you that posted the link to http://www.emacswiki.org/emacs/BzrForEmacsDevs
[19:32] <garyvdm> bialix: I think that bug 307270 might be related to the problem I was having with ftp passwords in qbzr
[19:32] <santagada> ?
[19:32] <bialix> Gary, hmm
[19:32] <kfogel> santagada: yes, I posted that
[19:32] <kfogel> santagada: what I posted was actually:
[19:33] <garyvdm> bialix: I'll do some debuging
[19:33] <kfogel> http://www.emacswiki.org/emacs/BzrForEmacsDevs#Regulars
[19:33] <santagada> kfogel: so, there is a type in there s/lather/later
[19:33] <kfogel> santagada: aaaaah
[19:33] <kfogel> thank you
[19:33] <santagada> typo
[19:33] <bialix> garyvdm: because you're working on Linux too, may I ask you about PPA?
[19:34] <bialix> luks: are you here?
[19:34] <garyvdm> bialix: Sure - I don't know if I will be able to answer
[19:34] <bialix> garyvdm, luks: our PPA still has only 0.9.5, https://launchpad.net/~qbzr-dev/+archive/ppa
[19:34] <santagada> kfogel: and if you want some inspiration to work more on the page I can point you to a kind of the same document for python, its on http://www.python.org/dev/peps/pep-0374/
[19:35] <Necoro> does "bzr pull" does the right thing on bound branches?
[19:35] <garyvdm> bialix: Ah - I've never built a deb before - I guess now is a good time...
[19:35] <Necoro> or should one use "bzr up" instead
[19:35] <bialix> I'm mostly indifferent on this, because I'm windows guy and because I know how to run from sources, but it seems important for hardcore ubutu users
[19:36] <Necoro> if it is the latter, the EmacsForBzrDevs page should be corrected ;)
[19:37] <bialix> maybe luks can provide some instructions
[19:38] <garyvdm> bialix: Cool - I will address this.
[19:38] <kfogel> santagada: that's great, thank you
[19:38] <bialix> garyvdm: Great!
[19:38] <kfogel> Necoro: it does
[19:41] <Necoro> kfogel: ok - I tested it ... it does as long as you used "bzr branch && bzr bind" - using only "bzr checkout", it won't work except you are giving the branch again
[19:41] <kfogel> Necoro: sure.  The recipe uses branch, not checkot.
[19:41] <kfogel> checkout
[19:42] <bialix> AmanicA: I'm trying to implement new layout for scmproj control dir. I'm not sure how to detect that remote branch (w/o WT) is our control dir actually. Any ideas?
[19:42] <Necoro> kfogel: I know ;)
[19:42] <kfogel> Necoro: (I've been using that model for bzr code, and for bkrpr development, and other things, so it is tested)
[19:43] <Necoro> kfogel: any particular reason, why you are not using co && up? or is it just to keep the amount of commands to learn down?
[19:48] <kfogel> Necoro: I've never used them in bzr myself.  I'm not sure when to use them (as opposed to branch / merge / pull).
[19:50] <Necoro> ;) ok
[19:52] <LaserJock> anybody have issues with latest bzr-svn from ~bzr PPA?
[19:52] <Tak> imo there's never a good reason to use co/up with bzr
[19:52] <LaserJock> all of my branches with updates say that the branches have diverged
[19:52] <LaserJock> if you want to keep a SVN-like workflow co/up is nice
[19:53] <Tak> if you want to keep a svn-like workflow, why are you using bzr? ;-P
[19:53]  * bialix sometimes thinks this channel should be called #bzr-svn :-P
[19:53] <LarstiQ> Tak: it's a valid way to work.
[19:53] <LaserJock> Tak: people don't always have a choice
[19:53] <Lo-lan-do> Tak: Local branches while cooperating with others who don't do bzr.
[19:54] <LaserJock> some people like SVN's workflow but aren't allowed to use SVN
[19:54] <Lo-lan-do> Also, merge tracking, disconnected work, all that.
[19:54] <LarstiQ> Tak: also, trunk being a checkout usually fits well imo.
[19:55] <LarstiQ> LaserJock: see UPGRADING in bzr-svn source, jelmer said he would incorporate that into the packaging for the next upload
[19:55] <LaserJock> LarstiQ: what does that mean?
[19:56] <Tak> that was a rhetorical question...
[19:56] <LarstiQ> LaserJock: it means 0.5 uses a different svn-bzr revision mapping by default.
[19:57] <LaserJock> LarstiQ: can I use it with the older version of bzr-svn?
[19:58] <Lo-lan-do> No, which is why you should read that UPGRADING file.
[19:58] <LarstiQ> LaserJock: yes, you can set 'default-mapping = v3' in ~/.bazaar/bazaar.conf or ~/.bazaar/subversion.conf
[19:58] <bialix> garyvdm: look at recent thread about password bug in bzr.dev ML
[19:58] <LarstiQ> LaserJock: but that won't gain you any of the advantages
[19:58] <LaserJock> LarstiQ: the problem is, I use multiple bzr/bzr-svn versions on the same branches
[19:59] <LarstiQ> LaserJock: that is not a problem per se
[19:59] <LaserJock> bzr is hard enough with backwards compatibility as is, having to watch bzr-svn versions to kinda sucks
[19:59] <etenil> Hi there
[19:59]  * LarstiQ uses multiple bzr-svn versions against the same svn paths
[19:59] <LarstiQ> LaserJock: well then, I suggest you set that default-mapping
[20:00] <LaserJock> LarstiQ: you use then on the same bzr branch?
[20:00] <etenil> is branching a project the same as unbinding a checkout?
[20:01] <etenil> I started working on a checkout, but don't want to commit back to the trunk. Can I just unbind my checkout and make it a branch?
[20:01] <LarstiQ> LaserJock: no, I communicate via svn
[20:01] <Necoro> etenil: yes
[20:02] <LarstiQ> etenil: yeah
[20:02] <LarstiQ> etenil: you could also use `bzr reconfigure`
[20:02] <LaserJock> LarstiQ: ah, see that's my problem, I'm working on the same branches with multiple bzr/bzr-svn versions
[20:02] <etenil> ok
[20:02] <etenil> thanks a lot guys
[20:02] <etenil> +
[20:02] <LarstiQ> LaserJock: bzr-svn talks to svn.
[20:02] <LaserJock> LarstiQ: sometimes one version will do something that "breaks" the branch for the other version
[20:03] <LaserJock> LarstiQ: right, but different bzr-svn versions using the same branch to talk with svn sometimes gives troubles
[20:03] <LarstiQ> LaserJock: if you keep the resulting bzr branches from different bzr-svn version seperate, you have no divergence.
[20:03] <LarstiQ> LaserJock: that I haven't experienced yet.
[20:03] <garyvdm> bialix: My ftp problem - it seems like it's nothing to do with qbzr.
[20:04] <jelmer> LarstiQ, LaserJock: Only because of bugs in older bzr-svn versions
[20:04] <bialix> ah
[20:04] <LaserJock> well, I don't want to keep different bzr branches
[20:04] <garyvdm> bialix: I'm going to try somthing with bug 307270
[20:04] <LaserJock> that's kinda silly to have multiple branches of the same exact thing
[20:04] <bialix> garyvdm: I'd start to look at bzrlib CLI code at first
[20:05]  * bialix heh
[20:05] <LaserJock> ok, so can I just merge these branches and it'll "Just Work"?
[20:05] <LaserJock> or should I just start over and rebranch
[20:12] <LarstiQ> alas, LaserJock is gone
[20:16] <jam> ls
[20:16] <jam> hey all
[20:19] <GaryvdM> Hi jam
[20:20]  * fullermd waves at jam.
[20:20] <mwhudson> morning
[20:21] <bialix> hi jam
[20:22] <jam> hi bialix
[20:22] <jam> I don't think this has to do with qbzr anymore
[20:23] <jam> try doing "bzr pull lp:qbzr"
[20:23] <jam> versus just doing "bzr pull"
[20:23] <jam> The former also gets the traceback for me
[20:23] <bialix> jam, GaryvdM trying to debug this problem
[20:23] <beuno> jam, hi, do you know how I can avoid getting into this situation?  http://paste.ubuntu.com/114010/
[20:24] <jam> beuno: well, you renamed all of them
[20:24] <jam> at least here where the encoding isn't hiding things:
[20:24] <jam> Autobus 2 pisos ingl?s
[20:24] <jam> != Autobus 2 pisos ingle?s
[20:24] <jam> beuno: I'm guessing you are on Mac OS
[20:24] <jam> doing a checkout from someone who used linux
[20:25] <jam> and on linux they checked in a file with e + accent
[20:25] <beuno> jam, windows
[20:25] <jam> which is a single char
[20:25] <jam> or windows
[20:25] <jam> doesn't matter
[20:25] <beuno> well, actually, yes, it was committed on linux
[20:25] <jam> on linux or windows e + ' is a single char
[20:25] <jam> on Mac, e + ' is 2 characters
[20:25] <jam> (mac *conveniently* renames files for us)
[20:25] <beuno> well, actually, yes, it was committed on linux
[20:26] <jam> are you on windows now?
[20:26] <beuno> nope
[20:26] <jam> As that would be unexpected behavior
[20:26] <jam> you are on Mac now, right?
[20:26] <beuno> in brazil, 400km away from the rpnolem  :)
[20:26] <beuno> er, problem
[20:26] <jam> so the *problem* is that Mac OS automatically renames files with "combining characters" for us
[20:27] <beuno> right
[20:27] <jam> when everyone else just leaves them alone
[20:27] <Lo-lan-do> jam: Actually, I think everyone else converts to one combined character.
[20:28] <Lo-lan-do> From what I've read, Linux and Windows automatically rename files to the canonical form A, Mac OS renames to canonical form B.
[20:29] <Lo-lan-do> (Replace A and B by their actual names)
[20:29] <beuno> jam, so no way around it?
[20:29] <Peng_> Lo-lan-do: Composed and decomposed?
[20:29] <Peng_> Or something.
[20:29] <Lo-lan-do> Peng_: Something like that, yes.  So that would be forms C and D :-)
[20:29] <Peng_> "Decomposed" sounds too zombie.
[20:30] <jam> Lo-lan-do: from my experiments
[20:30] <jam> linux and windows do nothing
[20:30] <jam> but the standard usage when someone is typing is
[20:30] <jam> NFC
[20:30] <jam> (which is also the XML standard)
[20:30] <jam> and Mac decided on a variant of NFD
[20:30] <jam> (I think it is close, but not exactly NFD)
[20:31] <jam> beuno: you could use a really old version of bzr with an old format repository and working tree, back when I actually tried to make that sort of thing work
[20:31] <jam> alternatively, rename all of the files manually
[20:32] <jam> ( I think cut & paste will work here)
[20:32] <jam> commit it
[20:32] <jam> and then when they update on Linux all of the files will be in NFD
[20:33] <beuno> jam, I'll start renaming it then  :)
[20:33] <jam> note that on Linux and Windows, NFD forms often look like crap
[20:33] <jam> depending on your Unicode implementation
[20:33] <jam> on Windows you tend to get "e[]"
[20:34] <jam> that may be better in newer versions
[20:34] <jam> it was the case in XP, IIRC
[20:34] <jam> Eventually we might be able to take the "case-insensitivity" work that mhammond has worked on
[20:34] <beuno> no matter, it'll teach people to stop using freaking accents
[20:34] <jam> and apply it to unicode normalization
[20:35] <jam> at one point I had been making things work by assuming everywhere != Mac was NFC
[20:35] <jam> and then translating 'on-the-fly'
[20:35] <GaryvdM> baltix: I'm going to make the SubprocessUIFactory raise a KeyboardInterrupt if the user canceled, and in the main process, not call the normal abort, but just clear the process queue.
[20:35] <jam> the problem was that it turned out that Windows liked to used mixed encodings
[20:35] <jam> IIRC
[20:35] <jam> GaryvdM: I think qbzr is fine
[20:35] <jam> GaryvdM: "bzr pull lp:bzr" gives the same "toomanyconnections" traceback
[20:36] <jam> It has to do with "read_mergeable_from_url", I believe
[20:36] <GaryvdM> baltix: Then we won't see that traceback if the user presses cancel - only if they press ok with blank password
[20:37] <LarstiQ> GaryvdM: do you mean bialix instead of baltix?
[20:37] <jam> ah, I've tracked it down
[20:37] <jam> read_mergable_from_url raises an exception, but still populates the "possible_transports" list
[20:37] <GaryvdM> jam: if you "bzr pull lp:bzr" and press ctrl-c you don't get the traceback - qbzr should do that if you press cancel in the ui.
[20:37] <jam> the exception is trapped at a higher level
[20:38] <jam> GaryvdM: sure with ^C you could just raise KeyboardInterrupt in the client
[20:38] <GaryvdM> LarstiQ: Yes - thanks.
[20:38] <jam> but just hitting "<enter>" the bug is in bzr
[20:38] <bialix> GaryvdM: with Cancel we don't have any problem now
[20:38] <bialix> only with blank/incorretc password
[20:39] <bialix> I guess transport raises some error when it cannot connect?
[20:40] <GaryvdM> bialix: Ah - Ok - then I'm not going to make that change.
[20:44] <bialix> jam: yes, you're right about ...mergeable
[20:44] <jam> bialix: I'm posting a fix
[20:44] <bialix> so it's bzr bug then
[20:44] <jam> the exception is bzr, yes
[20:44] <bialix> jam: thank you very much!
[20:45] <bialix> Gary: jam said it's the bug in bzr itself
[20:47] <garyvdm> bialix: Yes - but I thought that we went handling the cancel correctly.
[20:47] <bialix> sorry?
[20:48] <bialix> garyvdm: I guess we do it correctly, is it not?
[20:48] <garyvdm> bialix: Yes
[20:48] <bialix> ok
[20:56] <jam> garyvdm: translating ESC in the qbzr dialog into ^C in the client seems reasonable to me
[20:56] <garyvdm> jam: We do that by sending a SIGINT from the main process.
[20:57] <jam> k
[20:59] <garyvdm> jam, bialix: Still, might be better to raise KeyboardInterupt in the sub process. The sub process allready knows if the user pressed ok or cancel, and by doing it that way we rule out any delay in the signal being received.
[21:00] <bialix> jam: can you suggest most efficient way to detect is remote branch (without WT) has some specific file?
[21:01] <jam> bialix: something like:
[21:01] <jam> remote = Branch.open(location)
[21:01] <bialix> garyvdm: I don't follow. Is not we already do this?
[21:01] <jam> remote.lock_read()
[21:01] <jam> rt = remote.repository.revision_tree(remote.last_revision())
[21:01] <jam> rt.path2id(filename)
[21:02] <jam> if that is None, then the path doesn't exist
[21:02] <poolie> hello jam, bialix
[21:02] <kfogel> santagada: "lather" is correct there
[21:02] <jam> hi poolie
[21:02] <bialix> hello poolie
[21:02] <kfogel> santagada: "lather, rinse, repeat" is a stock phrase meaning to go through the same cycle again; it refers to washing clothing.
[21:02] <bialix> jam: thanks
[21:03] <bialix> I suspect something about inventory
[21:03] <garyvdm> bialix: No - at the moment, the main process writes to the stdin, and then sends SIGINT on unix and the event on Windows
[21:03] <jam> kfogel: I thought it had to do with shampoo
[21:03] <jam> since they generally say exactly that on the bottle
[21:04] <jam> which is an infinite loop
[21:04] <jam> :)
[21:04] <jam> or at least, they used to
[21:04] <fullermd> That's why it takes me hours to wash my hair.
[21:04] <bialix> garyvdm: what's wrong then?
[21:04] <kfogel> jam: oh, wait, you're right
[21:04] <jam> fullermd: until you pass out ?
[21:04] <Lo-lan-do> Until there's no shampoo left?
[21:04] <fullermd> Well, eventually you run out of shampoo...
[21:04] <bialix> :-D
[21:05] <fullermd> That qualifies as a NMI and breaks the loop   :p
[21:06] <garyvdm> bialix: There may be a delay in the signal/event being received, and so the sub process might do more than necessary.
[21:06] <bialix> NMI?
[21:07] <garyvdm> http://en.wikipedia.org/wiki/Non-maskable_interrupt
[21:07] <garyvdm> Had to look it up myself :-)
[21:07] <jam> fullermd: I would think passing out would also qualify as an NMI
[21:07] <bialix> lol, hardware things, I like it
[21:07] <poolie> jam, want to talk?
[21:08] <bialix> garyvdm: you has recently fixed the problem with cancel (revno 595)
[21:08] <fullermd> Depends on whether the shower curtain slows you before your head hits the tile...
[21:08] <garyvdm> bialix: It work, but it can be better.
[21:08] <bialix> garyvdm: if subprocess waits for the password I don't think it will do more than that
[21:09] <bialix> but not worse for win32 please!
[21:09] <bialix> :-)
[21:10] <garyvdm> bialix: Currently we write the qbzr:GETPASS: message to the stdin before we send the event.
[21:10] <bialix> garyvdm: yes
[21:11] <garyvdm> bialix: I'll make sure it's better :-)
[21:11] <bialix> garyvdm: ok :-)
[21:11] <bialix> just a thoughts: why bzr-gtk is not released anymore?
[21:12] <bialix> it reached the top?
[21:14] <ronny> re
[21:14] <santagada> kfogel: living and learning.... I never heard that expression before, only "rinse and repeat"
[21:17] <ronny> hmm
[21:17] <ronny> back to python
[21:17] <ronny> jelmer: anything i can do for dulwich?
[21:20] <bialix> garyvdm: we can send the event before we send the bencoded message, maybe you have in mind this?
[21:21] <garyvdm> bialix: I think it will be much more reliable to raise the KeyboardInterupt in the subprocess if accepted == False
[21:22] <bialix> garyvdm: do you mean after receiving bencoded string?
[21:22] <garyvdm> Yes
[21:22] <bialix> please, don't use accepted == False
[21:22] <ronny> jelmer: how do legacy/new style git objects work out?
[21:22] <bialix> just `not accepted`
[21:23] <garyvdm> bialix: Yes
[21:24] <bialix> garyvdm: I think I understand your intent better now, thank you for explanation
[21:25] <garyvdm> bialix: I'm going to also try fix bug 325924 before we release
[21:25] <jelmer> ronny: They should work; I've never encountered them though, James implemented them.
[21:25] <ronny> oO
[21:25] <bialix> ok
[21:26] <ronny> jelmer: whats the difference?
[21:26] <jelmer> ronny, a different object header afaik
[21:27] <bialix> jelmer: I'm just curious: what is the status of bzr-gtk now?
[21:27] <ronny> jelmer: what james did implement them?
[21:27] <ronny> ie is he here
[21:27] <jelmer> ronny: In terms of todo-items, I think one of the things that needs more work is the index
[21:27] <jelmer> ronny, it's james_w
[21:28] <ronny> james_w: can you point me to some docs about the evolution ofthe git repo format?
[21:31] <jelmer> ronny, I think the main docs are the C source files
[21:32] <jelmer> bialix, pretty similar to what it was a while ago
[21:32] <ronny> hmm :/
[21:32] <bialix> jelmer: the lack of man power?
[21:33] <jelmer> bialix: yeah
[21:33] <bialix> I understand
[21:33] <lifeless> jelmer: btw, branch.nick is likely what is connecting to the master
[21:33] <lifeless> jelmer: its used for the window title, or used to be
[21:33] <jelmer> lifeless, ahh
[21:33] <jelmer> lifeless: That would indeed be it
[21:33] <ronny> jelmer: the whole object parsing stuff in dunwich looks like please use c instead of python for 20x speedup
[21:33] <bialix> we have similar bug in QBzr
[21:33] <bialix> s/have/had/
[21:34] <jelmer> ronny, the delta apply stuff can be optimized a lot by avoiding string copies
[21:34] <ronny> hmm
[21:34] <jelmer> ronny, plus, we don't do lru caching of delta bases yet (which git does)
[21:34] <ronny> hmm
[21:34] <jelmer> I'm not necessarily opposed to having a faster implementation in C
[21:35] <jelmer> (or pyrex)
[21:35] <lifeless> what about putting such a thing in libgit2 then linking to that from pyrex/CPython
[21:36] <Jc2k> +1
[21:36] <ronny> jelmer: i want to implement a semilar api in vala, then map to python via a binding or pybank
[21:36] <Jc2k> libgit2 is horribly unfinished right now, i bet they'd love some help bringing it up to speed
[21:37] <Jc2k> i started writing git in vala, but it turned into something else (git sucks for our 'personal cloud'/backup/sync/everything is versioned monster use case)
[21:37] <jelmer> I wouldn't want to blame dulwich's current slowness on Python though
[21:39] <ronny> jelmer: the parsing uses patterns that have much overhead in python compared to plain c
[21:39] <xnox> Hello everyone! Is it possible to shelve something and then unshelve in another branch? All branches are in the shared repo.
[21:40] <ronny> Jc2k: what was that again?
[21:43] <lifeless> ronny: everything in python has a lot of overhead compared to C :P
[21:43] <Jc2k> ronny: a project im working on which is still vaporware so im reluctant to talk about too much :)
[21:43] <lifeless> ronny: its just that python doesn't stab you in the face 5 times a line of code
[21:43] <jam> xnox: you can copy the .shelf directory around, but you could also "bzr merge --uncommitted ../other" and then bzr revert ../other
[21:44] <Jc2k> ronny: theres a hackfest on it after FOSDEM where we are going to suck juergbi's brain out threw a straw :)
[21:45] <ronny> when/where is fosdem again
[21:45] <ronny> i might have to visit
[21:45] <Jc2k> belgium, this weekend
[21:47] <ronny> this already
[21:47] <ronny> then i cant come
[21:47] <Jc2k> sucks :(
[21:49] <jelmer> lifeless, btw, I managed to implement a working BranchBzrDirInter
[21:49] <lifeless> jelmer: nice
[21:49] <jelmer> Looks like I can kill off all svn-* commands except for svn-import soon
[21:49] <lifeless> jelmer: <3
[21:55] <xnox> jam: thanks that's what I needed =D
[21:55]  * xnox likes bzr better than git. Farewell my first ever learned vcs. You have served well git =D
[21:56] <lifeless> back shortly, breaking ze fast
[22:43] <Haffi___> Hi, how do I keep a file from being in source control in bazaar?
[22:47] <garyvdm> Haffi___: bzr ignore filename
[22:48] <Haffi___> Haha, figures
[22:49] <Haffi___> I hate when programs have sensible command names, it makes me look dumb when I ask questions in IRC chatrooms...
[22:58] <lifeless> poolie: also, I would really appreciate any comment on my fetch-history-bug-issue, I mailed about yesterday morning
[22:59] <lifeless> poolie: groupcompress is basically blocked at the moment on that
[23:00] <johnf1> I know I'm probably not the first to complain but I'm willing to put in time to make it happen. What is needed to ensure that the bzr PPAs always keep bzr,bzrtools and bzr-svn in sync?
[23:00] <lifeless> johnf1: do you know how to do debian packaging ?
[23:00] <johnf1> yes
[23:00] <lifeless> johnf1: in our docs there is a ppa document
[23:00] <johnf1> yep just read it
[23:01] <lifeless> johnf1: start by reading that; I suspect that making sure the beta has matching versions leading up to a release will be a good start (catches bugs)
[23:01] <lifeless> then when the release happens, if you wanted to do the uploads yourself, for instance, you could upload all of them
[23:01] <lifeless> but some of the trouble is 'ppa'
[23:01] <lifeless> because it doesn't act like a debian repo, apt will wedge and try to remove rather than waiting for the full upgrade to be possible
[23:02] <johnf1> yeah it seems in a strange state at the motion eg beta has a bzrtool 1.11 package but only for dapper
[23:03] <lifeless> johnf1: we would be delighted if you wanted to dive in and focus on this
[23:03] <lifeless> there is a lp team you should join
[23:03] <lifeless> to get upload accecss to the ppa
[23:04] <johnf1> ok It's on my TODO list for this arvo
[23:05] <lifeless> schweet
[23:05] <lifeless> ping me anytime
[23:05] <poolie> spiv, lifeless: thanks for the summary from yesterday, that sounded good
[23:06] <poolie> i don't have any particular technical feedback
[23:06] <poolie> i am also interested though in how we're organizing work on hpss
[23:06] <lifeless> cool, it fitted so well I didn't expect anything :)
[23:06] <lifeless> organising? hmm, you can do that :P
[23:06] <jelmer> is there any equivalent to self.outf for stderr?
[23:06] <poolie> it seems like it goes more than twice as fast when someone else is pairing with spiv
[23:06] <lifeless> jelmer: trace.note I think
[23:07] <poolie> jelmer: not directly; i guess generally you should go through trace
[23:07] <jelmer> ok
[23:07] <jelmer> lifeless, poolie: Thanks
[23:08] <lifeless> well, this stuff is a refactoring I've been mumbling about onlist for about 9 months now
[23:08] <lifeless> so we didn't do much guessing
[23:09] <lifeless> certainly the serialisation work he's been doing is needed to line up with this, really just a case of glueing the two ends together now I hope
[23:10] <poolie> jam, if you're still around
[23:10] <poolie> should we leave kerguelen in its semi-broken state?
[23:11] <poolie> or ask them to reinstall it?
[23:11] <lifeless> igc: ping
[23:11] <poolie> or, alternative, put it on a machine we completely control somewhere else
[23:11] <poolie> inside vmware say
[23:50] <jml> spiv: ping
[23:50] <jml> spiv: Can you please update https://bugs.edge.launchpad.net/bzr/+bug/255292 ?
[23:51] <spiv> jml: ok
[23:54] <mwhudson> btw
[23:54] <mwhudson> i've seen that one a few times now
[23:55] <mwhudson> not in a useful way, of course :/