[00:25] jelmer: thanks for lending your delete key [00:26] poolie: fewer functions on Repository means I have to implement fewer functions in the foreign branch plugins :-) [00:46] jelmer: are you coming to UDS? [00:46] poolie: yep [01:07] hi [01:08] a have an error Not a branch what does it mean [01:08] How can I lock a branch for testing? [01:10] linuxcomputacion: the location you specified isn't a branch. It might be a shared repository (but not a branch in that repository), or it might simply be an empty directory somewhere, etc. [01:11] doctormo: python -c 'from bzrlib.bzrdir import BzrDir; b = BzrDir.open('path/to/branch').open_branch(); b.lock_write(); b.leave_lock_in_place()" [01:11] thanks spiv [01:12] And you've probably given me the answer to getting rid of the lock too [01:12] https://bugs.launchpad.net/groundcontrol/+bug/519627 [01:12] Ubuntu bug 519627 in groundcontrol "Need method to detect and break bzr locks" [Medium,Confirmed] [01:13] doctormo: to break a lock, I'd look at how cmd_break_lock does it [01:14] spiv: I might as well just call that builtin right? [01:14] doctormo: maybe, although it's an interactive command, so maybe no [01:15] spiv: I've got the thing tied up to gtk, depends on if the command uses the ui factory [01:15] It should [01:15] If not, file bugs :) [01:34] spiv: I can't seem to lock my branch using your code [01:34] spiv: When I run b.lock_write() it waits for self.wait_lock() (sleeps) [01:36] doctormo: isn't there a .peek method already? [01:37] poolie: Not that I'd know how to use it [01:38] spiv: It might be locking and then when the program ends, it's unlocking [01:41] So even when I let my little lock script lock the branch, my problem still detects no lock [01:41] Is it not possible to lock a bazaar branch? [01:43] huh, so the branch _is locked_ in that the commit just waits around for the lock to go, but branch.is_locked() always returns False. [01:49] Ah I think I worked it out, get_physical_lock_status is the real thing [02:11] doctormo: if it's sleeping in wait_lock, then there's already a lock on disk [02:12] spiv: I understnad [02:12] doctormo: also, you *might* find that doing bzrlib.lockdir._DEFAULT_TIMEOUT_SECONDS = 0 is convenient [02:12] * spiv wanders off === mlh_ is now known as mlh [03:37] lifeless, spiv, poolie: if I have a corrupt dirstate file following a power failure, can I just delete it? [03:37] not much else you can do :P [03:37] you using ext4? [03:38] no [04:31] I have an idea [05:17] Hey guys [05:17] So I've got a lightweight checkout of my code and when I try a bzr pull I get: [05:17] Using saved parent location: bzr+ssh://bazaar.launchpad.net/~groundcontrollers/nautilus-lp/trunk/ [05:17] When it was checked out from: Using saved parent location: bzr+ssh://bazaar.launchpad.net/~groundcontrollers/groundcontrol/trunk/ [05:18] pulling uses the parent [05:18] For some reason it seems to have saved the old launchpad project name somewhere [05:18] you probably want 'bzr up' [05:20] hi, i'm moving my files to a new repo on our server. A new repo was made on the server, I've check out the repo, and I tried doing a bzr merge on the empty repo to all my stuff. WHen I do the merge, all changes are applied successfully, but when I do a bzr st, I get 'working tree is out of date, run 'bzr update'' then it lists files which have been renamed. and then if I try to bzr revert, I get an error: [05:20] bzr: ERROR: exceptions.ValueError: Cannot have multiple roots. [05:20] how can I do what I'm trying to do? [05:21] do you mean branch, when you say repo? [05:21] igc, you can fix (or vote for) the bug asking for an easier way to recreate it :) [05:21] are you trying to merge multiple branches in to one branch? [05:22] poolie: :-) [05:22] bob2: the admin did a bzr init on a remote machine. I did a co on that branch. now I'm trying to get all my local change sinto that branch [05:22] well, not my local changes to that branhc, but yes, my changes from another branch I guess [05:22] that's probably not what you want [05:22] so how can I get all my commit history for what I've done? [05:23] (I did my own bzr init locally and was working there until someone set that up) [05:23] cd yourcode ; bzr push sftp://server/path/to/empty/branch [05:23] thank you much :) [05:24] sftp too? not ssh+bzr? [05:24] whatever [05:24] undo what you've done, first [05:24] yeah, I've done nothing to my code, so that's easy [05:24] have you done anything to the remote branch? [05:28] ok, that worked very nicely :) [05:28] no, I had only been trying to check it out [05:28] so it was completely empty [05:28] and the push worked great [05:30] thanks again. I appriciate the help [06:07] igc could you answer https://answers.edge.launchpad.net/bzr/+question/99465 and maybe some other open questions some time? [06:08] poolie: I'll take a look [07:13] poolie: I need a teddy bear; can you supply ? [07:14] lifeless: ok [07:14] is now ok ? (voice) [07:14] sure, call [07:15] * lifeless sees if he remembers the # [07:31] lifeless: here you go. Teddy bear, fixing everything. http://indiequill.files.wordpress.com/2009/04/teddy-bear.jpg [10:12] hiya [10:12] should bzr depends on python-testtools? [10:13] I got "bzr: ERROR: No module names testtools" when I tried to push to sftp:// [10:27] igc: ping [10:28] hmm [10:33] dholbach: it's a bug that it currently requires that [10:33] dholbach: the workaround is to install it [10:34] ok :) [10:34] * dholbach can live with that [10:45] When is 2.1 final coming out, anyway? [10:54] 'morning [10:57] Q: Is there a way to preserve the date/time of the files during first branching? Ex. I'm branching/pulling from a trunk, but the files saved on my Linux is my local system time. So now if I use like Bzr Explorer, it tells me "Working tree differs from revision XXX", the diff is only the date/time of all files. [10:59] Laibcoms: that seems like a bug - it should also be checking the file contents [11:01] jelmer: hi, i'd like to talk to you more about incremental imports, but i'm too tired i guess [11:01] mwhudson: hey [11:02] mwhudson: I think I'll be around on IRC during your morning [11:02] jelmer: The diff works (if I edit a file, it shows the changed lines). But I haven't started editing files yet, so it's only reporting that my pull is different because of the date/time. [11:02] jelmer: that'd be great, i'll try to get up on time :) [11:04] oh, just noticed, maybe this is what triggered it: "(properties changed: -x to +x)" [11:04] mwhudson: :-) [11:05] Laibcoms: that would explain why the file is being marked as modified [11:08] jelmer: yep. But should it do that or something? Hmm.. I'll give it a try via WinXP then see if I pull via Ubuntu again there'll be a properties change. Tnx tnx! [11:08] Laibcoms, it means you have changed the permissions on the file [11:08] Laibcoms, the executable bit is now set whereas it wasn't earlier [11:09] Or alternately you're on a non-*nix filesystem that fakes them from not actually having +/-x itself. [11:12] fullermd: ahh! That explains it, my local repo is on my larger partition w/c is NTFS. [11:12] jelmer, fullermd thanks thanks!! [11:13] Laibcoms, we could probably detect that the fs doesn't support executable bits and Do The Right Thing [11:13] ahh [11:54] lifeless, ping [12:01] btw, should I file a suggestion for that -- +/- detection, or no need? [12:07] Laibcoms: please do [12:07] Laibcoms: at the moment I think we ignore the executable bit on just windows, but that really should be on any filesystem that doesn't support the executable bit (which includes all filesystems supported by windows) [12:09] jelmer: ahh ic. ok, I'll enter it as a suggestion. Thanks again ^^ [12:09] It's sort of a specific case of behavior varying by FS, that we approximate by OS. [12:10] I think on Windows we also try to do a little more handling (if only at the "fail gracefully" level) of case-insensitive issues, for instance, but that's really depending on the FS rather than the OS. [12:11] (or maybe we don't, and I'm imagining things. Always a possibility) [12:12] fullermd: we should distinguish between fs'es supporting the executable bit and case-insensitive/case-preserving file systems [12:13] Also, we should have a pony 8-} === mrevell is now known as mrevell-lunch [12:46] fullermd: there is case-insensitive fs check === salgado_ is now known as salgado === mrevell-lunch is now known as mrevell [14:35] How long does the test suite roughly take to run? [14:35] Hours? === JFo is now known as JFo-afk === salgado is now known as salgado-lunch === salgado-lunch is now known as salgado === JFo-afk is now known as JFo === IslandUsurper is now known as IslandUsurperAFK === beuno is now known as beuno-lunch [17:02] * jam peeks around for the current LOSA [17:03] in a meeting at the moment - will be with you after that === jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.0final has gone gold, time to build installers! [17:10] mthaddon: no rush, but eventually I'll need an 'lp:bzr/2.2' branch created and have it registered with pqm so we can start making 2.2 series releases. === beuno-lunch is now known as beuno [17:32] jam: have you filed an RT about that? === deryck is now known as deryck[lunch] [17:38] I have not === IslandUsurperAFK is now known as IslandUsurper [18:00] A 2.2 branch? I'd think we'd just cut off trunk 'till RC-stage... [18:04] fullermd: we keep a dev branch so that I can take a day or two to make a release without blocking trunk [18:05] * fullermd submits the ports update. [18:07] Always interesting seeing how much of the packing list changes every release are under tests/ :) === deryck[lunch] is now known as deryck [18:33] does anyone know if it is possible to start a new branch and make a commit from 2003 (for example)? [18:34] I've never used a vcs before but have revisions of some websites dating back to 2003 and I want to make a branch that has all that historical data in it [18:34] The commit command has a --commit-time arg (at least in recent enough versions) [18:38] so if I were to make an initial commit, I could get it to be set at 20031202 12:01 +0500 and then do it subsequently for all my other commits, working backwards all the way up to today? [18:42] Yah (assuming you actually have a 1-minute granularity on your old revs of course ;) [18:42] You'll want to check 'stat' in between commits, to catch any new or moved files and make sure they're recorded right of course. [18:44] * fullermd scampers off for a bit. [18:46] fullermd: hmm, okay. I see this was recently recreated in 2.1 and will only be available in Lucid (re: https://bugs.edge.launchpad.net/bzr/+bug/459276) [18:46] Ubuntu bug 459276 in bzr "user specified commit date" [Low,Fix released] [18:46] so I'll have to upgrade to Lucid to do this [18:47] I wish there was an easier way instead of using stat on all 50 directories/revisions I have... some folders will be complete rewrites and will require adding hundreds of files [18:58] mthaddon, or some other losa: I opened rt #37561 for the request for another pqm branch of bzr [19:00] jam: ok, once that makes its way into our queue, we'll attack. [19:10] GRRR... bzr di --diff-options="-C 1" => shows two chunks. This is good. I want to shelve one but not the other. [19:10] bzr shelve --diff-options => doesn't understand --diff-options. without said option, shows only one chunk. [19:10] hmm, no jelmer [19:12] * LeoNerd solves by bzr di ... >patch.diff; vim patch.diff; patch -R Hm, funny. bzr 2.1.0 cut today. Parrot 2.1.0 released today. [19:41] COINCIDENCE?! [19:46] * Tak head explode [20:03] fullermd: i'm having trouble with my conspiracy theory generator here [20:06] fullermd: its all about the pigeons === salgado is now known as salgado-brb [20:16] Man, the pigeons are just tools of the finch hegemony. It's ALL connected! [20:31] via farcaster? [20:36] hi [20:37] how can i ignore a file without have to remove it from the central repo? [20:37] i try remove --keep, but it remove it. [20:38] elh4z: why do you want to ignore it? [20:43] is a config file. [20:43] has parameters for the db connection. [20:46] hmm, not sure how you'd do that then [20:46] uhmm is simple.. [20:46] you have a config file, an commit it to the central repo. [20:47] but, what happen if other person checkout ?? then the config file updated.. and I have to re edit it. [20:47] if that person edit it, he have to commit it, then i have re edit it again.. [20:47] over and over again... [20:48] yeah I'm meaning I'm not sure how you can have it so that one file isn't checked out [20:48] the only thing I can suggest is put the config file in a separate branch [20:49] others might be able to offer better suggestions [20:49] uh.. thanks ;) [20:50] but i have to merge over and over again, no?? [20:52] elh4z: I usually make a file called "config.template" or something, and the idea is that you check out the branch, then copy config.template to config and use that locally [20:52] elh4z: or that you have something like configure or setup.py do that for you... my.config.in can go in the tree, but running configure fills my.config with values and leaves my.config.in untouched [20:53] uhmm good suggest. [20:53] but would be not good something like ignore without remove?? [20:53] I mean.. i have rename over and over agan config files :P [21:06] Is the equivalent of the push-and-update plugin now available in Bazaar core? [21:07] AfC: no, if you want that install the plugin [21:08] mwhudson, 'morning [21:08] hey lifeless [21:09] hi jelmer you pung [21:09] jelmer: hi! [21:09] lifeless: I was wondering if you saw the merge requests I put up for bzr-dbus [21:09] nope [21:10] lifeless: ok. Seems like it could be a simple option to push; surely bzr could pass it along its network protocol rather than having to set up a second SSH connection. [21:10] lifeless: one adds more laziness, the other adds support for zeitgeist [21:10] lifeless: I can provide links if you like, or whatever helps :-) [21:10] AfC: if you're using the smart protocol you can write a hook to sit on the server and do it for you [21:11] morning lifeless [21:11] AfC: and there is no ui for dealing with conflicts, which is one of the major reasons we don't do it by default anyway - that hasn't changed [21:11] mwhudson: should we talk about incremental imports? [21:11] hi jam [21:11] jelmer: yes please [21:11] jelmer: link me up [21:11] jelmer: here or skype? [21:12] lifeless: https://code.edge.launchpad.net/~jelmer/bzr-dbus/lazy/+merge/19002 is the lazy import one [21:12] lifeless, https://code.edge.launchpad.net/~jelmer/bzr-dbus/zeitgeist/+merge/19120 is zeitgeist [21:12] lifeless: right, so if there are conflicts and that option is selected, then the push should fail. Wouldn't that be reasonable? [21:12] mwhudson: skype ? Good moment to see if the skype support in my N900 actually works :-) === salgado-brb is now known as salgado-afk [21:13] lifeless: but for the common case of pushing to a branch which is a [public] mirror of one of your own branches, there will never be conflicts. [21:13] jelmer: heh heh heh [21:13] jelmer: i'm michael.w.hudson [21:13] mwhudson, I'm jvernooij [21:13] AfC: actually there can be, in that common case - e.g. .pyc files [21:14] lifeless: testing question. for 'expectFailure(reason, assertion)' if the assertion succeeds, should expectFailure consider that an error? [21:14] why would there be .pyc files in a Branch? Oh, like if someone is using that to push their website. Hm [21:14] Well, it still leaves people who are trying to publish Bazaar branches out in the cold [21:14] jam: yes [21:15] which is a bit of a letdown, since the whole "hey, you can just serve your branch with an HTTP server, and hey here are the files!" thing was a big seller for Bazaar early on [21:15] AfC: so the common case is something like dreamhost [21:15] lifeless: ok, it seems we regressed here. Testtools 0.9.2 tries to call addUnexpectedSuccess, but if that member isn't available, it calls addSuccess [21:15] where we suggest the 'bzr upload' plugin in fact [21:15] jam: and we have a result without addUnexpectedSuccess? [21:15] lifeless: I believe so [21:16] lifeless: right, and since we recommend the upload plugin for the "run my website" case, why can't bzr push update the remote checkout? [21:16] I tested it, and expectedFailure silently succeeds [21:16] jam: so, find that result and we should fix it ;) [21:16] lifeless: but is this a bug in testtools, or bzr? [21:16] jam: almost certainly bzr [21:16] Certainly we can work around it in bzr [21:16] but doesn't it seem that the default UnexpectedSuccess action would be Failure ? [21:16] jam: by workaround you mean 'implement addUnexpectedSuccess' [21:17] lifeless: I'm saying the default behavior of testtools is wrong, but we can use the hook provided to get our own result [21:17] jam: I'm saying that even if the default is wrong, we should implement that method anyhow. [21:17] even if the default was right. That its orthogonal. [21:18] lifeless: well, given that it will just thunk over to addFailure, I don't see a specific need to have it [21:18] but we can [21:19] AfC: a few thoughts: we can't consistently do it efficiently (sftp). We don't have a UI for resolving conflicts in this case, so people will be unable to push further. We can't take out the right locks in some cases (sftp). Remote branches rarely have trees at all. [21:20] jam: I don't know that a hard failure is the right behaviour; certainly we'd want to know about it though. [21:20] jam: so I do agree that the current outcome is not good. [21:20] jam: as for why addU..S.. goes to addSuccess, there isn't a backtrace available, and it seemed to make sense at the time. [21:20] does Canonical candidate for Google SoC? [21:23] lifeless: so, to complete this, 'addFailure' wants to have an 'err' which seems to be the value of sys.exc_info() [21:23] which was computed earlier when UnexpectedSuccess was raised [21:23] should I just pass None, though? [21:23] (since addUnexpectedSuccess does not take an 'err' parameter) [21:23] jam: well, the signature for addFailure should be (self, test, err, details=None) [21:23] lifeless: fair enough. I can't help but note that the push and update plugin manages all that fine though sadly inefficiently. Oh well. I give up [21:24] lifeless: our addFailure has no details param [21:24] jam: you may be seeing unmigrated code; and passing None will probably lead to explosions [21:24] AfC: having inefficient things in the core is a problem! [21:24] AfC: also it doesn't manage all of those things, but if it does what you need I'm very glad. [21:24] lifeless: I tracked down what I could, and at least testtools as an "if err is not None: #pass to unittest" [21:25] jam: testtools has a details parameter too though, which is where it starts supporting err as None [21:25] if details is a dict [21:26] lifeless: I've never once had a problem with it. I just wish it was a smart-server verb instead of a kludge to run a second external SSH process. [21:26] lifeless: I'm probably going to switch back to using rsync to publish Bazaar branches, so I guess it won't matter anymore [21:27] AfC: if you ask nicely jam might update it to provide a hook so the server can do it for you [21:27] AfC: it would be possible for the plugin to provide a smart server verb, and require that you install it on both sides [21:27] AfC: really? won't rsync be slower? [21:27] jam: "and require" <- hence my wishing it was in core! [21:27] AfC: well, you have to install it locally as well [21:27] and it would at least provide a proving grounds before we wanted to land it in core [21:28] jam: could use a post tip change [21:28] jam: and if chrooted activate then [21:28] lifeless: you mean server-side only hook, right? [21:28] essentially [21:29] using the server chrooting facility as a 'am I server side' check [21:29] lifeless: probably not; it'd only be one ssh connection instead of two [21:29] AfC: though if the pack files aren't identical you'll get *way* too much transfer [21:29] and rsync doesn't send data in the transaction safe way [21:29] but as long as you push again, you'll eventually converge [21:30] (I find myself rather frequently with "oh shit, gotta get up off the train" and waiting, waiting, waiting for push [-and-update] to finish. So it keeps being a sore spot for me) [21:30] and as long as you only publish from 1 location [21:30] verterok: hi [21:30] (plus forgetting that I installed in once 2 years ago and forgot about it, only to discover that it wasn't on new machine, so URLs to code I was giving out were not showing updated code. No end of embarassment) [21:30] verterok: have you ever participated in Google SoC? [21:30] RenatoSilva: hi [21:30] RenatoSilva: no [21:31] verterok: bzr-eclipse is a good candidate project :) [21:31] jam: it's just a public publish mirror of my branch, so there's nothing happening there that isn't happening here [21:31] though, if I have to go down this road, I'm more likely to do something like source-highlight the code locally and then rsync the lot up. That'd be pretty [21:31] RenatoSilva: heh, it might be [21:32] igc: let me know what the final URLs for the CHM docs are [21:32] I'll wait to build the windows installers until you tell me [21:32] verterok: we could mentor some student on coding bzr-xmloutput, bzr-java-lib, and bzr-eclipse towards releasing bzr-eclipse 1.0 [21:32] RenatoSilva: I can't participate, but I'ld be glad to help with it [21:32] I have to go for ~30min, bbiab [21:32] RenatoSilva: indeed === gnomefreak76 is now known as gnomefreak [21:33] verterok: not having a really stable, working eclipse plugin for bzr is the only reason I don't talk to my co-workers to migrate from CVS to bzr :) [21:33] RenatoSilva: oh, that's bad indeed :( [21:33] RenatoSilva: I'ld like to spend more time hacking on bzr-eclipse... [21:34] RenatoSilva: I need to finish testing the bundle-bzr-plugins branch on windows, with that it's a step closer to the next stable release [21:34] RenatoSilva: external bzr-xmloutput proved to be a pain [21:35] verterok: because of not being sure what version is installed? [21:36] AfC: you could run loggerhead, it has code highlighting via pygments [21:36] RenatoSilva: yes, and because it make it simple to control the dependencies, we could even require a set of bzr versions [21:37] RenatoSilva: e.g: this bzr-eclipse release work with bzr 1.9.x and 2.0.x, but <= 1.8 or >0 2.1 isn't supported [21:39] lifeless, VWS? [21:39] vertical white space [21:39] 'delete the empty line you put within that function' [21:40] verterok: I have never participated in GSoC, but if I find a way, and one or more students interested/~skilled, can I contact you later? [21:40] RenatoSilva: sure [21:40] verterok: I don't have much time too, but coding is for students, having ideas and telling what to do (and review code) is for us :) [21:40] RenatoSilva: :) [21:41] verterok: it's $500 for the project [21:41] RenatoSilva: if "later" means today, I'll leave to play soccer in ~1h but be back online later tonight [21:41] lifeless: Ahh.. Fixed 'n pushed. Thanks for the review. [21:42] lifeless, What do you think about having the zeitgeist support live in the dbus plugin? [21:42] verterok: in which stage is that project (forgot the name) which would allow to switch from java + bzr.exe to bzr lib? [21:42] jelmer: conceptually fine; needs copyright assignment, and I don't see why you hook commit when tip change is already hooked. [21:42] verterok: not today, but don't worry, I send memos if you're offline [21:43] s/too/either [21:43] RenatoSilva: :) [21:43] RenatoSilva: jython? [21:43] RenatoSilva: there is still a lot work to do to make bzr + jython work [21:44] lifeless: there is a post branch tip change hook, not a post commit hook [21:44] lifeless: we don't want the zeitgeist plugin to trigger on push/pull finishing [21:44] jelmer: commits involve the branch tip changing [21:44] jelmer: why not ? [21:44] lifeless: because zeitgeist keeps a log of the actions of the local user [21:44] yes [21:45] RenatoSilva: one of the biggest issues are missing CPython modules in jython [21:45] RenatoSilva: the other option is to implement bzr in Java... [21:45] * verterok hides [21:45] :) [21:45] lifeless: the commits that local user pulls are not made by them, and should not show up in the log [21:46] jelmer: but its an action ('I pulled'), why shouldn't that show up? [21:47] jelmer: (and you could filter those out if you want by checking the committer/author) [21:47] verterok: I think I mean CPython [21:47] lifeless: They pulled a lot of commits, not just the tip [21:47] jelmer: yes, however the 'action' was 'pulled a branch' [21:47] lifeless: if we would log those actions (push/pull) we should log them as actions on the branch [21:47] jelmer: right, thats what I'm proposing. [21:48] verterok: it would be *really* nice to get the c modules ported to jython, correct me if I'm wrong but I think that would be a new era for bzr-eclipse [21:48] verterok: I mean, talk directly to bzr-lib [21:50] RenatoSilva: indeed, it will make all so much simple [21:53] RenatoSilva: I'm seriously thinking of other way to do the bzr-java-lib <-> bzr communication, without using xml (nor xmlrpc but this is a detail) [21:54] RenatoSilva: I mean, leave xmloutput as is, and work on a rpc plugin just for bzr-java-lib or any other non-pyhton lib that wants to talk with bzr, but without the xml overhead and complexity [21:55] verterok: a new bzr plugin using rpc and some non-xml format? [21:56] RenatoSilva: yes, the rpc could be xmlrpc or any other...but it's just crazy talking :) [21:59] verterok: I like crazy talking :) [21:59] verterok: but do you have any other format in mind? the overhead of xml is just parsing right [22:00] RenatoSilva: and building it :) [22:00] verterok: yes, mapping it to an object... have you ever tried xstream? maybe not suitable in this case but [22:01] RenatoSilva: yes, I used it a while back [22:01] verterok: how about json? or maybe a custom format more easily parseable... [22:02] RenatoSilva: yes, json is an option [22:02] verterok: any chance of any "bzr jython edition"? [22:02] ^^^ [22:02] RenatoSilva: not in the short term [22:03] RenatoSilva: I need to pull the latest changes from jython trunk and see how it goes [22:03] RenatoSilva: one of the big issues is missing OSLocks [22:03] RenatoSilva: but I think it could be made using java.nio [22:05] verterok: by jython edition I mean remove the C stuff, and replace with python code, do you think it would make things too much slower, unusable? [22:05] RenatoSilva: bzr already have python fallbacks for all C/pyrex stuff [22:06] RenatoSilva: the issue are missing modules in jython, or modules that aren't going to be implemented in jython [22:06] verterok: but if jython misses the modules, bzr will use the fallbacks, right? so no problem in this part, right? [22:07] we only have fallbacks for the C modules we provide [22:07] ones CPython provides we don't. [22:07] RenatoSilva: ^ [22:07] lifeless: :) [22:09] morning [22:09] poolie: can you take a look at the cron job for refreshing the main website ... [22:10] my edits from yesterday still haven't come through for some reason [22:11] verterok: do you think that fallbacking CPython would make things considerably slow? [22:12] yes [22:12] ok [22:12] it may also push memory use way up [22:12] RenatoSilva: don't really know, but even if it's slower, it will be less fragile [22:13] verterok: fragile == less risky? [22:13] lifeless: in that case, I think that makes sense but it's something I'd rather defer until later [22:13] verterok: the ports to jython would be written in Java? or JNI + C? [22:13] RenatoSilva: currently bzr-eclipse has a lot of moving parts, my in-progress branch to bundle xmloutput with bzr-eclipse should help with that [22:14] verterok: moving? [22:14] ok igc [22:14] hello jam [22:14] lifeless, since we'd have to distinguish between commits from the user and branch actions and have a way to filter the latter out in the gnome ui [22:14] RenatoSilva: bzr-java-lib, bzr-xmloutput and bzr itself [22:14] hi poolie [22:14] 'morning igc, jam, poolie [22:15] RenatoSilva: and all the combinations between them :) [22:15] hi jelmer, jam [22:15] ah the N-way communications problem :) [22:15] :) [22:15] jam, you had a holiday yesterday i think? [22:15] i felt lonely :) [22:15] igc: I saw that you were going to rebuild the docs, did that finish? [22:15] vila is away too [22:15] verterok: you want to bundle bzr executable too? [22:16] poolie: yeah, holiday. very lonely here today w/o vila [22:16] It was quiet. Peaceful-like. [22:16] RenatoSilva: no [22:16] verterok: and python interpreter? :) [22:16] all of you don't show up until late [22:16] RenatoSilva: :) [22:17] RenatoSilva: other possiblity is to keep using the current approach, and work on a better rpc service [22:19] RenatoSilva: the current implementation doesn't handle log very well, it just load the whole history in memory and the send it over the wire [22:19] RenatoSilva: also authentication is missing, no way to prompt for a password [22:19] RenatoSilva: there are a lot of stuff to fix/find a solution :) [22:20] poolie: do you want to do a call tomorrow? I know we missed yesterday, and it is getting a bit late today [22:21] how about just ten minutes/ [22:23] fullermd: not silent, just different [22:24] verterok: nice, if we could get into GSoC, you (mainly) could create a todo list, bundle them in "goals" or "blueprints" and have the students working on it [22:24] jam i'm trying to get through but your robot doorbitch won't let me in :/ [22:24] jam: the chm rebuilds are done - uploading now [22:25] verterok: no idea if we could get a bzr-eclipse really-1.0, but it would still be 3 months of code progress [22:25] poolie: sure, you can do my cell if it is easier [22:26] verterok: I could help with code review and keep more in touch with the student etc, while you would be the "master" guy :) [22:26] RenatoSilva: yeap, sounds like a plan :) [22:26] RenatoSilva: I need to run, but be back later [22:27] * verterok is out [22:30] does bzr use too many / complex CPython modules? [22:33] bzip2, zlib, re offhand [22:34] lifeless: so if ~ these 3 libs get ported to jython, that would be enougth for accessing bzr-lib from Java code? [22:35] maybe [22:35] you should try [22:35] jam: http://doc.bazaar.canonical.com/bzr.2.1/downloads/ has the chm files now [22:36] lifeless: ok, thanks [22:45] igc: can you make it 2.1.0 ? [22:46] /bzr.2.1.0/ ? [22:48] lifeless: from #jython: sabi: re is implemented. bz2, there's some code but it's not done yet (http://bugs.jython.org/issue1445). zlib also appears to be implemented, though maybe not all of it [22:54] jam: poolie decided to move away from doc builds for 2.0.x to simply having one for 2.0 [22:55]