=== BasicMac is now known as BasicOSX === Peng_ is now known as Peng === Peng_ is now known as Peng [03:59] wow quiet day [04:00] we're all coding away before 1.0 closes ;) [04:08] I'm pinging out. :) [04:08] ;) [04:17] Peng: thanks for your patch to the docs; it's been merged I believe. [04:23] Lagggg. [04:23] lifeless: :) [04:23] 34.7s! [04:24] Peng_: :) [04:24] Peng_: did you see what I said ? [04:24] "thanks for your patch ...", yes. [04:24] Nothing after that. [04:25] that was all [04:31] Jesus! [04:42] Sighhh. [04:43] lagathon? === cprov is now known as cprov-zzz === me_too is now known as turbo0O === turbo0O is now known as me_too [09:48] abentley: yeah, thanks [11:47] How come `bzr gdiff` doesn't work if multiple files are given as arguments? [11:49] AfC, simply hasn't been implemented yet [11:49] jelmer: k [11:49] jelmer: do you need a bug for that? [11:50] AfC: please [11:50] Fine. [11:50] I've actually been meaning to try and get into the gdiff code [11:50] I'm not much for pygtk, but there are a couple of behaviours I want to recommend changing [11:52] [*every* single time I run it I a) maximize, then b) drag the Paned divider to give it enough room to show me the file names, then c) move from "combined" to first file.] [11:52] [getting a bit tedious] [12:03] there has been some talk about what to do with the diff window [12:03] perhaps we could call out to meld or something like that [12:03] jelmer: (meld?) [12:04] meld.sf.net [12:04] I came across some neat code in devhelp relating to remembering previous maximized-or-not state and acting accordingly to restore it on new instantiation. It's pretty good when done right. [12:13] moin [12:27] moin [12:31] allegedly [13:01] Using bzr-svn, is it possible to commit locally and then push the commits together to subversion later? [13:02] bzr commit in a bzr-svn branch always commits directly to the svn server. [13:03] not if you use 'bzr branch' instead of 'bzr checkout' [13:03] you can either unbind the checkout or use commit --local [13:04] I tried commit local, but it told me "bzr: ERROR: Cannot perform local-only commits on unbound branches." [13:04] but I can try to unbind [13:04] or check out again [13:04] thanks! [13:05] sverrej: it's a double negative - thats already unbound [13:05] One question about the new knitpack format: is it possible to automatically delete the obsolete packs in obsolete_packs, or is it even possible to stop bzr putting obsolete packs in there at all? [13:05] mneisen: they should auto delete; I thought I had merged that [13:05] I'll check [13:06] lifeless: I just did a small benchmark with the new format, and i ended up with about 60 megs of files in obsolete_files. [13:06] lifeless: I use the 0.92rc1 version of bzr. [13:06] I did a "rm foo.css" how can I bring a file back ... With svn I only needed to do "svn update" [13:06] mneisen: it's not merged sorry; I have a patch to clean it up though [13:06] Enquest: bzr revert foo.css [13:07] lifeless: great news. Hope to see it soon in the released packages ... :-D [13:07] mneisen: it'll be in 0.93/bzr.dev later today; it's unlikel to be cherry picked into 0.92 [13:07] OK. Thanks anyway ... [13:08] lifeless: Do you know by any chance when bzr-gtk will be up to speed, i.e. when bzr-gtk can be used with up-to-date bzr packages? [13:08] you can rm the contents of that dir safely [13:08] we use it to make operations wit flakey networks safer [13:08] lifeless:OK, will use rm. [13:08] just leave the dir itself around [13:15] lifeless: Anything about bzr-gtk (see above)? [13:16] it's just been released today [13:16] so 24 hours probably [13:19] lifeless: oic, didn't know that it was released today. [13:19] Thanks! [15:44] lifeless: "strict arch limits" (I'm unfamiliar with PAA) [15:45] er, PPA (see? :) [15:45] dato: it builds for i386, amd64 and lpia only (well, anything xen supports) [15:45] oh, and bazaar-vcs.org has ppc? [15:47] hope to soon; need to hook it up [15:47] currently amd64 and i386 only [15:48] and I doubt that we'd have a lot of lpia users [15:48] also I'd like to get rpm's up [15:48] lifeless: aren't there any plans to offer PPAs for debian chroots as well? (no idea about that) [15:49] why are debian packages on bazaar-vcs.org anyway? [15:49] sid is covered, lenny as usual, and I normally upload backports. [15:49] they used to be undermaintained in the past? [15:49] plus lifeless could do any of those uploads if/when necessary. [15:49] oh, I forgot backports. thanks dato! [15:50] (and backports is autobuilt these days) [15:50] dato: debian waits for releases [15:50] bazaar-vcs.org uploads beta's [15:50] lifeless: rc [15:50] sid gets rcs [15:51] and lenny, they'd migrate if there was time :) [15:51] It didn't in the past; [15:51] yeah, I'm just talking about the present [15:51] lifeless: we do since the pkg-bazaar team got into shape [15:51] but more importantly, when debian next starts to release it will probably stop taking bzr versions [15:51] when the UVF kicks in. [15:51] It's true that this may be next decade :) [15:52] there is backports.org for stable and oldstable [15:52] (I'm personally not uploading for oldstable atm) [15:53] siretart: and it's great the team is in shape - I'm in it too :) [15:53] lifeless: anyway, I'm not unhappy in any way, just wondering. [15:53] the basic thing is that the bazaar-vcs.org is geared around bzr's release cycle; even sid is geared around debians release ccle, so we need something for bzr enthusiasts during debian stabilisation. [15:54] (this is why we have ubuntu debs too) [15:54] the ubuntu one is much more visible because its 6 monthly [15:58] I'd also like to get daily builds up; its on my todo [15:58] we had them for baz and users lovd them [16:18] i'd like to put keep some of my system configuration files in /etc under revision control... so should i do something like "mkdir /etc/bzr ; cd /etc/bzr ; bzr init ; cd /etc" ? [16:19] and then, how would i add, say, /etc/make.conf to my new /etc/bzr repository? [16:19] oops [16:19] oh, that's right... i thought i mistyped that question [16:19] but it's typed correctly :) [16:21] or maybe i should just "cd /etc ; bzr init" and then just "bzr add make.conf" from /etc itself ? [16:31] statik: where are you ? [16:47] pattern: I simply put my entire /etc dir into bzr. [16:48] cd /etc; sudo bzr init; sudo bzr add; sudo bzr commit -m "version controlled /etc" [16:55] hi there, I am using bzr-gtk found in ubuntu gutsy [16:56] and olive does not seem to correctly recognize bzr branches on my disk [16:56] it only shows the directories and not the files, and offers disabled menu entries for handling the branch [16:58] how do I open a branch with olive? And how do I bookmark it? [16:58] it's such a simple program that you easily exhaust all the possible operations :) [17:29] nevans: nice :) [17:29] the only thing is that with gentoo, there's a lot of automatic messing with files in /etc [17:29] so i don't want to keep having to commit a ton of changes by hand [17:30] there are handful of files that i edit manually, and those are the ones i really want to keep under bzr's version control [17:30] anyway, the stuff that gentoo messes with itself are automatically kept under RCS version control via dispatch.conf [17:40] luks: hi [17:40] hi [17:40] I fixed problem with lock and pack repo in my branch [17:41] I just wonder: when you're planning to release QBzr 0.7.0? [17:42] hmm, I guess I could do it over the weekend [17:42] it will be great [17:42] pattern: I just do the whole /etc directory because it's easier. simply "sudo bzr add; sudo bzr commit", and you're done. I don't mind that I'm versioning a few extra things that I don't care as much about. [17:44] it's going to be a ton of extra things for me [17:44] on the other hand, when i do a "bzr status", it lists a ton of "unknown" files and directories [17:45] yeah, that's the other reason I do the whole thing... then I know when anything in there changes. [17:45] luks: do you still prefer to file wishes to QBzr in bug tracker? [17:45] pattern: I version just a few files out of /etc (and /usr/local/etc, and similar places). I just have '*' in .bzrignore, and manually add the bits I care about. [17:45] fullermd: that makes sense... that's what I do in my home directory. === BasicMac is now known as BasicOSX [17:46] bialix, yes, since otherwise it's very easy to forget them [17:46] err... the home directory itself ignores .* ...some of the subdirectories ignore * [17:47] (although... my home directory is actually still using svn, not bzr... and ignores behave a little bit differently in svn) [17:47] ahh... ".bzrignore" ... i should look in to that :) [17:47] luks: ok, because I have 2 new items to wishlist: search in qlog and working with tags in qlog window [17:47] search in qlog was on my unwritten todo list already [17:48] but please add it anyway [17:48] it's better to have all ideas on one place [17:48] can we collaborate on search feature sometime? [17:49] I haven't touched the code for a while, so I'm not sure when I'll have time and motivation to work on it [17:49] ok [17:50] I usually add new features only when something really annoys me or I'm really bored :) [17:50] me usually too === bac_afk is now known as bac [18:54] is there a way to uncommit a specific commit out of order? [18:54] perhaps undo changes is a better way of saying it [18:54] not really; there is a way to merge it out - to reverse it. But it is part of the written history so it can't be removed without rbeaking referntial integrity [18:55] so - 'bzr merge -r234..233 .' [18:55] that will remove commit 234 for you [18:55] (you need to commit after that naturally) [18:56] i made a commit that changed mysql functions to pgsql, now later on i just want to switch back to mysql... so bzr merge -r will allow me to do that? [19:03] yes [19:04] whats the diff between that and revert? [19:04] revert undoes all changes to the selected paths from the revision forward [19:05] spiv: reconcile on launchpad is up to 4.5Gb and no progress marker yet [19:06] so revert is full sequential, and merge is from points out of sequence [19:07] yes === cfbolz_ is now known as cfbolz [21:52] Hello! Does anybody have any experience with using bazaar on a branch on a hfsplus filesystem? I get permission errors (on .bzr/branch-format) when trying to add files. Moving the branch to ext3 fixes this... [22:04] dodijk: maybe jam-laptop knows about that, but he doesn't seem to be around right now [22:06] data: ok, i'll try again some other time === Mez|Away is now known as Mez === Mez|Away is now known as Mez === Mez|Away is now known as Mez === Mez|Away is now known as Mez === Mez|Away is now known as Mez [23:28] Is there a shortcut to create a new branch WITH the current changes in the tree? [23:29] nir, uncommited ones? [23:33] yea [23:34] nir, I don't think you can do that with bzr, no. As far as I can tell, bzr brings in the repository and restores the working tree from it [23:34] rsync would work though [23:34] branch ; merge --uncommitted [23:34] ah, there you go [23:35] I learn new things here everyday... [23:35] great [23:35] although branch --uncommitted would be even nicer [23:37] nir, you can file a bug requesting it. Unless fullermd has a good reason why not to have it [23:38] its a feature request, not a bug [23:40] nir, right, it would be wishlist, I don't believe there is something specific for feature requests in Launchpad [23:40] blueprints seem like and overkill, and I believe they don't have "states" so you would know when it gets implemented