[05:03] is there such thing as whitelist for bzr upload ? === mwhudson_ is now known as mwhudson === samgee_ is now known as samgee === jfroy is now known as jfroy|IB === jfroy|IB is now known as BZ|IB === BZ|IB is now known as IBZ [13:20] hello [13:23] i see that, according to the posts on ml, 2.2.1 performs much better...we're looking for a dvcs (excluding git) to use for open-source project...i played with monotone and i like it, but it's not much supported/widely_used...how does bzr compares with hg on Mac (linux will be main platform, and i know about explorer and tortoise hg for non-gui users, so wonder about Mac OS)? [13:24] gour: have you tried the OSX installer ? [13:25] vila: no, i'm not using Mac..any gui tool there? (i'm fien with cli, but for other potential devs) [13:25] gour: bzr-explorer is included [13:25] vila: ohh, that's great... [13:25] btw, how in general does bzr compare with hg today? [13:30] gour: I'm not a big fan of general comparisons, one has to use tools for his own needs to compare and decide, there are far too many differences in perfs and perceived ease of use to get a clear cut [13:32] that being said, I think the 2a format closed the gap with both hg ang git in terms of repo size [13:33] vila: i'm aware of bzr's ease of use, and although i like darcs/monotone, here i'm thinking about making it easy for others...performance was something bzr was always complained about, so i'm just questioning about bzr's adoption these days in comparison with hg [13:33] bzr has still a lot of potential areas for improvements, we'll get there when time permits ;) [13:34] ok..but not some big perf. holes in 2.2, iow, in par with hg? [13:34] well, if you ask *me*, I'd say perfs are roughly the same between hg abd bzr [13:34] yup [13:34] thanks [13:34] you're welcome [13:35] gour: the most important one I'm aware of for bzr these days if annotate with huge histories [13:35] i'm sad ian is not around any longer to see bzr's harvest :-( [13:35] :-/ [13:36] vila: have you ever tried monotone? [13:37] no. AIUI the data model is an interesting one, but implies that you can run into combinatorial explosions without notice [13:38] iow, it doesn't scale. But there are certainly interesting ideas for small scale sort of stuff (including a single submission from a single dev even for big projects) [13:39] security model with signed certs is really nice [13:43] oh, we have a pending bug for that in bzr ;-) Not a big amount of work, but nobody stepped up for it so far (well, I remembered one attempt but it was blocked because the contributor didn't want to sign the agreement :-( ) [13:43] git gives you those properties for signed commits [13:43] awilkins: I think gour is referring to a different part of the workflow, you *can* sign your commits with bzr [13:43] awilkins: i simply cannot stand git's 'design' [13:44] right. monotone allows you to have kind ogf QA [13:44] certs are supposed to be used to control access to repos in broader terms: can you push a set of revisions including ones you didn't create yourself [13:45] gour, I have found bzr much easier to grok than git ; I'm currently in the learning process for git because it has some properties that Hg and bzr do not in terms of a particular use case [13:46] bzr kind a 'favors' left branch during merge, right? [13:47] awilkins: git is ungrokable for me :-) [13:48] gour, I had a three day headache for Bazaar because I'd been using SVN for so long .... I kept checking merges very carefully because I couldn't actually believe it was that easy [13:48] he he...svn [13:49] git is rather the next step on that ladder - it does so many things silently and quickly, you're not sure anything actually happened [13:49] Makes one nervous [13:49] even shooting you in your own feet...silently :-D [13:50] gour, I'm having to tutor people on VCS this week - the management are insisting that I focus on SVN "because it's what we already use" rather than break new ground and help people to be more productive with DVCS [13:51] awilkins: :-( tell them about monotone as well ;) [13:51] Despite my last project having a team of 10 using Bazaar on a daily basis (these are non-programmers too, a few shell scripts to walk them through the merges and they are just fine 95% of the time) [13:51] awilkins: otoh, bzr can be used almost like svn [13:51] gour, I tried Monotone, I wouldn't go back to it [13:52] awilkins: why not? 1.0 is around the corner...actually 0.99 [13:52] gour, The bzr-svn plugin is excellent too ; by far the most seamless SVn interaction of any DVCS [13:52] gour, Although git-svn copes with boneheads who can't use VCS better [13:53] gour, It's mostly a question of popularity - I liked the properties of Monotone, but I honestly found it harder to pick up than Bazaar, and it's nowhere near as popular as git [13:54] * gour nods [13:54] So in terms of my VCS "portfolio", I'm going to pick the best-in-class for given roles and ignore the rest [13:54] bzr? [13:55] SVN - old fogies who want CVCS ; Bazaar - nearly everyone else ; git - For when you need Phenomenal Cosmic Power [13:55] lol [13:55] git - for Suicidal inclinations [13:56] e.g. - I'm looking at using git for the version control of object counts in the 10's of millions ; probably needs a lot of new porcelain but I can't imagine the inventory-based DVCS systems (Hg, bzr) coping with that. [13:57] git, OTOH, means that commits can re-use tree objects so where the edit rate is low the number of objects you have to add for a new commit shouldn't be too bad [13:57] monotone & sqlite3 back-end? [13:59] gour, I'd need to review the monotone data structure a bit and see if I thought it was a good for for this [13:59] awilkins: feedback on where in the merges people encounter problems highly welcome [14:00] awilkins: do it... [14:01] vila, Does Bazaar store inventories as deltas? [14:01] awilkins: with 2a we started seriously to stop requiring manipulating the inventory by using chk maps [14:02] awilkins: roughly yes [14:02] meh, *store* yes, but I think some parts of the code base still doesn't use it optimally (imbw though) [14:02] vila, The reason I'm only considering git for this 10s-of-millions-of-objects thing is that if you break the keys for the objects into "trees", then a new commit will re-use most of the existing tree objects ; only the trees with changed objects and their ancestors will need to change, so the revision storage size will be smaller [14:03] awilkins: yes, that's what drove the chk introduction [14:03] vila, Plus the project is hostile to reciprocal licenses and jgit has a liberal license [14:03] awilkins: but it mostly apply to inventories [14:03] awilkins: EPARSE reciprocal licenses ? [14:04] vila, GPL, anything with copyleft [14:05] vila, Government IT projects seem to have been convinced that GPL is evil by their corporate partners (who naturally want to be able to take all our hard work and sell it back to us) [14:05] awilkins: ... "viral" nature of GPL applying to versioned content non-sense ? [14:05] vila, No, I've not seen the "GPL applies to the data!!!" fallacy yet [14:05] pfew [14:06] I'm certainly biased, but my feeling is that more and more people start to grok the floss implications... [14:06] vila, But the last internal report I saw was rather biased, uses language like "permissive" for BSD-style and "non-permissive" for GPL, and had a number of inaccuracies [14:07] right, that's a small incremental progress :) [14:07] What I can't understand is the willingness to pour public funds into projects under a license that allows corporate types to take the code and make proprietary projects out of it [14:07] hehe, exactly [14:08] * gour will use gpl3 licence for upcoming project [14:08] the day people will realize that people money is so better use when funding public projects (which GPL is *all* about), things will change [14:08] I know that the perception is that the companies will take their ball and go play somewhere else... but - really? They are going to turn down a slice of the £12 Billion NHS IT budget? [14:08] s/use/used/ [14:08] Even our internal open-source advocates are nervous about copyleft [14:09] I've yet to see companies *losing* by turning GPL, whereas new ones *win* every day [14:09] and following Oracle moves these days is... interesting :) [14:10] I'll use GPL for internal tools in preference to proprietary code, even if we already have licenses for it, just because it means I can fix the bugs myself and not have to wait for support [14:11] community support is a reality hardly denied these days... [14:11] And I'm presently operating a policy of turning down requests for Office documents as output formats for reports unless they can justify a 5-fold increase in costs for that module :-P [14:12] Just an estimate. But I know for sure that it's harder than CSV or HTML. [14:12] oh, you mean the *other* Office, not the open one ? [14:13] I give my best wishes to http://www.documentfoundation.org/ ... [14:13] Not tried ODF exports [14:13] We have the input filters installed so I guess they'd be able to view them in Office. [14:13] We just cancelled our NHS-wide agreement for MS products, so everyone is having to audit themselves [14:14] Or so I hear... Mentioned it to Mr Shuttleworth (shameless-namedrop) in the release party channel and he wanted the phone number for our IT director :-p [14:14] hehe [14:15] An "office of open office migration investigation" would cost us much less than our Software Assurance I'm sure [14:16] Naieve numbers would be say, 1M licenses at SA rates of 29% of retail - ~ £125M per annum [14:16] For Office Pro [14:17] For £62.5M I'll fork, maintain, support and train NhsOpenOffice, and run a "MS addiction clinic" for people with VBA Macros and Access databases. [14:17] rotfl [14:17] (and buy a place in the Maldives :-P ) [14:18] hehe, yeah, think about giving even part of that to http://www.documentfoundation.org/ instead of forking.... [14:19] if only to make other organizations think about doing the same... [14:19] Indeed. My fork would be a thinly branded branch of the official one - and I'd probably subcontract a lot of that cash to documentfoundation.org :-) [14:19] and compare what has been invested in the MS one and what we got in return... [14:20] A few NHS useful plugins like ... oooh, GPG support for confidential patient records. [14:21] people always ask me: but how is floss making money ? To which I like to answer: look, it works, you use it more and more and you didn't put *any* money in it, now, think about giving a small percentage of what you gave to proprietary software... What do you think you will get in return ? [14:22] And by the way, when was the last time you found you couldn't open one of those documents you created 10 years ago ? [14:22] The answer is - exactly what you wanted, instead of what the focus groups in Richmond wanted. [14:23] ..and more ;) [14:23] FOSS offers you the opportunity to engage in patronage again [14:24] with the guarantee that nobody will be able to steal it anymore.. what did you say about GPL again ? :-D [14:24] Only you get to build on the shoulders of giants, unlike Michaelangelo or Da Vinci [14:24] Who were great but had to start from scratch [14:24] growing giants :) [14:50] is the output of 'bzr status -S' supposed to match that of 'svn status' closely? 'bzr help status' isn't too clear. [14:54] The status columns aren't wide enough to match SVN [14:54] So I'm guessing no [14:55] SVN has more columns out front (6 AFAIK) [14:58] yeah, 7 [15:03] actually a little different from SVN; e.g., for a new file svn shows 'A foo', bzr st -S '+N foo' [15:21] launchpad is broken with py2.7; it's fixed on trunk (allegedly); trunk is on launchpad :-[ [15:23] can you bzr export trunk from another machine? [15:25] maybe, let me try [15:29] yes, the tricky part will be getting it into system without breaking anything [15:30] maybe it's sufficient to replace the plugins/launchpad directory? [15:32] Depends what the problem is i guess, but sounds like it should work [15:33] in fact, you might be better off grabbing the launchpad plugin folder and putting it into ~/.bazaar/plugins [15:34] Glenjamin: is there separate project/repository for that? [15:34] afaik, no - you'll have to grab the whole bzr trunk and copy it out (or symlink it) [15:36] nope, it still causes error with xmlrpclib [15:37] what OS are you on? [15:37] gentoo linux ~amd64 [15:37] but maybe I grabbed wrong version of bzr [15:38] if you built it from source, you should just be able to grab trunk and make && sudo make install [15:39] or if you have multiple pythons installed, you might be able to force the bzr executable to use 2.6 [15:45] Glenjamin: hmm, but I don't have paramiko installed for 2.6, is that necessary for pulls from launchpad? [15:45] if you set BZR_SSH=ssh i think you can fall back to the system ssh executable [15:45] i havent' done that for a while though, so no promises [15:49] lp:bzr is supposed to be the trunk, right? [15:49] typ [15:49] *yup [16:01] I still get this: http://paste.pocoo.org/show/273593/ can you confirm that this is the fixed error? [16:08] yeah, thats the issue [16:08] https://code.launchpad.net/~toshio/bzr/python27-lp-fix/+merge/35487 [16:08] thats the fix [16:16] so it's not bug with launchpad but with bzr http transport [16:16] that explains it [16:48] so I slapped the patch on top of source package and it seems to work, thanks [16:50] btw when is next release scheduled? [16:51] not a clue, i'm just a user :) === Ursinha-afk is now known as Ursinha === Ursinha is now known as MaverickIsOut === MaverickIsOut is now known as Ursinha [18:49] anyone have a good cia hook? the only one I can find relies on bzrlib.delta.compare_trees which has apparently been deprecated quite a while ago and since removed [18:51] bkgood, hi [18:52] bkgood, the bzr-cia plugin on launchpad should be up to date [18:52] if that raises deprecation warnings, please file a bug [18:58] jelmer_: no deprecation warnings, thank you! might want to update http://doc.bazaar.canonical.com/plugins/en/cia-plugin.html === ddaa1 is now known as ddaa [22:40] mornin all