[01:00] <fbond> When I do bzr combine-thread, I lose a reference to a head revision.
[01:00] <fbond> How can I get it back?
[01:41] <lifeless> fbond: bzr heads --dead
[01:41] <lifeless> and then branch with -r revid:<revid>
[01:41] <lifeless> fbond: but why are you deleting threads that are heads?
[01:54] <jfroy> jelmer: ping+
[01:57] <fbond> lifeless: Maybe I'm using the wrong words.
[01:57] <fbond> I guess that's my problem.
[01:57] <fbond> It *wasn't* a head.
[01:58] <fbond> I tried bzr heads, but only found a single revision that I didn't really care about.
[02:07] <fbond> lifeless: For some reason, I can't help but think of threads as branches with a tip.  But that's wrong, huh?
[02:08] <SKArfaceGC> general usage question: when would I use pull instead of merge?
[02:08] <SKArfaceGC> i.e. what does pull do that merge doesnt?
[02:08] <Peng_> SKArfaceGC: When you have a mirror of a branch.
[02:09] <SKArfaceGC> Peng_: ok, so it's mainly for copying a branch and be able to keep it updated.  i.e. pull a branch into a public_html directory to publish a website?
[02:10] <SKArfaceGC> is it different than running update on a checkout?
[02:13] <Peng_> SKArfaceGC: It's basically equivalent, but branches and checkouts are different things.
[02:13] <Peng_> Omg, brisbane-core got merged to bzr.dev! Awesome! :D
[02:13] <Peng_> A few revisions got left out, though.
[02:14] <SKArfaceGC> one more... is a branch that I've bound to it's parent any different than a checkout?  conversly, is a checkout that I've unbound different than a branch?
[02:15] <Peng_> SKArfaceGC: Bound branches are another name for checkouts. Unbound branches are regular old branches.
[02:15] <SKArfaceGC> perfect.  Than I actually do understand what I think I understand.  Thanks   :)
[02:18] <Peng_> :)
[05:44] <lifeless> fbond: well its right to the extent that each thread has a tip; but in a normal loom all the threads are merged upwards most of the time, so there is still usually only one head
[05:45] <lifeless> fbond: bzr log in the top thread will all the heads
[05:52] <lifeless> jelmer_: so why do you want to drop sqlite?
[07:59] <vila> hi all
[08:00] <vila> jelmer_: putting webdav into core has been proposed by poolie and is considered but not done yet ;)
[11:46] <jelmer> jfroy: hi
[11:46] <jelmer> vila: thanks
[11:47] <jelmer> lifeless: bug 185200
[11:49] <lifeless> jelmer: do you know, how friendly is the new gnome vfs thingy
[11:50] <lifeless> the old one was rather ugly
[11:52] <jelmer> lifeless: I haven't looked at it closely yet
[11:52] <lifeless> oh god
[11:52] <lifeless> I just started to look closely
[11:53] <lifeless> it depends on out of process, dbus rpcs to use the file system
[11:53] <lifeless> http://library.gnome.org/devel/gio/stable/ch01.html
[11:54] <jelmer> lifeless: it wants to be able to use GPL'ed libraries in LGPL'ed libs
[11:54] <lifeless> hmm, I really need to sit down and do the rejiggering of your liballocevent or whatever you called it and libevent
[11:54] <jelmer> ah, libtevent :-)
[11:54] <lifeless> jelmer: thats not the reason they give, and if so, thats trying to do an end run around the GPL, which I *do not* approve of
[11:55] <lifeless> if someone doesn't want their code used in non GPL apps, it shouldn't be used in non GPL apps.
[11:55] <jelmer> lifeless: it seems to me like that's at least one of the reasons
[11:55] <jelmer> (libsmbclient is GPL, and libgvfs is LGPL)
[11:55] <lifeless> so
[11:56] <lifeless> I think its time I wrote a C VFS
[11:56] <lifeless> an async C VFS
[11:56] <lifeless> because I like pain
[11:56] <lifeless> where is the libtevent source? I'm going to compare/prod it and libevent
[11:56] <jelmer> Samba's git repository, in lib/tevent
[11:57] <Peng_> libev?
[11:57] <lifeless> url please
[11:57] <jelmer> git://git.samba.org/samba.git
[11:57] <lifeless> jelmer: no http viewer?
[11:57] <jelmer> oh, probably
[11:57] <jelmer> http://gitweb.samba.org/
[11:57] <lifeless> Peng_: hmm, better than libevent?
[11:58] <Peng_> lifeless: I've never used either one, but libev was designed to be faster and have a better API. Plus it has a libevent-like API for lazy people.
[11:58] <lifeless> jelmer: ok, still lost. can you give me the url to view the source please
[11:59] <lifeless> Peng_: ok; IME when people claim that its 50-50 whether they are right or wrong :)
[12:00] <jelmer> lifeless: try "apt-get source tevent"
[12:00] <jelmer> :-)
[12:00] <Peng_> lifeless: Right. I just wanted to put it on your radar. :)
[12:00] <lifeless> jelmer: heh; so you can't find it in the web ui either
[12:00] <lifeless> Peng_: I'd almost use ACE, except its hugely overcomplicated
[12:02] <lifeless> jelmer: what did you think of my rewrite of the subunit README?
[12:02] <lifeless> jelmer: is there a tevent man page?
[12:03] <jelmer> lifeless: haven't seen it yet, not done my mail readin for the day yet
[12:03] <lifeless> jelmer: kk
[12:03] <jelmer> lifeless: no, most of the documentation is in the main header file
[12:03] <lifeless> k
[12:04] <lifeless> so what I want to exist is a good clean minimal extendable nonblocking [as opposed to async] C VFS
[12:04] <Peng_> jelmer: BTW, um. Did you know you left a couple pdb bits in bzr-svn's test_repository.py (in both 0.5 and 0.6)?
[12:05] <lifeless> with that in existence, people can write async or sync on top
[12:05] <jelmer> Peng_: Are you sure you're looking at current sources?
[12:05] <lifeless> jelmer: don't suppose you happen to know if such a beast exists?
[12:05] <jelmer> Peng_: ganieda:~/bzr-svn/0.6% grep pdb tests/*.py | wc -l
[12:05] <jelmer> 0
[12:05]  * Peng_ pulls
[12:06] <Peng_> jelmer: grep pdb tests/*/*.py
[12:07] <jelmer> lifeless: I'm not aware of one
[12:07] <lifeless> probably cause its hard.
[12:07] <lifeless> right, time for a bit by bit hobby project
[12:07] <jelmer> lifeless: :-)
[12:07] <lifeless> interested?
[12:08] <lifeless> oh, and fortunately, noone seems to have taken libvfs, at least not according to apt-cache search
[12:09] <jelmer> I'm not sure, I try to stay away from the file system bits in Samba generally :-)
[12:09] <Peng_> jelmer: Err, sorry. I didn't know there was a tests/test_repository.py. I meant tests/mapping_implementations/test_repository.py.
[12:09] <lifeless> jelmer: :>
[12:10] <lifeless> jelmer: my feeling is the reason that there are a bazillion different bad vfs' out there is because everyone is building them half-baked, so they play bad with threads, or with async, or with networks
[12:10] <lifeless> I don't mean bad code, I mean their design principles are such that the product isn't reusable in many contexts
[12:11] <jelmer> lifeless: You might want to talk to tridge about this, he's done quite some async work in Samba
[12:12] <lifeless> I would but he's not online :)
[12:12] <lifeless> I'll get my basic interest and notes together, then we can see
[12:15] <jelmer> lifeless: IIRC there were also still problems with the kernel support
[12:15] <jelmer> lifeless: (there is no way to make "open" non-blocking, ?)
[12:16] <lifeless> its hard to argue that the kernel should be fixed when there is no userland that can represent it
[12:17] <lifeless> from a VFS perspective you need: an interface that balances easy to use with getting the most out of good underlying facilities
[12:17] <jelmer> chicken-egg :-)
[12:17] <lifeless> then you can use threads or even helper processes over e.g. dbus, to get a non-blocking open
[12:18] <jelmer> lifeless: yeah, that's one of the things that's been talked about for Samba IIRC (helper processes)
[12:18] <lifeless> as long as client code can go 'for path in paths: pending_open = vfs_open(ctx, path)'
[12:18] <lifeless> squid uses a helper to do IO on BSD systems
[12:18] <jelmer> lifeless: anyway, my memory is all a big vague about this, you should really talk to tridge :-)
[12:18] <lifeless> ('diskd')
[12:19] <lifeless> on windows you can use completion ports to get nonblocking open
[12:19] <lifeless> the os calls back in on the next event loop cycle
[12:21] <jelmer> lifeless: any chance you can re-review my InterBranch.pull patch?
[12:21] <lifeless> remind me tuesday
[12:21] <lifeless> (its easter :P)
[12:21] <jelmer> ok
[12:22] <jelmer> lifeless: ah, ok
[12:26]  * jelmer is looking at git -> git pull today
[12:32] <lifeless> jelmer: having looked at tevent, I still think you'd be better off wrapping libev
[12:32] <lifeless> or libevent
[12:32] <jelmer> lifeless: Oh, I've never said we weren't
[12:33] <jelmer> lifeless: My day only has 24 hours though
[12:33] <lifeless> well thats true
[12:33] <lifeless> but you were rather dismissive of potential benefits when I raised this
[12:33] <jelmer> lifeless: the benefits are minimal
[12:33] <lifeless> I rather suspect they are more than you think
[12:33] <jelmer> lifeless: compared to the required investment
[12:33] <lifeless> perhaps
[12:34] <jelmer> lifeless: what would the benefit be, other than the fact that we have less code to maintain and fix bugs in?
[12:35] <lifeless> thats rather a big win in itself; but you would get the features from the library you wrap (both support quite a bit more), and they are likely more scalable FWICT
[12:38] <jelmer> lifeless: what sort of features does libtevent not have? last time I looked libevent lacked a couple of things that libtevent needed
[12:40] <lifeless> libevent may have nothing; libev is much more featureful
[12:40] <lifeless> child process watching, inotify support, that sort of thing
[12:40] <lifeless> signal reflection
[12:43] <jelmer> why do you need special inotify support, isn't that just waiting for a fd to become readable?
[12:43] <lifeless> shrug
[12:43] <lifeless> I'm not saying you should go change tomorrow
[12:44] <lifeless> I'd need to do a whole bunch more reading to make a strong case; and as the samba team clearly have more pressing concerns its not exactly a wise use of time to do that
[12:44] <lifeless> the key thing for me was looking at it now, and deciding that even if I use talloc internally in libvfs, I feel happier binding to libev, at least for now.
[12:47] <jelmer> makes sense
[13:09] <jelmer> lifeless: readme looks good
[13:09] <jelmer> looking forward to seeing that check patch land
[13:10] <lifeless> jelmer: me too
[13:22] <jelmer> woot, "bzr pull" from git into git works \o/
[13:23] <lifeless> grats
[13:24] <lifeless> oh bugger
[13:25] <lifeless> I think I just pushed a development6-rich-root repo to LP :P
[13:26] <fbond> lifeless: bzr log in the top thread will show all tip revisions, but how can I tell which revisions they are?
[13:26] <lifeless> by their branch nick
[13:27] <lifeless> they get the nick from the thread
[14:15] <lifeless> don't you hate it when you end up recursing to solve a problem
[14:16] <vila> :-) As in: 'I want to do X, but first I need to fix Y, but to fix Y I need to fix Z' ?
[14:24] <lifeless> yes
[14:24] <lifeless> find a URL library that isn't part of an http client
[14:24] <lifeless> for C
[14:24] <lifeless> kgo
[14:26] <vila> may be in an xml library ? :-}
[14:27]  * lifeless spanks vila
[14:27] <lifeless> time to register another launchpad project
[14:45] <jelmer> hmm
[14:45]  * jelmer wonders if he could finish colocated branches in time for 1.15..
[14:47] <jelmer> are there any plans to have loom support in core (even if just the infrastructure so we could have a common format) ?
[14:48] <lifeless> I'm not at all sure colocated branches _could_ have a common format with loom
[14:48] <lifeless> as loom threads cannot have different push locations etc etc
[14:48] <lifeless> nor do you [want or need I imagine] pending-merges on multiple branches stored at once
[14:49] <jelmer> I'm not saying they should necessarily have a common format
[14:49] <jelmer> but each of those changes will mean format changes
[14:49] <jelmer> and it seems reasonable to bundle those to avoid users from having too many upgrades
[14:50] <lifeless> I'm not currently convinced that colocated branches are the answer to the issues we have
[14:50] <jelmer> sorry, I should've specified common better
[14:50] <lifeless> they are *an* answer to be sure
[14:50] <lifeless> I encourage you to discuss the problem more on the list - that would be good
[14:50] <jelmer> I prefer colocated branches to the alternatives I've seen
[14:50] <jelmer> personally
[14:51] <lifeless> I think its a neither-fish-nor-fowl situation
[14:51] <lifeless> I'd rather we choose
[14:52] <lifeless> if branches are colocated, repositories are hard to justify, so we should look at ripping the separated-repo facilities out or evaluating why we can't do that, and so on
[14:52] <lifeless> if repositories are still useful, then we'll have non-colocated branches in repositories, and we aren't we making them as easy to work with
[14:53] <jelmer> s/repositories/shared repositories/ ?
[14:53] <lifeless> yes
[14:53] <lifeless> anyhow
[14:53] <lifeless> midnightis
[14:53] <lifeless> -> sleep
[14:54] <lifeless> also, launchpad.net/liburl and libvfs :P
[14:54] <lifeless> because the world needs more skeleton projects
[14:54] <jelmer> lifeless: that doesn
[14:55] <jelmer> 't help me in the near future though, nor does it help with foreign git repositories
[14:55] <jelmer> lifeless: 'night
[16:12] <vds> on my jaunty bzr hangs when I do pqm-submit to launchpad, if I stop it after a while with ^C I don't get any useful info
[16:17] <joschan> Hi. I am just having a little accident - I said "bzr revert" in the root folder if a live website. It seems all changes after the last commit are gone. Is this what revert normally does?
[16:18] <joschan> And is it somehow possible to get the latest version in the live fodlers (that was never commited) back?
[16:20] <joschan> it seems the old versions of changed files were copied as oldname.~1~
[16:22] <joschan> and new files were not deleted
[16:23] <joschan> i will re-rename manually and commit again
[16:47] <jelmer> joschan: yes, that's the intended behaviour of bzr revert
[16:48] <jelmer> vila: thanks!
[16:53] <vila> jelmer: np, are you going to do fallback credential store ?
[16:54] <SamB> hmm
[16:56] <vila> jelmer: I just tought about it and I think we need a way to desactivate it without uninstalling bzr-svn for example (if only for debug purposes)
[16:59] <joschan> jelmer thank you
[16:59]  * SamB wonders what is with the link: * http://starship.python.net/crew/mwh/bzrlibapi-oe/  (editable version)
[17:01] <jelmer> SamB: editable ?
[17:01] <jelmer> vila: yeah
[17:04] <vila> SamB: I get a 503, but mwh sounds a lot like mwhudson to me
[17:06] <SamB> well, I guess I'm wondering whether I should delete it from the BzrLib node ...
[17:07] <jelmer> SamB: I think it should be without -oe
[17:07] <SamB> jelmer: there's a link like that too
[17:07] <SamB> which actually works
[17:08] <SamB> what configuration does mwh use to generate this ?
[18:21] <jkakar> Is there a reason 'added', 'modified' and 'unknowns' are hidden commands?  I use them all the time and only just noticed that they're hidden commands (as a result, they don't tab complete).
[18:25] <jfroy> jelmer: If you pinged me back, I couldn't see your message as it went past the scrollback buffer. But I just wanted to let you know your bzr branch has been working pretty well, even though push still seems to not work quite right for new branches.
[18:47]  * SamB wonders why the files in doc/developers don't seem to be set up to activate rst-mode in emacs ...
[18:48] <jelmer> jfroy: hi
[18:48] <jelmer> jfroy: Ah, cool
[18:48] <jelmer> jfroy: Can you elaborate on "seems to not work quite right" ?
[18:49] <jfroy> bzr was unable to create a new branch, even with --create-prefix. I had to use svn mkdir to create the destination directory, then push --overwrite
[18:50] <jelmer> jfroy: hmm, odd
[18:50] <jfroy> creating a new branch -> push a bzr branch to svn
[18:50] <jelmer> jfroy: --create-prefix would only help if one of the parent directories of the target branch didn't exist yet
[18:50] <jelmer> jfroy: e.g. if you push to /branches/foo and /branches doesn't exist yet
[18:51] <jfroy> right, which was the case
[18:51] <jfroy> (new project, pushing its initial trunk basically)
[18:52] <jfroy> commit.py:593 raised MissingPrefix
[18:52] <jfroy> (even with --create-prefix, that is)
[18:54] <jelmer> jfroy: and did creating just /branches and then pushing /branches/foo work?
[18:54] <jfroy> I didn't try that
[18:55] <jfroy> I was pushing to <host>/<prefix>/<project name (does not exists)>/trunk
[18:55] <jelmer> jfroy: please file a bug
[18:56] <jfroy> Will do, as always :)
[18:56] <jelmer> jfroy: It looks like this requires a change from bzr as well as from bzr-svn
[19:03] <BUGabundo> hey
[19:03] <BUGabundo> need your help again
[19:03] <BUGabundo> how do I restore the content of an entire folder?
[19:04] <BUGabundo> system crashed and I last all files in that dir, so need to restore from last bzr commit
[19:24] <jelmer> BUGabundo: bzr revert <foldername> should create it again if it existed in the last commit
[19:27] <jelmer> vila: still there?
[19:28] <vila> jelmer: not for long but yes :)
[19:30]  * SamB wonders why the heck he still has Python 1.5 installed ... probably Red Hat's fault somehow ...
[19:36] <BUGabundo1> sorry.. I'm back... second system crash
[19:43] <jelmer> vila: So, I'm trying to decide whether to add a new object for the fallback credentials
[19:44] <jelmer> vila: or whether to reuse (and extend) CredentialStore
[19:44] <vila> I think adding a fallback parameter to the register funcs should be enough
[19:44] <jelmer> ok, so just "fallback=True" during registration
[19:44] <jelmer> and requiring the object to provide a "get_credentials()" method if fallback=True?
[19:46] <vila> sounds reasonable
[19:46] <vila> now, do we want to allow more than one ?
[19:46] <vila> if yes in which order are they tried ?
[19:46] <vila> let's start by allowing only one :)
[19:47] <jelmer> vila: can't we just allow multiple in the order they are registered?
[19:47] <vila> and the first returning a credential wins ?
[19:47] <jelmer> that seems easiest, since we could just walk the registry rather than remember which one was special
[19:47] <jelmer> vila: yeah
[19:48] <BUGabundo1> how do I restore the content of an entire folder?
[19:48] <BUGabundo1> system crashed and I last all files in that dir, so need to restore from last bzr commit
[19:48] <vila> again, sounds reasonable
[19:48]  * BUGabundo1 I know repeating is bad :\
[19:48] <vila> sorry BUGabundo1, I was replying to to jelemer :-/
[19:49] <BUGabundo1> I know vila
[19:49] <jelmer> BUGabundo1: bzr revert <foldername> should do that
[19:49] <jelmer> vila: ok, I guess I should get to work then :-)
[19:50] <BUGabundo1> jelmer thanks
[19:52] <BUGabundo1> jelmer it worked. thanks so much!
[19:52]  * BUGabundo1 is happy to store all ~/ ,conf in bzr
[19:52] <BUGabundo1> now to file a bug on kdepim
[20:27] <mdke> hi there. I'd like to branch something and place the .bzr folder and working tree in an existing folder. Is that possible?
[20:44] <jelmer> mdke: afaik 'bzr init .' will happily do that
[20:45] <jelmer> alternatively you could create a .bzr directory somewhere else and then move it into the folder
[20:45] <jelmer> but please file a wishlist bug if you have to do that
[20:45] <mdke> jelmer: what I'd like to do is to download an existing branch into an existing folder containing unversioned files
[20:47] <mdke> jelmer: to give you the details, say I download "desktop moin", which is an installation of Moin which I extract into my home directory. I then want to grab a Launchpad branch with some theme files, which are in the same folder structure as the Moin installation, and put them into the Moin installation under version control
[20:47] <mdke> (without putting other files under version control)
[20:47] <mdke> dunno if that explanation is clear or not :(
[20:50] <jelmer> mdke: so have you tried running
[20:50] <jelmer> bzr init in that directory?
[20:53] <mdke> jelmer: ok, and after that?
[20:57]  * SamB wonders why pydoctor takes so long to generate the bzrlib docs ...
[20:58] <newz2000> what's the best way to handle two projects that are both managed by bzr and you want one to be a subdirectory inside the other?
[20:58] <newz2000> (the subdir is a library used managed by someone else that my proj uses)
[20:59]  * SamB supposes it might help if it didn't look at all those tests ...
[21:01] <mdke> newz2000: I don't know anything about it, but in the absence of another response, I think this is the answer: http://bazaar-vcs.org/NestedTreeProgress
[21:02] <mdke> newz2000: no doubt someone else will know more though
[21:02] <LarstiQ> newz2000: lp:bzr-scmproj or config-manager are other options
[21:03] <newz2000> thanks mdke, looks like what I want when it comes. LarstiQ: I will check it out, thanks
[21:03] <DawnLight1> hello. would anyone want to help to develop a configure script for a small project?
[21:04] <LarstiQ> newz2000: ideally, yes, nested trees
[21:04] <LarstiQ> newz2000: for now, you can of course have a branch as a subdir of another branch, but can't version it at the moment
[21:05] <newz2000> yeah, my problem is that I use bzr to publish my code for review and deployment
[21:06] <newz2000> so I do the nested subdir but I have to do multiple pushes (there are actually four different sub-projects managed separately from mine)
[21:06] <LarstiQ> newz2000: right
[21:19] <distatica> Is there by chance a bzr version that runs on Python2.3? running redmine on shared host, and they do not have bzr installed. Unfortunately they also only have python2.3 (which is horrible).
[21:19] <distatica> I can run git which is setup and working nicely, and this is the only thing stopping me from going bzr vs git.
[21:23] <Odd_Bloke> So I have two bzr branches, a and b.  I would like b to become part of a at a/b.  Is there any good way to do this (I don't care about the time data, and all the revisions in b were committed by me)?
[21:23] <Odd_Bloke> Rebase?
[21:26] <jelmer> mdke: just "bzr pull" from the location
[21:27] <mdke> jelmer: oh!
[21:27] <jelmer> distatica: I don't think there is one
[21:28] <jelmer> Odd_Bloke: bzr join?
[21:28] <distatica> jelmer: I'm trying to compile python2.6 on the server now, I'm hoping that works out.
[21:29] <distatica> It's really unfair that they don't have a half up to date python distro, but call themselves a host with python.
[21:29] <jelmer> distatica: yeah, 2.3 is really old
[21:29] <mdke> jelmer: that's not bad, although it's moved some of the existing folders as conflicts rather than coexisting with them
[21:29] <Odd_Bloke> jelmer: Will joining a bzr branch into a bzr-svn branch Just Work?
[21:31] <jelmer> mdke: yeah, that's intentional; if you resolve the conflicts it should deal with that happily
[21:31] <jelmer> Odd_Bloke: that's the idea
[21:32] <jelmer> Odd_Bloke: be sure to use a recent enough bzr-svn, other than that it should work fine
[21:32] <mdke> jelmer: I'll move the non-versioned files back
[21:33] <mdke> jelmer: thanks for the help
[21:34] <distatica> does anyone know, if I do all my local commits and then push that to a server, does it keep a record of all my local commits on the server? Or does it just keep the last one before I pushed?
[21:40] <NfNitLoop> distatica: it keeps everything.
[21:41] <NfNitLoop> distatica: even if you do merges, every commit to each separate branch gets maintained throughout history and can always be retrieved.
[21:41] <distatica> nice
[21:41] <NfNitLoop> which is quite refreshing coming from SVN. :)
[21:41] <distatica> I got python 2.6 on the server running fine, I hope bzr installs.
[21:41] <distatica> Perfect, I have bzr :)
[22:08] <LarstiQ> jelmer: quite the dos on pk-bazaar-commits
[22:19] <jelmer> LarstiQ: hmm, not sure where that came from
[22:19] <jelmer> LarstiQ: somebody restarted somethign :-)
[22:23] <LarstiQ> jelmer: I need to find a way to limit how many messages exim accepts in one connection.
[22:24] <LarstiQ> jelmer: oom-killer kept visiting exim, until the entire server was unusable
[22:24]  * LarstiQ babysits it with iptables and atop in the mean time
[22:55] <LarstiQ> jelmer: woo, smtp_accept_max_per_connection helps
[22:56] <jelmer> \o/
[23:22] <lifeless> moin
[23:36] <lifeless> I just found out that libgetopt++ is packaged :P I wrote that ages ago!