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