=== jaguarondi_ [n=david@82.243-246-81.adsl-dyn.isp.belgacom.be] has left #bzr [] === cprov is now known as cprov-afk === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr === Demitar [n=demitar@c-212-031-182-147.cust.broadway.se] has joined #bzr === BasicOSX [n=BasicOSX@216-250-174-201.static.iphouse.net] has joined #bzr === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr [01:08] yay net fuckage === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr === pete__c_ [n=pete@032-461-712.area7.spcsdns.net] has joined #bzr === mpt [n=mpt@canonical/launchpad/mpt] has joined #bzr === Admiral_Chicago [n=FreddyM@ubuntu/member/admiral-chicago] has joined #bzr [01:27] Ok, this may be a silly question [01:28] But is there any way to revert to how a file/tree looked on a particular date? [01:28] Short of first using bzr log to find the newest revision before that date? [01:28] bzr revert -r date:2007-09-30 [01:28] See 'bzr help revisionspec'. [01:28] Neat! [01:29] Yeah. [01:31] And that's not mentioned directly in "bzr revert --help" because revisionspec is also used by diff [01:31] hmm === Admiral_Chicago [n=FreddyM@st074039212101.monm.edu] has joined #bzr === pete__c [n=pete@032-461-712.area7.spcsdns.net] has joined #bzr === BasicOSX [n=BasicOSX@216-250-174-201.static.iphouse.net] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr [01:41] mpt: we should add a seealso to revisionspec I guess [01:41] brb [01:43] lifeless, it already says "See 'help revisionspec' for details", I just didn't realize that the "details" would be interesting or relevant to ARG [01:45] because they were on a separate line [01:45] which is an accident of how long "-r ARG, --revision=ARG" is [01:46] mpt: A lot of commands use -r. === bitmonk [n=justizin@adsl-76-192-203-38.dsl.pltn13.sbcglobal.net] has joined #bzr === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === bitmonk [n=justizin@adsl-76-192-203-38.dsl.pltn13.sbcglobal.net] has joined #bzr === jml [n=jml@ppp108-61.static.internode.on.net] has joined #bzr [01:59] hi [02:01] mpt: this is true, but can we make it more clear [02:12] mpt, lifeless, hello === BasicOSX [n=BasicOSX@216-250-174-201.static.iphouse.net] has joined #bzr === kiko is now known as kiko-zzz === orospakr [n=orospakr@64.230.44.161] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr === ajmitch_ [n=ajmitch@port166-123.ubs.maxnet.net.nz] has joined #bzr === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === Admiral_Chicago [n=FreddyM@ubuntu/member/admiral-chicago] has joined #bzr === mpt [n=mpt@canonical/launchpad/mpt] has joined #bzr === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr === asak [n=alexis@201-0-38-199.dsl.telesp.net.br] has joined #bzr === pacharasil_ [n=astromme@12-214-205-206.client.mchsi.com] has joined #bzr === herzel104 [i=herzel@gateway/tor/x-3eac73957eb94f65] has joined #bzr === Mez_ [n=Mez@ubuntu/member/mez] has joined #bzr === Vernius [n=tomger@p508AF23C.dip.t-dialin.net] has joined #bzr === thatch [n=thatch@pool-71-96-248-177.dfw.dsl-w.verizon.net] has joined #bzr === bigdog [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr === michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr === kiko-zzz [n=kiko@canonical/launchpad/pdpc.supporter.active.kiko] has joined #bzr === ubotu [n=ubotu@ubuntu/bot/ubotu] has joined #bzr === niemeyer [n=niemeyer@200-140-230-150.ctame705.dsl.brasiltelecom.net.br] has joined #bzr === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr === cory_ [i=cory@zeus.penguinhosting.net] has joined #bzr === AnMaster [n=AnMaster@unaffiliated/anmaster] has joined #bzr === dous_ [n=dous@ubuntu/member/dous] has joined #bzr === statik [n=emurphy@canonical/launchpad/statik] has joined #bzr === abentley [n=abentley@64.229.18.231] has joined #bzr === joejaxx [i=joejaxx@fluxbuntu/founder/joejaxx] has joined #bzr === arjenAU [n=arjen@mysql/community/arjenAU] has joined #bzr === elijah [n=whatever@c-69-252-219-78.hsd1.nm.comcast.net] has joined #bzr === vila [n=vila@lec67-4-82-230-53-244.fbx.proxad.net] has joined #bzr === mw [n=mw@189.146.13.202] has joined #bzr === BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr === _logger_ [n=_logger@adsl-75-51-62-134.dsl.chcgil.sbcglobal.net] has joined #bzr === probablydrew [n=drew@ip72-211-146-73.tc.ph.cox.net] has joined #bzr === duckx [n=Duck@tox.dyndns.org] has joined #bzr === Vantage13 [n=Vantage@www.toddcharron.com] has joined #bzr === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #bzr === welterde [n=welterde@gandalf.srv.welterde.de] has joined #bzr === mlh [n=mlh@c211-30-211-232.belrs1.nsw.optusnet.com.au] has joined #bzr === hmeland [i=29578@klodrik.uio.no] has joined #bzr === metze_asleep [n=metze@ip-217-172-181-76.mx-netz.de] has joined #bzr === mwh [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr === spiv [n=andrew@86.228.233.220.exetel.com.au] has joined #bzr === Solarion [n=solarion@cruftix.physics.uiowa.edu] has joined #bzr === sii [n=sii@tranquillity.sii.se] has joined #bzr === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #bzr === meuh [n=meuh@pdpc/supporter/active/meuh] has joined #bzr === jeremyb [n=jeremy@unaffiliated/jeremyb] has joined #bzr === james_w [i=jw2328@jameswestby.net] has joined #bzr === alla [n=alla@soy.cyber.com.au] has joined #bzr === Sigma [n=yann@pdpc/supporter/active/Sigma] has joined #bzr === jrydberg [n=johan@213.115.45.46] has joined #bzr === mneptok [n=mneptok@canonical/support/mneptok] has joined #bzr === radix [n=radix@70.91.133.157] has joined #bzr === Peng [n=mnordhof@fl-69-69-140-112.dyn.embarqhsd.net] has joined #bzr === ike [i=ike@unaffiliated/ike] has joined #bzr === grantgm [n=gabriel@d57-194-175.home.cgocable.net] has joined #bzr === taaz [n=dlehn@66.37.66.32] has joined #bzr === [PUPPETS] Gonzo [i=gonzo@80.69.47.16] has joined #bzr === SteveA [n=steve@canonical/launchpad/SteveA] has joined #bzr === dato [n=adeodato@debian/developer/adeodato] has joined #bzr === siretart [i=siretart@ubuntu/member/siretart] has joined #bzr === beuno [n=beuno@ubuntu/member/beuno] has joined #bzr === tsuno [n=michael@ninthorder.com] has joined #bzr === dirker [n=dirker@woosome.net] has joined #bzr === ryanakca [n=ryan@ubuntu/member/ryanakca] has joined #bzr === Odd_Bloke [i=oddbloke@compsoc.sunion.warwick.ac.uk] has joined #bzr === NfNitLoop [i=codyc@cpe-70-112-28-217.austin.res.rr.com] has joined #bzr === uws [n=mathilda@213.207.93.150] has joined #bzr === fullermd [n=fullermd@adsl-072-148-013-213.sip.jan.bellsouth.net] has joined #bzr === quicksilver [n=jules@212.69.38.59] has joined #bzr === mpt [n=mpt@canonical/launchpad/mpt] has left #bzr ["http://mpt.net.nz/"] === ajmitch_ is now known as ajmitch === Mez [n=mez@ubuntu/member/mez] has joined #bzr === pete__c [n=pete@032-461-712.area7.spcsdns.net] has joined #bzr === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr === marianom [n=marianom@ubuntu/member/marianom] has left #bzr [] === jml [n=jml@ppp108-61.static.internode.on.net] has joined #bzr [03:13] poolie: just filed a bug [03:13] thanks [03:20] New bug: #147916 in bzr "support for checkout of readonly url has regressed" [Undecided,New] https://launchpad.net/bugs/147916 === BasicOSX [n=BasicOSX@216-250-174-201.static.iphouse.net] has joined #bzr [03:30] http://live.gnome.org/iogrind looks shiny [03:33] is it a blocktrace wrapper? === orospakr_ [n=orospakr@CPE001c1019cfc4-CM0011ae034e04.cpe.net.cable.rogers.com] has joined #bzr [03:46] lifeless: the page says [03:46] iogrind works in 3 parts: [03:46] * tracing the application using valgrind [03:46] * snapshotting the filesystem [03:46] * simulating the trace, against a snapshot to visualise. [03:47] hmm [03:47] should use blktrace ;) [03:47] no need for snapshot [04:00] jelmer: yo === BasicOSX [n=BasicOSX@216-250-174-201.static.iphouse.net] has joined #bzr [04:05] New bug: #147927 in bzr "use python -O (assertions off) when running installed copy" [Undecided,New] https://launchpad.net/bugs/147927 [04:22] poolie: another patch sent in === Verterok [n=ggonzale@75-108-235-201.fibertel.com.ar] has joined #bzr [04:40] lifeless: hi [04:41] your commit mails still say file:/// [04:41] you need a public_url entry in your config [04:41] whoops [04:46] moin [04:52] I don't known if this is a bug or a problem of my installation, but I'm getting a exit value =1 when I run 'bzr diff' === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr [04:53] I found this yesterday, while running the test cases of BazaarClient (the java library, part of bzr-eclipse) my test case for diff is broken and is because 'bzr diff' return a exit value = 1, but the output I get is ok [04:56] Verterok: its a feature [04:56] 1 - changed [04:56] 2 - unrepresentable changes [04:56] 3 - error [04:56] 0 - no change [04:57] lifeless: thanks, now you tell me, It's a nice feature :D [04:58] could you file a bug though, bzr help diff should list this [04:58] ok, I'll do that === Admiral_Chicago [n=FreddyM@ubuntu/member/admiral-chicago] has joined #bzr [05:10] New bug: #147938 in bzr "bzr help diff should list the meaning of exit values" [Undecided,New] https://launchpad.net/bugs/147938 === bigdog [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr === Admiral_Chicago_ [n=FreddyM@st074039212101.monm.edu] has joined #bzr === Admiral_Chicago_ is now known as Admiral_Chicago === Admiral_Chicago [n=FreddyM@ubuntu/member/admiral-chicago] has joined #bzr [05:43] lifeless, are you sure bug 147916 is real? [05:43] Launchpad bug 147916 in bzr "support for checkout of readonly url has regressed" [High,Incomplete] https://launchpad.net/bugs/147916 [05:44] yes [05:44] but I may be wrong [05:44] or misjudging some root cause [05:44] spiv: damn this patch is long [05:45] spiv, can you explain why you want bug 106898? [05:45] Launchpad bug 106898 in bzr "put_bytes should raise a specific exception when given unicode" [Undecided,New] https://launchpad.net/bugs/106898 === jml [n=jml@ppp108-61.static.internode.on.net] has joined #bzr === BasicOSX [n=BasicOSX@216.243.156.81] has joined #bzr [06:18] spiv: review sent [06:20] lifeless, i can't reproduce any failure with readonly branches, nor find a likely report in mail [06:20] there may well be one that i can't find [06:20] but for now, i'm going to just work on the other bit - better message when trying to commit to a readonly branch [06:22] ok [06:22] i think it may be enough to (add a test and) just make that error a user error [06:22] and check the message is reasonable [06:31] bbiab, fooding [06:41] is it just me or is BB timing out a lot? [06:56] just you ? [07:00] as in, it works for me === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr === jamesh_ is now known as jamesh === Admiral_Chicago [n=FreddyM@st074039212101.monm.edu] has joined #bzr [07:56] spiv: ping [07:57] lifeless: pong [07:57] you promised me a review :) [07:58] lifeless: thinking of which, lp reviewers meeting in a couple of minutes... [07:59] oh crud [07:59] my stomach has just decided to throw spasms at me [07:59] It dislikes the launchpad review team that much? ;) [08:00] unrelated I think, but I'm going to do a runner === lifeless toilets [08:34] tmi [08:36] poolie: I think 106898 was motivated by wanting to know what to catch in test_put_bytes_unicode. UnicodeEncodeError is raised by some transports, but that seems strange (we don't want to try encode unicode in that method, so why should it raise that?). Some others raise AssertionError, which always feels a bit funny to catch to me but I guess can be ok. [08:38] i guess the heart of it is === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr [08:38] i'm not sure how much we should have apis promise they will reject invalid input [08:38] In that they should reject it, but not promise specifically how? [08:39] i.e. we should test simply for Exception in test_put_bytes_unicode and stop worrying about the details? [08:40] poolie: I think its reasonable to promise when its a cheap promise; and/or the api is at the edge of a subsystem [08:40] that seems like a good guideline [08:40] spiv, well, why are you writing this test? [08:41] I don't really remember why I wrote it. (Or if I wrote it or just touched it?) [08:41] But it seems good to ensure that put_bytes will not silently accept unicode strings as if they are bytes. [08:42] Otherwise with sys.getdefaultencoding() == 'ascii', which it is by default, it's easy for it to appear to work reliably when testing, and then fail on real data that isn't 7-bit ascii. [08:43] yes, that's true [08:43] i would probably add TypeError or ValueError or both to the list of exceptions it can raise [08:43] i don't think we need to test that it raises one particular exception [08:44] i think declaring a new class would almost certainly be excessive [08:44] I agree that a new class would be excessive. [08:45] TypeError seems reasonable to me. I guess the main thing that bugs me about that test as-is is that UnicodeEncodeError seems like a bogus exception to raise. [08:45] well [08:45] Hmm, and ideally, it should raise when fed u'foo', not just u'\u1234', according to my argument above :) [08:45] TypeError requires LBYL [08:46] (But the test currently only tests with u'\u1234') === metze_asleep is now known as metze [08:51] spiv, i agree that it should do this [08:51] check the actual type rather than just whether it's convertible [08:54] well [08:54] the point is that it shouldn't be converted at all [08:56] poolie: 139478 would be the regression [08:58] bug 139478 [08:58] Launchpad bug 139478 in bzr "UnlockableTransport running update in checkout of readonly branch" [Medium,Triaged] https://launchpad.net/bugs/139478 [08:58] now that bug numbers are 6 digits maybe ubotu and the markup code should just always recognize them. [08:59] i'm working on those two now [08:59] spiv: so, is that review pending? or no-comment ? [09:00] lifeless: pending [09:00] k === Lo-lan-do [n=roland@mirexpress.internal.placard.fr.eu.org] has joined #bzr === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr === pbor [n=urk@host42-87-dynamic.1-79-r.retail.telecomitalia.it] has joined #bzr === pbor [n=urk@host42-87-dynamic.1-79-r.retail.telecomitalia.it] has joined #bzr === g0ph3r [n=g0ph3r@p57A09B8E.dip0.t-ipconnect.de] has joined #bzr [09:35] New bug: #147986 in bzr "branch in test root directory can cause confusing results" [Medium,Confirmed] https://launchpad.net/bugs/147986 === BasicOSX [n=BasicOSX@216.243.156.81] has joined #bzr === allenap [n=allenap@87-194-166-60.bethere.co.uk] has joined #bzr === BasicMac [n=BasicOSX@warden.real-time.com] has joined #bzr === Zindar [n=erik@stockholm.ardendo.se] has joined #bzr === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr [09:57] mrevell, hi [09:57] hi poolie [10:00] Over the 30 - 45 minutes, we're going to be discussing Bazaar documentation. [10:00] Welcome to the meeting and thanks for coming :) [10:01] The aim of this meeting is to identify gaps in the current Bazaar docs. [10:01] Yesterday we had a similar meeting and the main issues raised were: [10:01] * We need examples for as many use cases as possible for each command in bzr help/user reference. [10:01] * We need good coverage of what sort of conflicts can happen, how you can provoke them, and how to clean them up. [10:01] * We should make the split between user reference and user manual clearer. [10:02] So, I'd be keen to hear what you guys feel we're currently missing. I'd like to cover: [10:02] * The user reference: do we have an entry for each command, should we cover more advanced topics in the user reference? [10:02] that's a good list [10:03] Two meetings a day? WHat kind of bureaucratic monster has #bzr become? [10:03] Lo-lan-do: The other was yesterday my time :) [10:03] He's just trying to have one without me around. [10:03] mrevell: Mine too, but one every twelve hours still qualifies as two daily here :-) [10:03] * The user manual: should this become a straight tutorial, with the reference materials moving into the user reference? [10:04] Lo-lan-do: Fair point :) [10:04] Lo-lan-do, they won't repeat daily [10:04] btw, [10:05] So, starting with the user reference: have you noticed any obvious gaps in bzr help? [10:05] packs are now annotation-free; this means their initial commit for any experimentation will be 30 seconds faster than they were yesterday. [10:05] and I'm going to eat, sorry mrevell I will read and comment on minutes though, if there are any [10:05] lifeless: thanks [10:06] mrevell, i think there are some gaps, [10:06] lifeless: I'll post minutes to the bazaar list later today === lifeless waves [10:06] ciao [10:06] there's a gap that the commands are not always explained from the right perspective of the person first reading about the command [10:06] poolie: Ah, interesting. [10:06] a good example might be, um [10:07] well, an ok example is 'bzr help send' [10:07] it seems a bit like it just jumps into the details [10:08] poolie: Yeah, I can see that. [10:08] i think the other thing that may be happening with the manual vs reference [10:08] is that the reference is taken from the materials in the help text [10:09] if we stick with this distinction, the online help will be all reference-type material, not introductory [10:09] and i'm not sure that's quite right [10:09] maybe it's ok, as long as they have a brief introduction to whatever topic they're talking about === mvo [n=egon@p54A66FA4.dip.t-dialin.net] has joined #bzr [10:11] Right, yeah, I agree the online help should continue to have an introduction to each topic and should ease the reader into it [10:11] mrevell, did people say more yesterday about what that split should be? [10:11] poolie: Just a moment, I'll put out a quote. [10:12] fullermd suggested dividing the documentation along these lines, which I broadly agree with: [10:13] fullermd One is the "quick start". That's the "bzr in 5 minutes", the "here-kid-the-first-one-is-free" stuff. [10:13] fullermd The second is the more miniseries-style tutorial stuff, which are individual pieces, but follow a reasonable progression without too much overlap. Taht would be the "Learning bzr" sort of doc. [10:13] fullermd And the third would be the reference. In-depth discussion of commands and use-cases, lists of config options and revspecs, et === mwh [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr [10:14] Although I take the point that the reference must include introductory material for the online help. [10:15] You can model those three as "get the flavor of bzr/get a recipe for a quick project contribution", "learn bzr", and "reference bzr". === boggle [n=spindler@modemcable212.211-70-69.mc.videotron.ca] has joined #bzr [10:17] that sounds pretty good === n2diy [n=darryl@wlk-barre-208-103-148-32.dynamic-dialup.coretel.net] has joined #bzr [10:18] So, for the user reference we have the suggestion that not all entries are correctly targeted at someone who needs an introduction to a command. Thanks for that poolie. [10:18] Thanks fullermd also [10:18] i think the only thing to do is to go through them one by one with new-user glasses on [10:19] poolie: I have those glasses :) [10:19] i think the main thing is that the first bit of the description should be a 1-5 sentence summary of what the command is for [10:19] the purpose === pbor would like a tips-and-tricks page/FAQ with quick oneliners for common stuff [10:19] thanks pbor [10:20] I just expressed the desire to have it not to write it, so nothing to thank me about :) [10:20] poolie: Some of our descriptions are quite a bit longer than 1 - 5 sentences right now. One thing that came up yesterday was that it's sometimes difficult to be concise [10:20] pbor: Thanks for the suggestion :) [10:21] poolie: Although obviously we can make the writing as tight as possible [10:21] pbor, yes, i think a faq would be a good idea - [10:21] particularly a single clearly-identified faq [10:21] i've been wondering if we should use answers.launchpad.net for that [10:21] (which i posted about recently) [10:22] it has some advantages, like trying to guide people who have new questions to the existing answers [10:22] poolie: So, I like the idea of ensuring the most important info is in the first 1 - 5 sentences [10:22] and linking to bugs if the answer relates to a bug, though at the moment only weakly so [10:22] ok [10:22] i agree that sometimes it is hard to fit it in that limit [10:23] this is partly a problem of knowing just how much you ought to explain [10:23] obviously we don't want every command's help going from first principles [10:25] poolie: I'll tkae an action item of looking at a good way of using the Answers FAQ system for bzr [10:26] I'd like to move onto the user manual, unless anyone has more to say about the user reference. [10:26] sure [10:28] so for the manual [10:28] I think the user guide's weakest point, at the moment, is in advanced topics. [10:28] Perhaps some material could move out of the current tutorial [10:29] into advanced topics === fullermd somewhat disagrees. [10:29] fullermd: Please go ahead [10:30] Well, it could just be a taxonomy issue, in what we want to have where. [10:30] in fullermd's description it looks like there's just one pretty short tutorial, and then the user's guide, and not a long tutorial [10:30] But I think of a user guide/manual to be the thing you sit down and read through to understand the program and what you'll do with it. [10:30] The current User Guide is just a collection of rather independent articles. It's random-access. [10:31] (that may be a more meta position than we want to go into, though) [10:31] fullermd: I agree that we need to make the user guide more cohesive, and that each section should progress naturally one to the next. [10:32] We don't currently really have a place where we can say to new users "Go here, and read from here to there, and you'll have a good understanding of bzr"; that's what I'd want a User Guide to be. [10:33] (in fairness, that doesn't seem to be what the current UG is _trying_ to do, so...) [10:34] i agree about cohesion and flow too [10:34] i think that's because it's acreted rather than because it's particularly what people want [10:34] Yah. It's more a "Hey, we have these docs; we better link to them all". [10:34] so what, if anything, would be the difference between such a guide, and an extended tutorial? [10:34] fullermd: Right. So, as a relatively inexperienced Bazaar user I'm in a good position to see how we should shape that sort of guide. I think your three split model is a great suggestion but I'm concerned that, because the user ref is also bzr help, we shouldn't overload that. Perhaps we need a rewritten tutorial and then further articles that cover "further reading" type topics [10:35] it seems like they might cover the same concepts and commands [10:35] but a tutorial has more of a continuing worked example [10:35] None, really; that's sort of where I want it to be. Go in one end of it new, come out the other end with a working bzr gestalt. [10:35] mrevell, what kind of thing are you thinking of as 'further reading'? [10:36] When I read "tutorial", I tend to read it more as "recipe"; it tells you the steps, and maybe a little about why you take them, but it doesn't leave you with the gestalt. [10:36] poolie: For example: hosting a team branch in Launchpad, or running a bzr smart server. [10:36] Well, that comes back to my opinion about the place of 'bzr help'. But I think I'm minority there. [10:37] poolie: Topics that aren't essential to everyday use of bzr [10:37] I think the User Guide should very much reference the User Reference for more in-depth coverage. [10:37] poolie: and perhaps that won't be applicable to everyone. [10:37] e.g., the USer Guide should talk about the smart server and why you might use it, but setting it up should be the Reference's province. [10:38] actually i disagree about that particular case [10:38] fullermd: I think my concern there is that it's not necessarily a clean break between the two. [10:39] poolie: Ah, okay. Well, perhaps using some of the community's tools such as bzr-svn. [10:40] ok, so the guide should give you a map to most of the content in the reference? [10:41] I picture the guide as giving you a solid working understanding. Read it, then you can comfortably use bzr for your projects. [10:42] Reference would be more details of each command and its options (--reprocess was an example I used yesterday) and more involved cases where you'd use them, detail coverage of a spectrum of workflows, etc. [10:43] fullermd: Do you think all of that should be in the online help? [10:44] my default position for the online help [10:44] I don't, no. I want quick-ref. "I know the concepts, remind me where this command fits and what options it has". Describing just what the options do and what their side-effects are can be a multi-paragraph endeavor. [10:44] (i'm willing to change) [10:44] is that, well, what fullermd just said, pretty much [10:44] a typical user, if they only had the help and not the guide, could work things out but they'll need to piece it together by themselves [10:45] right [10:45] ok [10:45] so on the guide in particular [10:45] i think we want to get rid of the section called 'tutorial' [10:46] poolie: Yeah, and make the guide itself work as a tutorial [10:47] poolie: in that progresses the user through each topic [10:47] coherently [10:48] maybe a good place to start would be to just change it's index.txt to incorporate an outline of what should be there [10:48] I'm hoping in the next week or two work will calm down enough that I can sketch out an outline for my ideal UG. Hardly had time to breathe lately :( [10:50] poolie: Okay, I'll change the index.txt to create an outline of where I think we should go and then we can get a discussion going on the list. [10:50] at the moment 'configuration' is one of the first topics [10:50] did you get enough feedback on the 5 minutes doc? [10:50] i glanced at it and it looked godo [10:50] good [10:51] poolie: Yeah, I got some great feedback, thanks. In particular, I've got some good feedback on how to pitch it. I was worried that I'd used the slightly wrong tone and that was confirmed [10:52] Someone said one part was a little too "cutesy", which I think was a fair comment. [10:52] Right, well, thanks for your time guys. Over these two meetings I've had some very useful input. I'll write up the minutes of these two meetings and post them to the bazaar list today. === boggle is now known as TeTeT [10:53] Unless anyone has anything further they'd like to add, I'll close the meeting and continue discussion on the list. [10:55] just one more thing [10:55] yeah? [10:55] one more open issue is this: there are several ways [10:55] you can set up to use Bazaar [10:56] so at the moment we have centralized_workflow; we could also talk about team branches, or using pqm, or other thnigs [10:56] similarly, shared repositories vs standalone branches vs checkouts [10:56] there's potential for confusion [10:57] i guess [10:57] Well, for the latter, I think a good Fundamentals piece will cover that well (as I blathered about at excruciating length on the list) === jml [n=jml@CPE-124-177-6-69.vic.bigpond.net.au] has joined #bzr [10:57] we should be clear about what the mainstream method is [10:57] right [10:57] but present the alternatives and why you might want to use them [10:57] For the former, I think that needs a chapter in the Manual, and emphasizing that it's a continuum rather than a set of points. [10:57] the former? [10:58] The workflows [10:58] At one end is a single shared branch everybody works on, at the other is individual branches full-mesh merging, and everything else is in between. [10:59] ok [10:59] I have an idea of tackling that by starting with the single-branch case, and walking up through more and more distributed bits until it finally becomes full-mesh. [10:59] and then maybe the reference should describe the constituent parts [11:00] But you could also go the other way. Or describe the ends, then walk inward from both. I haven't decided which I like better [11:00] I think what's needed is to cover the continuum, then pick a small handful (3, 4 maybe) points along it and describe how you'd use them specifically, and what use-cases they might well fill. [11:01] I have to admit that this is an area where my lack of experience with bzr lets me down. I understand that there are different workflows but I'm sketchy on when is best to use which workflow. [11:02] Not sure how to split that between Guide and Reference, though. The whole would be too big and deep for Guide. [11:06] (obviously, I'm a big "understand the concepts, then the 'real' instances are Obvious(tm)" guy. That may be a blind spot.) [11:08] tutorials as such do tend to start out with specific examples [11:08] anyhow, that gives us something good to go on with [11:08] thanks, mrevell [11:09] i'm done if you are [11:09] fullermd: I worry that starting with the concepts could overwhelm people. [11:09] but obviously there's basic ground that needs to be covered to understand what follows [11:09] yes, thanks poolie [11:09] poolie: I have some great action points and input from these two meetings [11:09] Yeah. It's a problem :( [11:10] I'll write the meetings up for the list and come up with a first draft contents for the tutorial. [11:10] I think I'll be relying heavily on community input for the more advanced topics. [11:10] Thanks everyone. === dous [n=dous@124.104.0.255] has joined #bzr [11:24] poolie: ping [11:24] poolie: err, a bite late maybe :-/ === gabe [n=gabriel@91.84.56.254] has joined #bzr [11:34] Is it a bug that heavy checkouts don't inherit the branch nick from their branch? === fullermd thinks it is... === dous_ [n=dous@124.104.10.249] has joined #bzr === Enquest [n=Enquest@d54C28B91.access.telenet.be] has joined #bzr [11:49] How can I make sure that "bzr add" ignores a few directories [11:55] Enquest, add them to .bzrignore [11:56] poolie, could you point me to the docs for this [11:56] Where is .bzrignore located? [11:56] on my home tree on the server tree? [11:56] Enquest, just in the root of your source tree [11:57] there is no file there .bzrignore? [11:57] I have to create it [11:57] ? [11:57] http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/tutorial.html [11:57] search for 'ignor' [11:57] you can either create it, or use the 'bzr ignore' command [11:57] to create it and add patterns to it === jml_ [n=jml@CPE-124-187-233-64.vic.bigpond.net.au] has joined #bzr [12:16] New bug: #148030 in bzr "Heavy checkouts don't inherit nick" [Undecided,New] https://launchpad.net/bugs/148030 === TeTeT [n=spindler@modemcable212.211-70-69.mc.videotron.ca] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === Mez [n=mez@ubuntu/member/mez] has joined #bzr [12:39] speaking of docs, am I the only one to think that in the quick start guide branching a remote branch should come first than creating your own repo? [12:39] I don't think that way, no... [12:39] (at least, necessarily) [12:39] maybe it is just me, but I think it is way more common to start using a vcs when joining a project that already uses it than starting a new project [12:40] usually it goes: "I want to fix this with a patch, how do I get the code" [12:41] when I start a new project and I pick a vcs chances are that I am already familiar with the vcs I pick [12:44] Well, but the steps of using it are pretty much the same, and it's simpler to start describing in isolation (IMO) [12:45] Enquest: bzrignore is in your home dir [12:47] fullermd: dunno, I know that each time I read cvs/svn/bzr doc when I started using them it got on my nerves... every time I thought "I do not want to create no f. repo, I don't even know what a repo is! Just tell me the command to get the code" [12:48] Well. That gets into why I *HATE* quick-start docs. === sii [n=sii@tranquillity.sii.se] has joined #bzr [12:50] fullermd: if I read I quick start doc I just want to get the job done, I am not interested in the theory, so I prefer to order things by how often they are needed... a full reference is a different matter, there I agree that things should go in logical order === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr === jml__ [n=jml@CPE-124-177-1-217.vic.bigpond.net.au] has joined #bzr === herzel104 [i=herzel@gateway/tor/x-621bbda4688b0d44] has joined #bzr === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr === mrevell is now known as mrevell-lunch [01:31] hey revisionistas [01:35] sabdfl: hi === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === niemeyer [n=niemeyer@200-140-230-150.ctame705.dsl.brasiltelecom.net.br] has joined #bzr === allenap [n=allenap@87-194-166-60.bethere.co.uk] has joined #bzr [02:39] vila: what's news in bzr-land? [02:39] is there a bundle-buddy page where I can see what's in the queue for review and landing? [02:40] sabdfl: see http://bundlebuggy.aaronbentley.com/ [02:40] Well, I don't follow as closely as I wish, but lifeless is working on big improvements with pack formats [02:40] http://bundlebuggy.aaronbentley.com/ will show you all pending patches === mrevell-lunch is now known as mrevell [02:41] bulk of lifeless work does not appear there of course only bits he can merge now to bzr.dev [02:42] also, spiv is working on some smart server improvements also not shown on BB [02:42] but both their works are supposed to land for 0.92, so soon [02:43] thanks vila, that's a nice list [02:44] sabdfl: you're welcome, but take it with a grain of salt, that's mostly my personal view, I may miss some parts [02:45] sabdfl: and finally, mrevell is working on the doc, but you should know that ;) [02:46] And I'm just sitting around stirring up trouble, as usual. [02:47] and giving good hints for docs ;) [02:47] Well, yeah, in the sense that "someone else should write them the way I think they should be" ;p [02:48] heh [02:48] every good project has a good curmudgeon [02:49] vila: the packs patch is pretty small now, the review I got today gets rid of the largest non-format delta [02:50] anyhow, its *sleep* time, just dropping by for a last minute irc fix ;) [02:50] lifeless: glad to know :) Will tell it to sabdfl :) [02:50] lifeless: have a good night [02:51] only remaining must-do-before-merge of everything is the index layer; need to give keir's proposed format a fine toothed go-over and profile, or make the toy format do bisection === lifeless waves === luks [n=lukas@unaffiliated/luks] has joined #bzr === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr === nir [n=nir@moinmoin/fan/nir] has joined #bzr === orospakr [n=orospakr@bas4-ottawa23-1167864095.dsl.bell.ca] has joined #bzr [03:06] light lifeless === mw [n=mw@189.146.13.202] has joined #bzr === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === BasicOSX [n=BasicOSX@216.243.156.81] has joined #bzr === g0ph3r [n=g0ph3r@p57A0B930.dip0.t-ipconnect.de] has joined #bzr === bigdog [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr === orutherfurd [n=orutherf@dsl092-164-022.wdc2.dsl.speakeasy.net] has joined #bzr === mw [n=mw@189.146.13.202] has joined #bzr === orospakr [n=orospakr@132.213.238.4] has joined #bzr === Lllama [n=Lllama@217.154.92.11] has joined #bzr [04:54] Afternoon all. Anyone managed to get Trac working with bzr? I'm getting errors about it not being a Svn repository. [04:58] hi, anyone have any tips for sharing a branch using ssh? I think I'm running into bug 50568 [04:58] Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed] https://launchpad.net/bugs/50568 === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr [05:04] Well, my solution doesn't really help you :) [05:04] Lllama: did you include "tracbzr.* = enabled" in your components ? [05:08] Sigma: Yep. I've got [components] tracbzr.* = enabled at the bottom of the ini file. === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has left #bzr [] [05:10] Various bzr related messages show up on the source browser of the subversion repositories, so I'm guessing that the plugin is working. === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr === p4tux [n=p4tux@189.169.95.23] has joined #bzr [05:16] Lllama: I can pastebin a working config for you if you still need it. [05:16] abadger1999: Worth a look. Cheers. [05:18] Lllama: http://pastebin.ca/723121 [05:37] abadger1999: cheers. You've got a couple of extra lines, so I'll try playing with them. [05:37] Cool. Hope it helps! === cprov is now known as cprov-lunch [05:48] abadger1999, Sigma: thanks for the pointers. Upgrading from 0.9 to 0.10 was the key. [05:49] Great === phanatic [n=phanatic@ubuntu/member/phanatic] has joined #bzr [06:15] orutherfurd: you can correct that via chmod/chown. [06:16] Only temporarily. Later pushes can still screw it up when they create new dirs. [06:20] stupid question, I'm sure, but is there any way for paramiko to explicitly create directories w/same owner and permissions as parent directories? or to change them after the fact? [06:20] No, the problem is the setgid. The sftp server strips it. [06:20] So paramiko can _say_ to set it, but it won't get set. [06:21] ah, that's unfortunate ;-) [06:21] bzr+ssh is probably a workaround. And the better choice anyway, if you can run with it. === kiko-zzz is now known as kiko [06:21] My workaround is to not use a system with SysV filesystem semantics ;) [06:22] yeah, I saw that as a suggestion, but one of the big draws for using bzr was not having to install any software on the server [06:22] easier to fly below the radar [06:22] I don't think bzr+ssh requires installing bzr? [06:23] or am I getting them mixed up? [06:23] oh, maybe I was misunderstanding -- I thought that was the 'smart server' [06:23] Yes, it does. Otherwise you'll have a lot of trouble with the 'bzr' part of it. [06:24] Ooh. it's bzr tunneled over ssh. Duh. === NfNitLoop reads scrollback before commenting further. === BasicOSX [n=BasicOSX@216-250-187-201.static.iphouse.net] has joined #bzr === LeoNerd [n=leo@cel.leonerd.org.uk] has joined #bzr === cprov-lunch is now known as cprov === NamNguyen [n=namnt@cm38.delta196.maxonline.com.sg] has joined #bzr === Lllama [n=Lllama@217.154.92.11] has left #bzr [] === mrevell is now known as mrevell-dinner === Alien_Freak [n=sfaci2@castor.tavros.net] has joined #bzr === mikl [n=mikl@pdpc/supporter/active/mikl] has joined #bzr === marianom [n=marianom@ubuntu/member/marianom] has joined #bzr === Gwaihir [n=Gwaihir@ubuntu/member/gwaihir] has joined #bzr === joejaxx [i=joejaxx@fluxbuntu/founder/joejaxx] has joined #bzr === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr [07:38] phanatic: ping === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr [07:38] jelmer: pong, i saw you've subscribed a bundlebuggy :) === Vernius_ [n=tomger@p508AC107.dip.t-dialin.net] has joined #bzr [07:41] jelmer: got your mail as well. it's awesome, thanks for your work! [07:46] Oog. I hate it when a annoying-but-harmless bug turns into an annoying-but-harmful one :( [07:47] abentley: ping? [07:48] phanatic: we don't seem to be able to vote yet :-/ === Admiral_Chicago [n=FreddyM@ubuntu/member/admiral-chicago] has joined #bzr === nir [n=nir@moinmoin/fan/nir] has joined #bzr === Zindar_ [n=erik@stockholm.ardendo.se] has joined #bzr [07:50] jelmer: yeah, just noticed... === asak [n=alexis@201-1-201-182.dsl.telesp.net.br] has joined #bzr [07:54] Can somebody more official take a look at bug 114615, particularly in light of the comment I just posted on it? [07:54] Launchpad bug 114615 in bzr "AssertionError trying to commit with 0.16.0" [High,Confirmed] https://launchpad.net/bugs/114615 [07:55] I feel the desire to bump Importance to Critical for that, but that's above my paygrade. === dpm [n=dpm@p54A116C6.dip0.t-ipconnect.de] has joined #bzr === jrydberg_ [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr [08:02] fullermd: please update that bug to reflect that it affects bzr.dev and 0.91 [08:03] Hm. I mentioned it in the comment. Is there an Affects field I don't see? [08:06] There should be a "Edit Description/Summary" link or something on the left [08:07] Ooh, the title? Gotcha. [08:10] Damn thing bit me on a real project earlier today. That was fun to try and reproduce... === phanatic_ [n=phanatic@dsl54028251.pool.t-online.hu] has joined #bzr === kiko is now known as kiko-phone [08:35] ouch === bratsche [n=cody@adsl-68-94-36-166.dsl.rcsntx.swbell.net] has joined #bzr === phanatic_ is now known as phanatic [08:51] if I do mv a b in one branch and edit a in another I get a conflict upon merging the move to the edit. That seems wrong to me. [08:51] also there is no way to resolve it so that the move gets recorded. === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr [08:53] I've not seen that. A quick test doesn't show it here either. [08:57] ah, it works this time, I don't know what I was doing there. [08:58] I blame violent video games, personally. === kiko-phone is now known as kiko === luks [n=lukas@unaffiliated/luks] has joined #bzr === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr === BasicOSX [n=BasicOSX@216-250-187-201.static.iphouse.net] has joined #bzr === cprov is now known as cprov-afk === fog [n=fog@debian/developer/fog] has joined #bzr === Mez_ [n=Mez@ubuntu/member/mez] has joined #bzr === Mez_ is now known as Mez === Mez_ [n=mez@ubuntu/member/mez] has joined #bzr === mvo [n=egon@p54A66FA4.dip.t-dialin.net] has joined #bzr === AnMaster_ [n=AnMaster@unaffiliated/anmaster] has joined #bzr === AnMaster_ is now known as AnMaster === Zindar [n=erik@h188n1fls12o803.telia.com] has joined #bzr [10:14] fullermd: nice bug. [10:19] Hrmph. *I* didn't think it was so nice ;p [10:20] 2 revs down the line... "WTF? Why is this totally vital file that's existed in the project for months 'unknown'??" [10:21] :( [10:22] It gave me just enough time to get over "Hmph. That wacky assertion failure that works the second time isn't fixed yet?" [10:26] The test case might be trimmable a bit farther. I think you need the re-rm'd directory to trigger the assert (and so you need a change in that file deleted), and I presume it's the "other file from the same dir mv'd into another dir" bit that triggers the "rm'd/unknown" bit. [10:26] So maybe some of the other files aren't necessary. But I don't have time today to try and work up truly minimal cases :| [10:28] I don't think the second directory is needed. [10:29] I have just sent an analysis to the report though, so the test case can be trimmed using that. === Gwaihir [n=Gwaihir@ubuntu/member/gwaihir] has joined #bzr [10:30] Probably not. It's part of an earlier attempt I made at trying to figure out what of my real project brought it about. [10:31] it was good enough to pinpoint the problem though, so thanks. [10:34] indeed the second dir is not needed. [10:35] Maybe the bug is really "What the hell are you doing to your poor branches?!" [10:36] changing, renaming and deleting your files all at once? You expect me to merge that? [10:37] "Rise up against your oppressors! Power to the branches!" === ppc [n=ppc@abfv59.neoplus.adsl.tpnet.pl] has joined #bzr === ppc [n=ppc@abfv59.neoplus.adsl.tpnet.pl] has left #bzr [] [10:48] james_w: thanks === phanatic_ [n=phanatic@dsl5402836B.pool.t-online.hu] has joined #bzr [11:02] lifeless: no problem. [11:02]