| elijah | How would I determine how much space the svn-bridge information takes under .bzr? | 00:12 |
|---|---|---|
| elijah | (For a repository imported via bzr-svn.) | 00:13 |
| lifeless | what do you mean 'svn-bridge' ? | 00:20 |
| elijah | If I import with bzr-svn, I may want to later do an incremental update. | 00:21 |
| elijah | Does bzr-svn store any information to make later updates easier? | 00:22 |
| elijah | If so, how much space does such information take? | 00:22 |
| elijah | (i.e. it's not fair to compare svn storage requirements to bzr storage requirements using bzr-svn on an existing svn repository if bzr-svn is storing extra information about bridging to an alien repository) | 00:23 |
| elijah | From poking around under .bzr, it appears the answer is not much, if anything...but I just want to be sure. | 00:24 |
| lifeless | elijah: the mapping data you are talking about goes in ~/.bazaar/ | 00:24 |
| lifeless | elijah: and is regenerated on demand | 00:24 |
| elijah | ah, so if I have a svn checkout of foo in foo-svn and a bzr-svn checkout of foo in foo-bzr, then it is fair to compare 'du -hs foo-svn' and 'du -hs bzr-svn', yes? | 00:25 |
| elijah | (Well, keeping in mind the fact that bzr stores all information on the branch instead of just a copy of the latest version) | 00:25 |
| james_w | elijah: yes. | 00:27 |
| elijah | cool, thanks. :) | 00:27 |
| james_w | elijah: however it may not be representative of what you would have with a pure bzr branch of the same revisions, as bzr-svn may have some overhead, but it is all mixed in with the .bzr metadata | 00:28 |
| elijah | doh | 00:28 |
| elijah | well, I probably can't measure that easily, so I guess I'll have to do without. | 00:28 |
| lifeless | also | 00:29 |
| lifeless | we have annotations cached in .bzr | 00:30 |
| lifeless | some formats make them optional, if storage is a premium | 00:30 |
| lifeless | and in about 2 months we're expecting a 50% size reduction in .bzr | 00:30 |
| elijah | with the knit-pack format? | 00:30 |
| beuno | lifeless, would you have a few minutes to talk about the XML/Output Abstraction patch? We're still unsure on to procede... :( | 00:33 |
| lifeless | beuno: yes, but not right now sorry | 00:42 |
| lifeless | elijah: with a successor based on it. new delta logic and ordering | 00:42 |
| lifeless | elijah: its a minor tweak now we have the infrastructure in place. | 00:42 |
| lifeless | later all | 00:42 |
| beuno | lifeless, np, tnx anyway | 00:44 |
| elijah | lifeless: cool | 00:44 |
| elijah | thanks for the help, lifeless and james_w | 00:44 |
| AfC | Does[n't] Launchpad have a bzr:// server running? | 04:07 |
| jamesh | AfC: no | 04:13 |
| jamesh | just http: and bzr+ssh: at the moment | 04:14 |
| jamesh | and sftp: | 04:14 |
| jamesh | you can access all branches via http and bzr+ssh | 04:14 |
| AfC | jamesh: yeah, but http:// is deadly slow | 04:14 |
| jamesh | try bzr+ssh then | 04:15 |
| AfC | I'm surprised at them for not running a Bazaar server. Hello, dogfood. | 04:15 |
| jamesh | we are running a Bazaar server | 04:15 |
| AfC | There are some pretty evident differences between invoking a single bzr serve for a short duration over an SSH tunnel, and having a bzr serve daemon running. | 04:16 |
| jamesh | AfC: we did have bzr+http set up a while back, but it seems to have bit-rotten | 04:16 |
| AfC | jamesh: (yeah, I gave up trying to make that work) | 04:16 |
| AfC | (too) | 04:16 |
| jamesh | there do seem to be some bugs in Bazaar related to closing connections | 04:17 |
| AfC | jamesh: Incidentally, in reply to your response of "try bzr+ssh://" to "my http:// is deadly slow", my comment was really more directed along the lines of "everyone is publicly being told (by Launchpad itself, and everything else) | 04:17 |
| jamesh | AfC: well, we're looking at changing those instructions to "bzr branch lp:whatever" | 04:18 |
| AfC | jamesh: to do bzr clone http://whatever ... and thus the very first impression they get of Bazaar as a result is pathetic performance. We observed an improvement of the order of 22 minutes to ~105 seconds by switching to a public bzr:// instance | 04:19 |
| AfC | jamesh: yeah, I filed one myself about CLOSE_WAITs. | 04:20 |
| jamesh | AfC: sure. http or sftp are not really comparable to bzr or bzr+ssh | 04:20 |
| AfC | [which is usually a pretty clear flag or such] | 04:20 |
| AfC | s/or/of | 04:20 |
| AfC | The Bazaar hacker crew it talking about 1.0 any day now; it's things like what we've been speaking about which I would encourage be cleaned up lest the marketing opportunity they are hankering after be wasted. | 04:21 |
| AfC | s/it/is | 04:21 |
| AfC | Apparently I haven't had enough coffee yet today | 04:21 |
| jamesh | I wonder if we have a bug for adding plain bzr:// protocol support | 04:21 |
| AfC | I'll file one if you want, but that's really your internal business. | 04:23 |
| jamesh | please do so | 04:23 |
| jamesh | AfC: how many squares were on the senate ballot paper for you? | 04:26 |
| AfC | jamesh: Zero. I'm not an Australian citizen. | 04:27 |
| jamesh | ah. | 04:27 |
| jamesh | you should fix that :) | 04:27 |
| AfC | [This is almost, but not quite a bitch for me. Same problem in New York. I lived there years. I PAY TAXES. And yet I am unable to exercise representation. Taxation without representation has been the singular most dominating issue driving western politics in the last 300 years. Even religious conflict is usually cover for this issue] | 04:28 |
| jamesh | I remember one of my former colleagues who moved states in Canada | 04:29 |
| jamesh | the two states had different enrollment rules, so he got taken off the roll in the old state, but had to wait a while before they'd put him on the roll in the new state | 04:30 |
| jamesh | so he missed the election | 04:30 |
| AfC | uh huh | 04:30 |
| jamesh | (can't remember which type of election it was though) | 04:31 |
| AfC | I'm pretty much a permanent expatriate now. It's ok. I kinda like it that way. | 04:31 |
| AfC | I love how when I try to report a bug in launchpad it crashes my web browser. | 04:32 |
| AfC | jamesh: https://bugs.launchpad.net/launchpad/+bug/164790 filed | 04:34 |
| ubotu | Launchpad bug 164790 in launchpad "Launchpad should run a Bazaar server and advertise bzr:// URLs." [Undecided,New] | 04:34 |
| jamesh | with the changes I did to the launchpad plugin for Bazaar, it'd be trivial to get people using bzr:// instead of http:// for lp: URLs purely through changes on the server | 04:36 |
| AfC | jamesh: that makes sense | 04:38 |
| AfC | jamesh: I'm mostly an outsider on all this, but we made an early commitment to Bazaar for what we believe are the right reasons. My colleagues and I just want to see Bazaar put forward as successfully as possible as a result. | 04:39 |
| AfC | ie removing cruft, etc | 04:39 |
| jamesh | AfC: yep. | 04:40 |
| jamesh | hopefully you'll find some of the new Launchpad features in the coming months useful | 04:40 |
| AfC | [IMO (nothing humble about it) merely calling it "1.0" has little to do with achieving that. I know that'll bring more users, but on the other hand | 04:41 |
| AfC | there are so many warts (and the two competitors are improving in usability rapidly enough) that it's really quite underwhelming as a result. Little things matter. | 04:41 |
| jamesh | 1.0 is not the end by any means though | 04:42 |
| AfC | But the nature of leadership making is that people make input and then a decision is taken. Martin has made his call, fine] | 04:42 |
| AfC | jamesh: I know. But all you're setting yourself up for is to get FUCKING PANNED in the trade press. Why would you invite this? | 04:42 |
| jamesh | you'd have to ask one of the Bazaar guys about release planning -- I'm primarily a Launchpad developer | 04:43 |
| AfC | Sure | 04:44 |
| AfC | s/you/Canonical/ | 04:44 |
| * AfC is used to getting panned and mocked when he makes releases. Alas. | 04:44 | |
| AfC | That's Open Source for ya. | 04:45 |
| fullermd | AfC: That's why I take great care to get my code ALMOST ready for release, and then never touch it again. It's not laziness, it's careful PR! ;) | 07:43 |
| AfC | fullermd: ha | 07:43 |
| fullermd | Having spent the last couple days working on code in mtn, I'm reminded of how much I prefer bzr. | 07:44 |
| fullermd | But I do agree that a current 1.0 isn't just tempting fate, it's slapping a 'Kick Me' sign on yourself. | 07:46 |
| Owner | hello, I've got a question about using bazaar with asp.net+IIS projects, anyone around? | 07:56 |
| === Owner is now known as bp | ||
| fullermd | I dunno what the question is, but I'll bet the answer involves holy water... | 07:57 |
| bp | :) it's not as bad as you think, infact I kind of actually have a solution to the problem, but I wanted to know if bazaar supports the fix "officially" | 07:59 |
| bp | The problem is that IIS seems to reject applications that contain directories with a "." (period) in their names. I.E. the .bzr folder | 08:01 |
| bp | there seems to have been a bug report filed back in 2006: http://bazaar-vcs.org/UnderscoreControlDir but I can't find any recent mention of it. | 08:02 |
| fullermd | What, it ignores the whole directory because there's one file like that in it?? | 08:02 |
| bp | not ignores, per say, just acts wierd in certain situations | 08:03 |
| bp | renaming .bzr to _bzr (or anything else for that matter) fixes the problem, but of course this breaks the repo. | 08:03 |
| fullermd | That's fwacky. | 08:03 |
| fullermd | I do remember the _bzr discussion, but it's certainly not currently there. I don't remember if it just petered out, or got voted down for some reason, though. | 08:04 |
| bp | yup, so basically I'm asking if bazaar supports renaming the repo folder. | 08:04 |
| fullermd | AFAIK, no. | 08:05 |
| fullermd | You might be able to put a wrapper around all bzr commands that mv it from _bzr to .bzr, do the bzr stuff, then mv it back. | 08:05 |
| fullermd | Or just keep the VCS separate from the deployment. | 08:06 |
| beuno | under apache, he means :p | 08:06 |
| fullermd | The former has its problems, but may work. The latter's how I do stuff, but it does mean a little more infrastructure work. | 08:06 |
| fullermd | Well, obviously, apache is the Right Answer ;) | 08:06 |
| bp | hmm, yeah those are valid solutions, but I think I might just attempt to apply the patch in the aforementioned link. Thanks for your help. | 08:07 |
| fullermd | Well, the actual changes are probably a lot more involved than that suggestion there. I'm pretty sure that only gets one place of the number that look for .bzr. | 08:07 |
| bp | oh, well. I guessed as much, especially since that was back in 2006. Meh, no big deal, just a minor annoyance. | 08:09 |
| beuno | bp, you could serve it through ftp | 08:12 |
| beuno | anonymous ftp if you need public access | 08:12 |
| bp | oh, no I'm not trying to make the repo public. Just trying to run the project (asp.net) in my dev environment. | 08:13 |
| beuno | bp, well, you can serve bzr through ftp then | 08:14 |
| beuno | you can push/pull through ftp | 08:14 |
| * fullermd blinks. | 08:14 | |
| fullermd | I don't think bzr access is in any way his problem... | 08:14 |
| beuno | oh, I might of understood it wrong then | 08:14 |
| fullermd | It's that for whatever stupid reason, IIS goes nutty simply because of the presence of a '.bzr' directory, even if it's never accessed. | 08:14 |
| beuno | aaah, sounds like fun | 08:15 |
| fullermd | Which sounds insane to me. Even for IIS. | 08:15 |
| beuno | I was under the impression he wanted to branch from http | 08:15 |
| * beuno reads it through again and realizes it was pretty clear | 08:18 | |
| beuno | no more IRC for me after 4am | 08:18 |
| bp | :) thank's for trying beuno. hmm, just noticed Martin Pool (poolie) and Robert C (lifeless?) are on the channel, I think I'll just lurk for a few hours and hope they see the convo | 08:18 |
| fullermd | Pshaw. That's the best time ;) | 08:19 |
| fullermd | Well, it's Saturday night for them. They may check in, but... | 08:19 |
| lifeless | bp: I've seen that you had one, but not the content, and I'm on the way out to dinner | 08:19 |
| lifeless | bp: mailing the ist would be a good thing to do | 08:19 |
| fullermd | lifeless: asking after _bzr support | 08:20 |
| fullermd | Did that discussion just peter out, or did we decide against it? | 08:20 |
| lifeless | I think its got enough UI problems we are more against than for | 08:21 |
| lifeless | but its not an impossibility; whats the reason - broken webserve or 'dont want an empty dir' ? | 08:21 |
| lifeless | actually, I have to go; sorry | 08:21 |
| * fullermd nods. | 08:22 | |
| bp | np, thanks lifeless, I think I'll put this issue on the lists | 08:22 |
| fullermd | bp: Yeah, a summary to the list is probably the best thing. | 08:22 |
| bp | yup | 08:22 |
| ubotu | New bug: #164810 in bzr "knit chunk should contains inside all meta information that index has" [Undecided,New] https://launchpad.net/bugs/164810 | 08:55 |
| ubotu | New bug: #164814 in bzr "osutils.splitpath lose info about root directory" [Undecided,New] https://launchpad.net/bugs/164814 | 09:00 |
| === cfbolz_ is now known as cfbolz | ||
| ubotu | New bug: #164825 in bzr-push-and-update ""pushed 0 revisions" incorrect" [Undecided,New] https://launchpad.net/bugs/164825 | 10:16 |
| === weigon__ is now known as weigon | ||
| dennda | Hi there. I have a problem that isn't bzr-related at all, but maybe you can help me. I heard bzr uses ElementTree a lot. Is that correct? | 11:05 |
| dennda | I parsed a svg-file (which is xml) with ElementTree and without altering it saved it back to the disk. the result is: http://pastebin.ca/795717 <- I want to know how to get rid of ElementTrees namespace-behaviour. It adds them automatically, which is not what I want. (It breaks the svg.) - If anyone has an Idea I would be glad if you shared it (maybe in query. Don't want to spam your channel) | 11:10 |
| fullermd | Well, I'm no developer or expert. But I was under the impression that bzr didn't use ElementTree to write the XML; just to parse it for reading. I think the writing is done manually. | 11:14 |
| === kiko is now known as kiko-phone | ||
| === kiko-phone is now known as kiko | ||
| === kiko is now known as kiko-afk | ||
| === cprov-away is now known as cprov-lunch | ||
| dato | oh, no jam. | 14:08 |
| dato | ah, weekend. right. :) | 14:08 |
| rto | Are some of you well versed in the bzrlib? | 14:09 |
| rto | Ok, i'll just try asking a question. | 14:11 |
| rto | The thing is, i would like to find out which revision are "local" to a branch. | 14:11 |
| rto | That is, when a branch is branched from another branch, i would like a way to find the revision commit'ed on the new branch - rather than all the branches from both the new branch and the branch i branched from. | 14:12 |
| rto | Basically i want a bzr log --local command or something similar | 14:13 |
| james_w | rto: bzr missing --mine-only otherbranch? | 14:32 |
| rto | james_w: That seems to be somewhere along the lines of what i want, but it only lists revisions that differ between the two branches. | 14:35 |
| james_w | so you want all revisions that were committed to the local branch and not another branch. | 14:36 |
| rto | james_w: Yep, that is basically it. Something like bzr log --local | 14:36 |
| rto | And preferably something where you don't have to give it another branch (or more) to compare with. | 14:37 |
| rto | Up til now i have been able to use branch-nick to something along the lines, so local revisions are the ones where the branch nick on a revision is the same as the branch's nick. | 14:38 |
| rto | But nick's can change, and i think there should be some way to tell revisions committed on the branch from revisions gotten from another branch. | 14:39 |
| james_w | rto: well what you are asking for is not that easy to define. All the information required to do this is certainly not stored by bzr. | 14:40 |
| james_w | the nick is the closest you can probably get, but as you say it's not perfect. | 14:40 |
| james_w | also bzr log --short is kind of like that too, but again it depends on the situation. | 14:41 |
| rto | Hmm, it just seems like something you would want to know, for instance bzrweb could show more relevant information by only showing the revisions on the particular branch. | 14:44 |
| james_w | rto: well you normally define that in relation to another branch, as missing does. | 14:47 |
| rto | james_w: But won't you end up with having to list all the branches that you have ever merged from in the past to show just "your changes"? | 14:48 |
| abentley | rto: No, merges don't show up in the lefthand ancestry. | 14:49 |
| abentley | That is, the revisions you merge don't show up there. | 14:49 |
| james_w | rto: yes, it doesn't scale to many branches. | 14:50 |
| abentley | So all you need to know is when your branch started. Everything on the lefthand ancestry since your branch started is stuff you committed. | 14:50 |
| rto | abentley: Ok, so i only need to list the branch i branched from | 14:51 |
| abentley | Yes. Or know the revision you branched at somehow. | 14:51 |
| rto | abentley: Now _that_ sounds like something bzr should be able to tell me, the point at which i branched, or whether this branch is a branch of something else in the first place. | 14:53 |
| abentley | It would make sense to store that, I agree. | 14:53 |
| abentley | Some of our early decisions were based on the assumption that we wanted "cp -a" to be the standard way of branching. | 14:54 |
| abentley | That's why we don't have a branch ID or a branch-point marker. Those things are useless if copied verbatim. | 14:55 |
| abentley | Since cp -a is not commonly used for branching, we could revisit that. | 14:56 |
| rto | abentley: Ahh, that makes sense. | 14:57 |
| pygi | hello all | 16:57 |
| pygi | would anyone be interested in writing a bzr adapter for rvcs? estimate is that it's around 500 lines of code =) | 17:01 |
| james_w | pygi: the Road Vehicle Certification System? | 17:06 |
| pygi | james_w: actually, it's not :) | 17:07 |
| pygi | Ruby Version Control System Abstraction Layer | 17:07 |
| james_w | pygi: what does it take? | 17:08 |
| pygi | james_w: what do you mean? | 17:08 |
| james_w | you need a ruby mapping to all concepts? Or just a way of getting the latest version of the code for build scripts or what? | 17:09 |
| james_w | and where's the code? | 17:09 |
| pygi | james_w: gimme a second :) | 17:09 |
| pygi | svn checkout http://rvcs.rubyforge.org/svn/trunk | 17:10 |
| james_w | ah, ok. Doesn't look too hard, but I don't know ruby, sorry. | 17:12 |
| pygi | james_w: it's not too hard ... I'd implement it myself, but currently playing with the abstraction code itself | 17:12 |
| pygi | I think that's a good way to bring bzr to ruby community =) | 17:13 |
| loswillios | hej | 17:14 |
| loswillios | I'm having some problems with bzr, seems that something isn't in its correct path: http://pastebin.com/m4eb18ec3 | 17:19 |
| loswillios | can somebody help me with that? | 17:19 |
| james_w | loswillios: how did you install bzr? | 17:20 |
| loswillios | aptitude install bzr | 17:20 |
| loswillios | I have bzrlib in /usr/lib/python2.4/site-packages/ and /usr/share/pycentral/bzr/site-packages/, I guess I need to put that in some $PATH | 17:21 |
| james_w | loswillios: python --version? | 17:22 |
| loswillios | python -V: Python 2.4.4 | 17:23 |
| loswillios | urgs | 17:25 |
| loswillios | Version: 0.11-1.1 | 17:25 |
| loswillios | I guess that's way too old right? | 17:25 |
| pygi | is that bzr version loswillios? :P | 17:25 |
| pygi | yes, that's way too old :D | 17:25 |
| loswillios | debian... | 17:26 |
| loswillios | thanks james_w | 17:26 |
| loswillios | hmmz | 17:31 |
| liw | I'm doing a "bzr add" in a source tree that happens to contain sub-directories which contain .svn dirs, and bzr-svn (I assume) wants to connect to the svn server -- is this expected behavior? | 17:31 |
| loswillios | even with 0.91-2~bpo40+1 from backports.org I have that problem | 17:31 |
| loswillios | weird stuff | 17:32 |
| loswillios | anyone another idea on that? | 17:40 |
| pygi | so anyone knows a bit of ruby and willing to write a bzr module? ^_^ | 17:42 |
| abentley | loswillios: It sounds like bzr thinks you're trying to add files to the svn checkout. | 17:43 |
| abentley | sorry, I meant liw | 17:45 |
| james_w | loswillios: can you run python and then run import sys; print sys.path | 17:45 |
| liw | abentley, that perhaps be a reasonable assumption, I guess | 17:47 |
| liw | (why people put .svn dirs in release tarballs I do not know; I only put CVS ones in by mistake, but some people do it intentionall, go figure) | 17:47 |
| loswillios | james_w: ['', '/usr/lib/python24.zip', '/usr/lib/python2.4', '/usr/lib/python2.4/plat-linux2', '/usr/lib/python2.4/lib-tk', '/usr/lib/python2.4/lib-dynload', '/usr/local/lib/python2.4/site-packages', '/usr/lib/python2.4/site-packages', '/var/lib/python-support/python2.4'] | 17:48 |
| abentley | liw: It means that you can immediately start working on the code from the tarball. | 17:48 |
| abentley | I was actually going to propose that bzr export start doing that. | 17:48 |
| liw | abentley, ugh | 17:49 |
| abentley | A lightweight checkout doesn't require very much space. | 17:49 |
| loswillios | james_w: bzrlib is in /usr/lib/python2.4/site-packages/ | 17:49 |
| abentley | And it means you can update to the latest code if you want. | 17:49 |
| abentley | Or convert it to a branch with "bzr reconfigure --tree" | 17:50 |
| james_w | loswillios: so can you do 'import bzrlib'? | 17:50 |
| liw | abentley, as long as you make it optional, I won't mind | 17:50 |
| loswillios | james_w: nope, ImportError: No module named bzrlib | 17:50 |
| liw | if I want a branch, I'll make a branch; I use "bzr export" to make release tarballs, and I don't want any vcs metadata there | 17:50 |
| james_w | loswillios: weird. | 17:52 |
| === me_too is now known as too_short | ||
| === too_short is now known as me_too | ||
| loswillios | indeed | 17:53 |
| abentley | liw: You aren't the person who will be using the tarball. | 18:11 |
| liw | abentley, yes I am | 18:11 |
| abentley | Really? No one else uses your software? | 18:12 |
| liw | there are other users (at least sometimes), but that doesn't mean I don't use the tarball myself | 18:12 |
| abentley | Well, I am thinking of software that has many users who are not the author. | 18:14 |
| liw | abentley, I am not opposed to having an option to include .bzr/ in the export, if the user wants it | 18:15 |
| liw | abentley, but if you don't retain the current behavior, then I think you're making a mistake | 18:15 |
| abentley | All I'm talking about is bringing it up for discussion. | 18:16 |
| abentley | But I think that it's in-line with open-source ideals to make it easy to start hacking on the software you've just downloaded. | 18:17 |
| liw | and therefore you want to make it difficult to not include the .bzr stuff even for people who don | 18:18 |
| liw | 't want it? | 18:18 |
| abentley | liw: I think that it might be nice to make it a lightweight checkout by default. | 18:19 |
| abentley | Because I think that in the common case, the author will not be the tarball user. | 18:19 |
| liw | and I think having any vcs metadata in a release tarball is bad, since it messes up with the downloader's ability to set up their own version control | 18:21 |
| abentley | Could you expand on that? | 18:23 |
| liw | I've never had any use for any .svn, .bzr, .git or other such metadata included in a release tarball; rather, they interfere with things when I want to import the sources into a new branch I've created myself | 18:25 |
| liw | or prevent me from creating such a branch before I clean up | 18:25 |
| liw | if I want to branch off upstream's branch, I already have tools for that; putting extra stuff in tarballs does not give me new functionality, but does make more work for me | 18:26 |
| liw | (further, not all bzr branches are for software projects, of course; the .bzr stuff is of zero use for, say, when I create a zip of a document project to send to my father) | 18:29 |
| === me_too is now known as too_short | ||
| === too_short is now known as me_too | ||
| === me_too is now known as too_short | ||
| === too_short is now known as me_too | ||
| === abadger1999 is now known as abadger_afk | ||
| === cfbolz__ is now known as cfbolz | ||
| === cfbolz_ is now known as cfbolz | ||
| === cfbolz is now known as cfbolz_____ | ||
| nekohayo | hello, is there any reason for my 3 bugs with patches (for example, https://bugs.launchpad.net/bzr-gtk/+bug/151824 ) still lying around, in an unconfirmed state, after one month? | 22:13 |
| ubotu | Launchpad bug 151824 in olive "use single click for bookmarks" [Undecided,New] | 22:13 |
| nekohayo | did I file them on the wrong components? | 22:13 |
| pygi | hello | 22:13 |
| pygi | anyone with at least little ruby knowledge willing to write bzr adapter for rvcs?? | 22:13 |
| beuno | nekohayo, let me take a look. It might be due to 1.0 release being so close by | 22:25 |
| beuno | a lot of attention is diverted toward that | 22:25 |
| beuno | nekohayo, seems filed correctly, maybe you could email the list with the bug numbers so they can be looked at? | 22:26 |
| pygi | anyone? :P | 23:04 |
| nekohayo | beuno: wha, 1.0 already? of bzr or bzr-gtk you mean? | 23:18 |
| jelmer | nekohayo: manpower mostly | 23:19 |
| beuno | nekohayo, bzr | 23:19 |
| jelmer | nekohayo: there's only a couple of us working on bzr-gtk, and we're quite busy with other things as well | 23:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!