[00:00] well [00:00] i'm not sure 'common' is the right measure, compared to [00:00] Maybe there's something involving graph logic that already would help bzrlib? [00:01] I mean, [00:01] if there are cases where we need it, how much trouble or friction or [00:01] maybe there's already an operation bzrlib does, or would like to do, that could benefit from this? [00:02] sory about interruption [00:02] hardy is not _that_ stable [00:03] I'm saying that the structure I understand you to be heading towards is hand coded [00:03] but needs on the wire the exact same degree of encapsulation [00:04] so why not just define the encapsulation, then let the client and server use them as desired [00:09] Basically, the tradeoff is at the moment the encapsulation encoder/decoder has a pretty simple interface with the objects that use it, and there's a single place that knows things like "this message part is a body". If we generalise, we push that work to the individual message handlers. [00:09] I guess that's manageable, but I'm also not sure it's work that we'll get much benefit from. [00:10] well [00:11] you could make sure the wire protocol is generalised [00:11] and then only add api complexity as needed [00:11] Hmm. [00:11] long as the error-handling cases the protocol object knows how to eat the entire entity we're good to extend it later. [00:11] (extend in the python code I mean) [00:12] so START, TUPLE|BODY+, END [00:12] Right, similar to the container format... [00:12] where TUPLE and body are both self delimited [00:12] and BODY is able to be ended_complete and ended_incomplete [00:13] lol https://pqm.bazaar-vcs.org/ refuses to show in ff3 [00:14] And if a body is ended_incomplete, then it can be followed by another TUPLE? [00:14] (as a convention) [00:14] right [00:14] but even if not we'll know it was incomplete [00:15] and can error regardless [00:15] Well... [00:15] that's the sort of thing that bugs me :) [00:15] More options == more cases == more tests & work :P [00:16] ok [00:16] up to you [00:17] I've exhausted my ideas on this, but it seems pretty clear to me that there are different layers here [00:17] It's not so much that that one part is a big concern, but it's the sort of thing that we're enabling with this plan. [00:17] lifeless: wtf [00:17] lifeless: maybe it was just bad timing [00:18] but going to pqm.bazaar-vcs.org just crashed my kernel :-) [00:18] jelmer: LOL [00:18] !! [00:18] Wow. [00:18] jelmer: get a new kernel [00:18] Before You Die, You See... [00:18] maybe it'll work better if I run a kernel out of bzr instead of out of git... [00:19] lifeless, i think it's a good point about the protocol [00:53] spiv, lifeless, i think we should allow for it in the protocol doc [00:53] the actual encoding iirc would already support this [00:57] brb, fixing a KnitCorrupt in Mary's PhD branch... [00:58] ouch === jamesh__ is now known as jamesh [01:16] Newlines in filenames leads to broken inventory.knit... [01:16] it seems the dapper packages of bzr on ppa don't work? they're complaining about not having python2.5 when I try to install them [01:20] radix, yes, it's bug 189915, i'm working on it [01:21] poolie: cool, thanks [01:23] fwiw, the reason it's not working for me is bzr: Depends: python (> 2.5) but 2.4.2-0ubuntu3 is to be installed or [01:23] python-celementtree but it is not installable [01:24] which doesn't seem to be exactly what bug #189915 is talking about [01:24] Launchpad bug 189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Critical,In progress] https://launchpad.net/bugs/189915 [01:46] lifeless, what is the best address for the bzr packaging team? [01:46] ^branch [01:46] http://bzr.debian.org/pkg-bazaar/bzr/ubuntu/ ? [01:48] http://bzr.debian.org/pkg-bazaar/bzr/unstable/ [02:11] ok [02:11] the changelog for the pakcage i took from bazaar-vcs.org is somewhat diverged from that [02:11] starting with your "New bazaar-vcs.org build" on 3 dec [02:22] poolie: yes, merged numerous times; but theres nothing in the bazaar-vcs.org devel-distro-release packags that wasn't sent back to bazaar-vcs.org [02:22] possibly some dependency differences [02:23] and the dapper package has the patch from the bzr list [02:30] abentley: ping [02:30] abentley: I'm looking for the branch nick on bb, I can't see it [03:28] anybody around who has experience using the cvs plugin for bzr? [03:30] lifeless: I think it's not there. [03:30] LaserJock: do you mean cvsps-import ? [03:30] I assume you want the branch nick from the last-committed revision? [03:30] yes I guess that's the one [03:31] We do have the source branch location, if the user provides it. [03:32] lifeless: I'm assuming I can use cvsps-import to track a CVS repo [03:33] abentley: yes, I'd like it to be visible [03:34] LaserJock: I don't know if it can do incremental or not; it certainly doesn't have the logic to handle all the idiocies people can do to cvs like cscvs does [03:35] well, I've been using git-cvsimport and it seems to be working well [03:35] I'm just trying to figure out the bzr equivalent [03:38] LaserJock: well cvsps-import is the plugin to examine [03:39] I've used it for one-shot conversions very successfully [03:39] k [03:45] I have about 14 different VCS repos in CVS, SVN, bzr and I thought I might give it a go at trying to just use bzr for everything [03:45] Riddell keeps saying it's the only way to go :-) [03:50] LaserJock: riddel is right :) [03:51] bzr-svn will get your svn stuff beautifully [03:51] for CVS, just one-shot convert and never look back [03:51] well, I don't own the CVS repos so I'll have to keep updating periodically [03:51] ok [03:51] have a look at it; or use the launchpad cvs service [03:52] hmm [03:52] actually one of them is already in launchpad === asac_ is now known as asac [04:11] I wonder how hard it is to 0wn a CVS repo [04:12] its ok security wise, if you like crunchy shell [04:29] what's a better merge type to use for criss-cross merges (in bzr 1.1) ? [04:30] http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01212.html [04:30] thumper: --lca [04:30] spiv: so `bzr remerge --lca`? [04:31] thumper: yeah. [04:32] 7 conflicts -> 2 conflicts \o/ [04:33] both of which were entirely valid [04:33] when is --lca becoming the default? [04:33] abentley: ^ [04:36] lifeless, how can i avoid dpkg-source complaining about the binaries in the debian/.bzr directory? [04:36] -x .bzr [04:36] ok, i have to give that every time? [04:36] or use bzr builddeb to do most of the machiner for you [04:37] bzr builddeb --working --builder="pdebuild-$distro --override-config" [04:37] thats how I built the packages [04:38] so to do that i should have the source in one branch, and the debian/ directory in another branch checked out below it? [04:40] * poolie reads the maunal [04:42] lifeless, so it looks like people are using it in "merge mode", since the packaging is alone in a branch? [04:45] thumper: I would give it another release cycle. See I got this new job, and it's been a lot to learn all at once... [04:46] Unfortunately, there's some work needed before it's a complete replacement for merge3. It doesn't do reverse-cherrypicks, and there's an edge case where it doesn't give a conflict when it should. [04:57] later all [04:57] have a good weekend [04:58] lifeless: later [04:59] poolie: you have mail; if you want a call ring now :) [05:00] thanks [05:00] no i don't think so [05:00] am just learning more about builddeb === jamesh_ is now known as jamesh [07:58] hi! getting "bzr: warning: unknown encoding . Continuing with ascii encoding." every time I call bzr. [07:59] echo $LANG reports C [07:59] LC_ALL is not set [07:59] tried exporting LANG as sv_SE.UTF-8 too, still the same message [07:59] Mac OS X 10.5.2 [08:05] Eww, UTF-8 [08:05] Latin1++ [08:21] New bug: #188058 in bzr-gentoo-overlay "Launchpad transport error installing bzr-vimdiff-0_pre17 (dup-of: 181945)" [Medium,Incomplete] https://launchpad.net/bugs/188058 [08:34] So, I've pushed my source to my server -- bzr update doesn't work, what do I run to initialize? [08:44] What's the best/recommended way to install bzr on OS X; easy_install or macports? === vila_ is now known as vila [08:51] kedmccabe: Probably what you're most used to working with [08:51] I used ports .. because, well I use it for lots of things and it's easy to keep stuff updated. [10:55] how's the support for cherry-picking these times? bzr still does not track them, right? [10:59] nope [11:01] :-/ [11:20] rotty: will be discussing this in the up coming sprint [11:23] so it could be implemented in the foreseeable future? [11:38] How do you ignore all files in a certain directory? Like bzr ignore dir/*, but that adds all specific files to the .bzrignore file .. should I manually edit the file? [11:38] :) [11:39] I think bzr ignore 'dir/*' should work [11:39] or "dir/*" on windows [11:39] (to disable the * in the shell) [11:40] sweet [11:40] worked, thanks :) [11:48] can you remove all ".svn" directories from your project somehow? [11:48] I added them, and the ingored them .. now I want to remove them :P [12:16] appcine: If you're on *nix or something, that would be easy. 'find -name .svn -execdir bzr rm {} +' or something. === asak_ is now known as asak [12:28] lifeless: I have an ideas for a new feature: tracking the currently-checked-out revision, so when you do "bzr get -r FOO", a subsequent "bzr status" will compare against the revision FOO and not HEAD [12:28] does that make sense? [12:30] jelmer: ping? [12:30] dato: pong [12:31] jelmer: I have a situation, and I'd like to know whether rebase could help. well. situation. I commited some stuff over a revision that I didn't thought it was there... [12:31] how much would I need to write to make rebase re-commit the good ones on top of $BAD-1 [12:31] I don't mind a dirty+ad-hoc solution [12:32] well, there's also the "replay" command that's part of rebase [12:32] oh [12:32] ooh [12:32] if you check out $BAD-1 then you can just run "bzr replay -r" [12:33] right [12:33] thank you [12:33] for $BAD+1 [12:38] I get a conflict, whereas I think I shouldn't get one [12:38] $BAD touches foo1.py [12:39] and $BAD+1 is a merge that does not touch foo1.py [12:39] ? [12:40] jelmer: ^ [12:46] rotty: Err? get == branch; it does do that... [12:47] fullermd: but "revert -r" doesn't, does it? [12:48] hello, i'm running into a repository compatibility problem with bzr hosted on launchpad. [12:48] Well, what you'd want for that use case isn't revert, it's "update -r". [12:48] i used svn-import to create a new branch on my machine. [12:48] Which comes with a minor hitch. [12:48] then i push it onto launchpad [12:49] but bzr co complains that KnitPackRepository is not compatible with RemoteRepository... [12:49] fullermd: according to "bzr update --help", update doesn't have that option "-r" [12:49] rotty: That's the minor hitch 8-} [12:50] i should say: I push it *first* and that works, then I try *bzr co* and that fails. [12:51] oh well, I used WorkingTree.commit for $BAD+1. replay did $BAD+2,3 fine [12:52] fullermd: is this implemented in bzr HEAD? [12:52] * fullermd shakes his head. [12:56] rotty: https://bugs.launchpad.net/bzr/+bug/45719 [12:56] Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,Fix committed] === kiko is now known as kiko-afk [13:18] Peng: Ah, yes. I'm on unix. Something like the find-command might work, but {} doesn't print the path to the file .. know how to do that? :) [13:20] appcine: It doesn't? What? Depending on your shell, you might need to escape it. [13:20] find . -name .DS_Store -execdir echo {} + [13:20] prints: .DS_Store .DS_Store .DS_Store [13:20] bash on os x [13:21] ah [13:21] appcine: Yeah, exactly. execdir 'cd'es to the directory and then executes it. [13:21] appcine: It's supposed to be safer. Shrug. [13:21] Peng: Hmm, hehe.. let me try again .. bzr reported that .DS_Store didn't exist [13:22] with --exec it worked [13:23] Peng: Nevermind me. I'm just sloppy. It works just fine. [13:23] Thanks for the tip === mrevell_ is now known as mrevell-lunch [13:32] fullermd: where can I get a recent version of this patch? [13:33] (the repos mentioned in the report don't apply to current HEAD anymore) [13:34] I don't think there is one. [13:35] :-( === mrevell-lunch is now known as mrevell [14:01] * fullermd ponders. [14:02] I guess poolie's long since gone for the night... [14:09] * lamont wonders when bzr 1.2.0 will hit the ppa [14:10] lamont: it did yesterday [14:10] or well, the buildds and then failed [14:10] it's not there.... [14:10] so eh yeah, can't use it yet :) [14:12] * lamont notes the lack of a debian directory in the tarball, too [14:14] lamont: which one, upstream? [14:14] launchpad.net/bzrtools/... [14:15] I'm not clear on what you mean, but fwiw there are something like 4 different debian dirs needed [14:15] since dapper/etch/sid are all different enough that there is no universal packaging (yet?) [14:16] most people tend to package something that's the latest... [14:17] as the Bazaar project, debs for all those distributions need to be made [14:18] anyway, I haven't been involved in that area for a while now === kiko-afk is now known as kiko [14:42] heh. it took longer to test the backport to dapper/edgy than it did to do it. === weigon__ is now known as weigon === kiko is now known as kiko-fud [15:14] * fullermd wonders whether 1.2 is officially released. [15:15] I see the file, but I haven't seen any announcements. [15:16] New bug: #145811 in nautilus-python "python-nautilus: Feisty: Python script's methods seem to be not called by extension." [Undecided,Fix released] https://launchpad.net/bugs/145811 [15:18] * rotty is annoyed that the "update -r" patch has been abandoned [15:19] Here's your number; there's the line :p [15:19] unfortunatly, I'm not able to forward-port the patch, as I don't have knowledge of bzr internals [15:20] I have an entirely off-topic quandary: I created a GPG key for myself 5 days ago. I had a copy of my private key on a server I don't own the whole time. Should I be paranoid and revoke it or not? I'm not using it for much so it would be no big deal if I did revoke it. [15:22] I s'pose it depends on how much you trust whoever has root on it. [15:24] Also, if I ever got a VPS, I might need to put the private key on it, which would be just as bad... [15:25] * fullermd shrugs. [15:25] Any hardware that anybody else ever has physical access to is insecure and untrustworthy if you're paranoid enough. [15:26] I'm trying to find the right level of paranoia. [15:30] and the changelog needs to be updated for 1.2 too.. === asak_ is now known as asak === kiko-fud is now known as kiko [17:50] is there any recent .deb of bazaar that works on dapper? [17:55] radix: https://launchpad.net/~bzr/+archive ? [17:55] Huh, Hardy and Dapper are the only ones that have had their 1.2rc1 debs built. [17:55] * Peng wanders off. [17:57] Peng: the dapper debs from ppa are broken [17:57] they depend on python2.5 [18:00] Oh. [18:00] Nice. [18:00] I dunno nothin' then. [18:00] * Peng wanders off. [18:00] Sorry I couldn't help. [18:32] Are the bazaar-vcs.org branches going to be packs? [18:32] I notice that they're still dirstate/knits currently [18:34] jdong, bzr.dev has been in packs for a while now [18:34] beuno@beuno-laptop:~/bzr_devel/bzr.dev$ bzr info http://bazaar-vcs.org/bzr/bzr.dev/ [18:34] Standalone branch (format: pack-0.92) [18:35] beuno: what? no way [18:35] * jdong questions his sanity [18:36] * beuno questions it too :p [18:36] beuno: oh I see my idiocy [18:36] beuno: I looked at bzr.1.2 [18:36] not bzr.dev [18:36] jdong, I think 0.92 and on have been in packs on bzr.dev. Especially since at that poing packs<>knits operations where painfully slow [18:37] WOW the performance difference with packs over HTTP is very noticeable [18:38] jdong, yeap, lifeless and jam did an amazing job at it :D [18:38] and I understand the smart server has improved greatly too [18:38] yeah I'm impressed at dumb http alone [18:38] I haven't branched something big from HTTP since packs came about [18:39] I think the "less amounts of round-trips" was the key [18:39] right, that's always been the case [18:39] gazillion knits vs a dozen packs [18:40] * beuno wonders why the 1.2 branch is in knits... [18:40] and no poolie around... :/ [18:41] beuno: yeah the 1.2 branch took nearly 5 minutes to get, while I just grabbed dev in under a minute [18:41] and looking @ how it's 85MB, most of that time would've been simply network transfer [18:42] jdong, I'll send an email to the list and see if it just got forgotten or if there is a good reason for it [18:42] beuno: cool [18:42] thanks for the heads up! [18:42] anytime [18:51] * jdong reconciles bzr.dev for fun [18:52] jdong, if it's in packs, it should be fairly fast. Knits, on the other hand, might take a while. I have 3gb branch that took 40+ hours to reconcile on a AMD 4000+ dual core [18:53] beuno: yeah right now the packs are taking over 10 min to reconcile, looks CPU bound [18:53] oh well, i twas for fun anway [18:54] jdong, you can also run "bzr check" if you feel like making the CPU sweat a while :p [20:00] someone should change the topic to mention 1.2 [20:02] and add a changelog entry [20:02] on the site [20:06] is there no way to pass bzr through an authenticating proxy? [20:09] it would seem according to bug 83954 that the support should be there [20:09] Launchpad bug 83954 in bzr "Error while using "bzr branch" through proxy" [Undecided,Fix released] https://launchpad.net/bugs/83954 [20:20] New bug: #156299 in bzr "bzr bash completion error (compgen: --: invalid option)" [Wishlist,Confirmed] https://launchpad.net/bugs/156299 === zmanuel is now known as z-man [21:09] GARRRRR [21:10] * mtaylor hates that Branch.open_containing() returns a tuple and not a branch. [21:10] just FWIW === kiko is now known as kiko-afk [21:59] hey my network is just awful but i need to copy a big bzr repo (300mb) to a server it always disconnect while doing it [22:00] is there a way to zip up the repo and rsync it there? [22:02] treeform_, "pull" has resume integrated [22:02] you can of course just rsync the folder [22:02] and/or zip it [22:02] you don't need anything special [22:03] beuno, does push has resume integrated? [22:04] treeform_, I'm not 100% sure, but I don't see a reason why not [22:04] it always errors out with a python stack trace so i think it bzr just crashes [22:04] treeform_, what version of bzr are you using? [22:05] if it's spitting out a traceback it should be a bug [22:05] 1.1 [22:05] sorry i would post the trace back but i dont have it [22:05] treeform_, would you happen to have a traceback handy that you can paste somewhere? [22:05] ah, right [22:05] i will run it again just wait about 10 min [22:05] well, just plain rsyning the dir will work just fine [22:06] but the dir is about 600mb [22:06] with the .bzr 300mb and the contents is 300mb [22:06] treeform_, can you run "bzr info" and see what repository type it is? [22:06] treeform_, I suppose you can rsync the .bzr directory and then just do "bzr revert" (which is sort of what bzr branch would do) [22:07] zip up .bzr, rsync that, unzip, "bzr revert" [22:07] (I'm sure there are better solutions though) [22:07] as long as that works [22:08] "Standalone tree (format: pack-0.92)" [22:08] oh my format is lower version [22:09] treeform_, that's the latest version [22:09] i been using bzr since .14 and never had reasons to upgrade but it looks like i did at .92 [22:09] oh ok [22:10] i think i needed to upgrade it because some one could not read it [22:10] That seems unlikely... [22:10] treeform_, if they have a pre 0.92 version than they might not be able to read packs [22:10] ok but i am up todate? [22:11] treeform_, if you have bzr 1.1 and are using the packs repository, yes [22:11] ok thanks [22:11] np [22:12] 1.1? Jeez, that's SO yesterday... [22:13] fullermd, i should upgrade? [22:13] fullermd, :p [22:13] treeform_, 1.2 is out _today_ [22:14] so 1.1 is _yesterday_ [22:14] upgrading is always recommended, but you're good at 1.1 [22:14] oh i just installed 1.2 on the server [22:14] that is how it crashes http://dpaste.com/35397/ [22:15] treeform_, it says you're using bzr 1.0 [22:15] and, a release candidate [22:15] ok 1.2 it is [22:16] I'd recommend upgrading to at least 1.0 final [22:16] treeform_, your traceback says: bzr 1.0.0.candidate.1 on python 2.5.1.final.0 (linux2) [22:17] yes it does [22:17] i am sure i am wrong [22:19] grr installing it also fails http://dpaste.com/35399/ [22:22] i got my current bzr is the latest in my repos [22:24] Assume we have a centralized shared repository for product foo. directory "foo" has been bzr init-repo'd. we then make branch "foo/head", and do work. Now, getting reading for a release, we bzr branch foo/head foo/release-1.0. Question: is there any way to see what branches are available within foo? (within bzr, that is...) [22:28] rthalley: not that I know of [22:28] rthalley: but a simple ls of foo will give you some idea [22:29] how does the bzr_access script work? I've added set up the .ssh/authorized_key file. Do I just invoke the script with the appropriate parameters? [22:29] rthalley: bzrtools provides a "branches" command that lists the branches under a given location [22:37] thanks, that's handy. now a "best practices" question... let's say we now finish foo-1.0 and ship it. do I tag foo/release-1.0 to indicate the version that was released? Do we worry about people still being able to commit to foo-release-1.0? [22:52] is it clean to clean .bzr/repository/upload by hand or is there a tool for it? [22:52] s/clean/safe/ [22:53] jdong: sounds like my dating career [22:54] mneptok: that probably explains the global shortage of nitrile gloves :) [22:55] some little developing conscience in my head is telling me I shouldn't go into .bzr with /bin/rm and whack out things I don't think belong :D [23:01] whatcouldpossiblygowrong [23:02] lol well ASS-U-ME-ing that nothing is uploading to the location, I would expect the 35MB of packs in upload to be simply in-transit cut-connection junk [23:03] jdong: you can't break your repository by removing the contents of upload. [23:03] * jdong saves this chat log ;-) [23:03] If someone was in the middle of uploading, you might cause their upload to fail with a nasty error. [23:04] awesome [23:04] this one branch I have, I regularly commit to it via a crappy connection... it's nearly double its pristine size because of cruft in upload [23:05] I'm wondering if bzr should have a command for dealing with cruft like that? [23:05] Well, perhaps robert can fix that, but it's not an open-and-shut case like obsolete-packs. [23:06] granted, else it would've been naturally fixed already [23:06] btw if you haven't heard yet, packs rock :) [23:06] I am astounded by the performance difference over plain HTTP [23:07] now if there's only a way for LP to upgrade all branches to packs rather than me having to sftp them. [23:07] Yeah, I did see your talk in the scrollback. [23:08] yeah, you guys really came through for me. That was just about the last complaint I had about bzr :) [23:08] jdong: You would not believe how snowed-under the launchpad-bazaar team is. [23:08] I don't think we'll have time for nice-to-haves in the near future. [23:08] I can imagine :( [23:08] oh well scrape-and-loop time :) [23:09] if there's one skill I've learned in my time around Ubuntu, it's how to abuse Launchpad :) [23:09] But create a blueprint, and then we'll at least have it in the system. [23:09] yeah, I'll do so in a sec [23:10] Seems like "smart server upgrade verb" would fill that niche pretty well. [23:10] well the thing is... [23:10] I don't think $average_lp_user knows or cares what the heck a pack is. [23:11] and I don't think people are aware in general of this massive speedup. LP should be more active in telling owners of branches to upgrade to packs === kiko-afk is now known as kiko [23:22] Where would you suggest we tell people about packs? [23:27] when was rich-root-packs added? [23:28] jdong: yes it should and I think there is a bug open for htat [23:28] mtaylor: 1.0 IIRC [23:29] mtaylor: bzr help formats or so should say [23:29] also bzr should start nagging soon [23:29] lifeless: thanks [23:49] anyone up to helping me brainstorm what tests I should include with the automatic plugin thingie? I've got working code and would like to strap on the tests and send to the list for initial review [23:53] beuno: You should test all the commands you add, and the major functions you add. [23:53] I'm not sure whether you're doing network stuff. That can be annoying, but you should be able to run your own server if necessary. [23:53] abentley, the problem is that I'm not actually adding any commands at this point, just catching unknown commands and checking to see if another plugin provides it [23:54] Okay, so you should be testing the command-line functionality you've added. === Verterok_ is now known as Verterok [23:58] abentley, right, I got that far. The question is a bit more specific. I should make the test execute a command that I know will be caught as a plugin and test if the output is correct? Maybe also commands that I know will be unknown and make sure they are still unknown? [23:58] Yes. [23:59] You don't necessarily have to do exhaustive tests of the commandline. [23:59] But that's pretty key functionality.