[12:07] Hi guys, just testing bzr atm. I did a nested branch and 'bzr status' returns it as unknown. Is the normal practice to add these nested branches to the ignore list? === BasicOSX [n=BasicOSX@216.243.156.81] has joined #bzr === jrydberg [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr === jaguarondi_ [n=david@216.252-64-87.adsl-dyn.isp.belgacom.be] has left #bzr [] === BasicMac [n=BasicOSX@warden.real-time.com] has joined #bzr === Verterok [n=ggonzale@75-108-235-201.fibertel.com.ar] has joined #bzr [12:28] moin [12:30] MediaWiki? === jrydberg [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr [12:41] is there an environment variable to set to specify a different bzr lib directory? === bialix [n=chatzill@77.109.20.25] has joined #bzr === elijah [n=whatever@c-69-252-219-78.hsd1.nm.comcast.net] has joined #bzr === arjenAU [n=arjen@ppp215-29.static.internode.on.net] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === schierbeck [n=daniel@dasch.egmont-kol.dk] has joined #bzr === schierbeck [n=daniel@dasch.egmont-kol.dk] has left #bzr [] === _thumper_ [n=tim@canonical/launchpad/thumper] has joined #bzr === herzel104 [i=herzel@gateway/tor/x-724e02254a2eb317] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr === herzel104 [i=herzel@gateway/tor/x-5da007e002bf3a05] has joined #bzr === _thumper_ is now known as thumper === jml_ [n=jml@ppp108-61.static.internode.on.net] has joined #bzr === joejaxx [i=joejaxx@fluxbuntu/founder/joejaxx] has joined #bzr === jml__ [n=jml@203-113-250-169-static.TAS.netspace.net.au] has joined #bzr === jml__ is now known as jml === Admiral_Chicago [n=FreddyM@ubuntu/member/admiral-chicago] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === abentley [n=abentley@64.229.18.231] has joined #bzr === statik [n=emurphy@189.66.188.72.cfl.res.rr.com] has joined #bzr === orospakr [n=orospakr@65.95.1.79] has joined #bzr === jml_ [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr === dous_ [n=dous@124.104.0.255] has joined #bzr === orospakr [n=orospakr@65.95.1.79] has joined #bzr === nir [n=nir@moinmoin/fan/nir] has joined #bzr === Verterok [n=ggonzale@75-108-235-201.fibertel.com.ar] has joined #bzr === orospakr [n=orospakr@bas4-ottawa23-1096745295.dsl.bell.ca] has joined #bzr === AnMaster [n=AnMaster@unaffiliated/anmaster] has joined #bzr === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr === pbor [n=urk@host216-21-dynamic.60-82-r.retail.telecomitalia.it] has joined #bzr === jml_ is now known as jml === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr === matkor [n=matkor@EUROCZESCI.wbs.ssh.gliwice.pl] has joined #bzr [08:49] Hi ! What is idea beging merging files using olive-gtk and meld ? I get three views BASE OTHER THIS, where should I store final (merged) version ? === g0ph3r [n=g0ph3r@p57A09DEB.dip0.t-ipconnect.de] has joined #bzr === pitti [n=pitti@ubuntu/member/pitti] has joined #bzr [09:02] hello [09:02] whoa, the first time in years that bzr really failed for me... === Lo-lan-do [n=roland@mirenboite.placard.fr.eu.org] has joined #bzr [09:03] I checked out a Debian SVN with "bzr get svn+ssh://...", and now try to merge this into a native bzr branch; when doing that, I get [09:03] bzr: ERROR: Repository KnitRepository('file:///home/martin/ubuntu/hal/hal/.bzr/') is not compatible with repository KnitRepository3('file:///home/martin/ubuntu/hal/hal-debian/.bzr/') [09:04] any idea about that/ bzr upgrade'ing the debian svn checkout doesn't work either ("Cannot convert to format . Does not support rich root data.") [09:05] You need to convert your branch to dirstate-with-subtrees or something [09:07] hm, 'dirstate-with-subtrees' does not exist, it is already 'dirstate', and it refuses to convert to 'knit' [09:11] dirstate-with-subtree, sorry [09:11] try dirstate-with-subtree [09:11] :) [09:11] Are you planning to drop pycurl? One comment in a bug mentions it. [09:12] I'm still confused as to why that format, which was supposed to become the default format around 0.15 or so, isn't even mentioned in "bzr help formats" [09:14] Because it's its purpose is to enable a feature there's not much of a UI for. I don't think it's slated to become a default any time soon. [09:15] At one point, there was a discussion about changing it from a parallel format to a flag, I think. But that was a long time back. [09:15] New bug: #147530 in bzr "pycurl http implementation peeks under the covers" [Low,Confirmed] https://launchpad.net/bugs/147530 [09:16] I see. But I guess bzr-svn could be a bit more explicit in its error messages then. [09:16] Well, I don't think the error message is coming from bzr-svn. [09:17] I don't know where it comes from, but I do know it's confusing :-) [09:17] meh, now bzr merge excepts out on me; I guess I'll revert the conversion and use classical patch for now [09:17] It's just a 'normal' bzr, "Hey-your-formats-are-incompatible-I'm-dying-here!" cry. === mvo [n=egon@p54A675D8.dip.t-dialin.net] has joined #bzr === fog [n=fog@debian/developer/fog] has joined #bzr === jaguarondi_ [n=david@193.190.210.10] has joined #bzr === allenap [n=allenap@87-194-166-60.bethere.co.uk] has joined #bzr === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr === jaguarondi_ [n=david@193.190.210.10] has left #bzr [] [10:33] Peng: see bug #82086 about dropping pycurl [10:33] Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed] https://launchpad.net/bugs/82086 [10:34] fixing bug #147530 will at least gives a better error [10:34] Launchpad bug 147530 in bzr "pycurl http implementation peeks under the covers" [Low,Confirmed] https://launchpad.net/bugs/147530 === pitti [n=pitti@ubuntu/member/pitti] has left #bzr ["Bye"] === luks [n=lukas@unaffiliated/luks] has joined #bzr === jml_ [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr === GaryvdM [n=chatzill@mtngprs4.mtn.co.za] has joined #bzr === gabe [n=gabriel@91.84.56.254] has joined #bzr [11:10] vila: What about the "stop making pycurl default if it's around" path that's been discussed a time or two? [11:11] fullermd: and stop verifying site certificates by default ? I'm really no comfortable with that... [11:11] Well, we're not verifying the certs by default for all the people who don't have pycurl installed. [11:12] There is still the option to make urllib the default for http and pycurl the default for https, but I'm not really comfortable with that wither [11:13] fullermd: yeah, I know, but windows installs it by default, ubuntu installs it by default, I think debian does that too, so who don't have pycurl really ? [11:13] I don't have it as a dependancy of the BSD port. [11:13] hmm [11:14] It's vaguely irritating to know that I could have a working setup with a self-signed cert or whatever, that nevers gives me any problems, then install some unrelated software that happens to install pycurl and suddenly have my branch blow up. [11:14] Well, I don't think I'm the one to take that decision, I can implement it though, but I'd feel better with an urllib solution [11:15] fullermd: you can't have working setup with a self-signed cert unless bzr pycurl http implementation is patched [11:15] Sure I can. I can not have pycurl installed and be using urllib, without having any idea that it's a problem. [11:15] thinking that an urllib setup works scares me ! [11:16] ("I" being not necessarily me personally. Me personally, I don't think I use http with bzr anywhere except for pulling bzr itself, and plugins) [11:16] Do you know what was my *first* proposed patch for bzr ? === cory_ [i=cory@zeus.penguinhosting.net] has joined #bzr [11:17] Renaming the command 'vila'? [11:18] lol, no. it was enabling self-signed certificates (or more precisely disabling certificate validation for self-signed sites)... 1 year and 1/2 ago I'd say :-) [11:19] Now, call me stubborn, but all my http-related activity is aimed at dropping pycurl support (while providing a better urllib impl. though) [11:19] So dropping pycurl while not providing certificate verification [11:19] ... does not fit the bill :) [11:20] I tried to summarize in bug #82086 [11:20] Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed] https://launchpad.net/bugs/82086 [11:20] Oh, I'm not proposing dropping pycurl; I'm mostly questioning whether it makes sense to use it by default when it appears. [11:23] Well, it's true that the subject has come quite often lately, may be a list discussion is in order then [11:24] so that all personal preferences and implications can be exposed === fullermd nods. [11:25] I don't have a particularly strong opinion, and it certainly doesn't really affect me. It just seems to come up with some regularity. [11:26] My going across the network tends to mostly be bzr+ssh :p === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === GaryvdM [n=chatzill@mtngprs4.mtn.co.za] has joined #bzr === phanatic [n=phanatic@ubuntu/member/phanatic] has joined #bzr === Mez [n=mez@ubuntu/member/mez] has joined #bzr === jaguarondi_ [n=david@193.190.210.10] has joined #bzr === NamNguyen [n=namnt@148.177.217.131] has joined #bzr [11:57] abentley, ping === jaguarondi_ [n=david@193.190.210.10] has left #bzr [] [11:58] Prob. be a while before he's around. === GaryvdM_ [n=chatzill@mtngprs2.mtn.co.za] has joined #bzr [11:58] alrighty ;-) === GaryvdM_ is now known as GaryvdM [11:59] i just hit a problem with bb [11:59] 2nd time === lukas__ [n=lukas@wired-201.fi.muni.cz] has joined #bzr === lukas__ is now known as luks === mvo_ [n=egon@p54A65CD0.dip.t-dialin.net] has joined #bzr === metze_ is now known as metze_asleep === Lo-lan-do [n=roland@mirexpress.internal.placard.fr.eu.org] has joined #bzr === GaryvdM [n=chatzill@mtngprs5.mtn.co.za] has joined #bzr === nir [n=nir@moinmoin/fan/nir] has joined #bzr === Lllama [n=Lllama@217.154.92.11] has joined #bzr [12:49] Morning all. Easy question: I've just resolved some conflicts and 'status' tells me I have pending merges. Do I just need to commit for these to take effect? [12:49] Yes [12:50] Lo-lan-do: cheers. === bac [n=bac@canonical/launchpad/bac] has joined #bzr === jrydberg_ is now known as jrydberg [01:12] Hi - I'm trying to push to a ftp server. I'm getting this error: http://pastebin.com/m57d74483 - and I am not sure what to do. === jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr === Lllama [n=Lllama@217.154.92.11] has left #bzr [] === NamNguyen [n=NamNguye@cm38.delta196.maxonline.com.sg] has joined #bzr [01:59] Easiest way to see changes introduced in given revision or since given revno ? Prefereable like kdiff presents changes ? [01:59] bzr diff -c 1234 === Zindar [n=erik@83.241.192.2] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr [02:12] I'm still having a problem pushing to a ftp server. It creates a file called /bzr-pushtree/trunk/.bzr/branch-lock/kasvrj7jcy.tmp/info.tmp.1191240308.188999900.3268.1560928192 [02:13] Then dose a RNFR /bzr-pushtree/trunk/.bzr/branch-lock/kasvrj7jcy.tmp/info === niemeyer [n=niemeyer@200-140-230-150.ctame705.dsl.brasiltelecom.net.br] has joined #bzr [02:13] That file dose not exist. [02:13] Lo-lan-do: bzr diff ... it is text only ... no graphical tool for that ? [02:14] Oh. Dunno, maybe in olive-gtk. [02:14] There is bzr-gtk - but it will not show you a sisde by side diff [02:15] Try https://launchpad.net/bzr-difftools/trunk === bac [n=bac@canonical/launchpad/bac] has joined #bzr [02:15] err https://launchpad.net/bzr-difftools [02:18] "353 MB .zip file" hmm pain [02:18] oops wrong window, sorry === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr === gander [n=gander@agander.plus.com] has joined #bzr === bac [n=bac@canonical/launchpad/bac] has joined #bzr === gander [n=gander@agander.plus.com] has joined #bzr === schierbeck [n=daniel@dasch.egmont-kol.dk] has joined #bzr === mrevell is now known as mrevell-lunch === ubotu [n=ubotu@ubuntu/bot/ubotu] has joined #bzr === kiko [n=kiko@canonical/launchpad/pdpc.supporter.active.kiko] has joined #bzr === UnUnOctium [i=mb0b0@dsl-146-56-168.telkomadsl.co.za] has joined #bzr === UnUnOctium [i=mb0b0@dsl-146-56-168.telkomadsl.co.za] has left #bzr [] [03:55] Is there easy way to test (using bzrlib) if at given path there is checkout or branch ? [03:55] hi, what can i do about this showing up in bzr st? kind changed: [03:55] emailer/steves_mailer (directory => tree-reference) [03:55] I do bzrlib.workingtree.open_containing(path) , what should be next ? === pete__c [n=pete@032-461-712.area7.spcsdns.net] has joined #bzr === orospakr [n=orospakr@132.213.238.4] has joined #bzr === bigdo2 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr [04:22] Unable to obtain lock sftp://anmaster@hosthere/var/www/envbot.org/htdocs/bzr/.bzr/repository/lock <-- bzr timed out when I pushed, how do I fix this?, deleting the whole repo dir is not an option [04:23] AnMaster: 'bzr break-lock' [04:23] (of course it's an option. It's just a really bad one ;) [04:23] fullermd, yes because uploading about 50 MB on 128 kbps up for just the main branch will be a PAIN [04:24] fullermd, I hope this won't leave it in a broken state or so? [04:24] Well, it's a Big Red Button. If the lock _should_ still exist (like somebody else is writing to it), breaking it could be bad. [04:25] But if it's just a stale lock from a lost connection or something, it'll be fine. [04:25] yep I know what it was [04:26] also how do I with rspush from bzrtools specify the port that ssh is on? it is simple to do with normal sftp push but haven't found a way with rspush [04:26] That, I have no idea on. [04:26] because ssh is on non standard port on this host [04:27] Can't you just use the .ssh/config file in the usual way? [04:27] ah [04:28] LeoNerd, I normally do it like ssh -p port user@host but ok [04:28] Yes; but the config approach has the advantage that all the SSH tools will use it [04:28] And you don't have to think about it [04:28] true === AnMaster goes to read up on syntax of it === Demitar [n=demitar@c-212-031-182-147.cust.broadway.se] has joined #bzr === mrevell-lunch is now known as mrevell === AnMaster swears loudly at trac-bzr === luks [n=lukas@unaffiliated/luks] has joined #bzr === mw|out is now known as mw === bwinton [n=bwinton@mail.phantomfiber.com] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has left #bzr [] === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr === jamesh__ is now known as jamesh === michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr === allenap [n=allenap@87-194-166-60.bethere.co.uk] has joined #bzr === luks [n=lukas@unaffiliated/luks] has joined #bzr === nir [n=nir@moinmoin/fan/nir] has joined #bzr === Lo-lan-do [n=roland@mirexpress.internal.placard.fr.eu.org] has joined #bzr === cprov is now known as cprov-lunch === mvo__ [n=egon@p54A66BD0.dip.t-dialin.net] has joined #bzr === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr [05:52] Hey guys - I'll be holding the first of our two Bazaar Documentation meetings here on the hour. [05:54] What all ground are you intending to cover? [05:56] fullermd: My main aim is to find gaps in the current documentation, so I'm looking for people to suggest areas that they feel are missing from the current docs. [05:57] Ooh, in that case, I'm going to run and quickly get lunch and be back here in 4 minutes. (Hopefully. Feel free to start without me.) === p4tux [n=p4tux@189.169.70.141] has joined #bzr [06:01] Well, my main bug on that is the Fundamentals stuff, which we've covered on the list. That, and the lack of a good reference to the commands. [06:01] I've issues with the tutorials, but I think one of the two biggiest (proliferation of partially-overlapping ones) has been resolved since the last time I sat down with the docs. Been way too busy with work lately :| [06:02] fullermd: Thanks. I'll get the meeting under way. [06:02] Welcome to this Bazaar Documentation meeting! Thanks for coming. [06:02] The purpose of today's meeting is to identify gaps in the current Bazaar documentation. === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr [06:02] My aim is to help the Bazaar team to find and plug those gaps in time for the 1.0 release. [06:03] I've divided the agenda into: === BasicOSX [n=BasicOSX@gatekeeper.real-time.com] has joined #bzr [06:03] * Is the user reference complete? [06:03] * What is missing from the user guide? [06:03] * What do we want to add the "advanced topics" and "best practice" sections? [06:03] So, who's here for the meeting? Say "me", if you're here to chat about the docs. [06:03] me [06:04] me [06:04] Not me, sorry, I'm here to pester jelmer about bzr-svn :-) [06:04] me (somewhat) [06:04] Thanks guys, we can keep things pretty informal :) [06:04] So, my first question: [06:05] Lo-lan-do: I didn't forward your latest bug as you said that jelmer was already aware. [06:05] What do you feel is missing from the user reference? [06:05] james_w: Fine by me [06:06] http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html [06:06] mrevell: ^ that one? [06:06] james_w: That's it, yeah. [06:07] examples [06:07] so that is generated from bzr help. [06:07] james_w: My main concern is that every command should be covered, as it's also the bzr help [06:07] I feel that having the 'reference' generated from the online help is a wrong path; the needs of the two cases are totally different. [06:07] james_w: Right, yeah [06:07] it's a good way of getting something together though. [06:08] Examples are a big thing (and good examples often cross command boundaries). [06:08] I agree that it is not complete, or ideal though. [06:08] Really need to tackle each command and answer, "when would I use this?", "when would I not use this?", "what side effects can this cause?", etc. [06:08] examples are usually what i want in man page type help [06:08] sometimes it's not obvious how to string together the arguments for a command [06:09] yeah, a clear statement for each about whether it modifies the working tree, uses network etc. might be good to have as well. [06:09] Thsoe sort of discussions get long, which isn't really suitable for online help (which should be more "remind me what the args/action is" than "describe in detail what each of these things do") [06:09] usually, some command as only a couple 'common use cases' [06:09] fullermd: indeed. It might be useful to have online though. [06:09] Reasonable example: merge --reprocess. Describing just what that does, and when you would/wouldn't want to use it is a couple paragraphs. Fitting that into an option list summary doesn't work well :) [06:10] Well. I'm iffy on that. If 'bzr help xyz' is more than a screenfull or two... [06:10] with the topics shadowing feature it would be possible to define long help for each command which is shown if you run bzr help topics/command (I think that's the syntax). [06:10] yes, not by default, but available. [06:10] hmmm, short meeting. === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr [06:10] See? The help was too long for him ;) [06:10] Hmm, got disconnected. [06:10] :) [06:10] :) [06:11] Would it be reasonable to include a link to web based help, if a description was too long for bzr help? [06:11] A good coverage of what sort of conflicts can happen, how you can provoke them, and how to clean them up, would be another thing a ref manual should have. [06:12] mrevell: reasonable yes, distros can patch this to point to a local copy as well. [06:12] It would probably have to be a pretty shallow link. "For more, see the Bazaar Reference Manual (online at ....)", rather than a deeper one. That way would lie madness... [06:12] fullermd: there is conflicts documentation, but it needs some work, and I agree it should be in the reference section. [06:13] I agree with fullermd on the link-to-online-docs point. [06:13] fullermd: Why would deeper linking be a problem? Perhaps I'm missing something obvious :) [06:13] Ditto for merging; we have some talk about workflows (we have some on the wiki; should emphasize the full continuum from "single shared branch" to "full mesh"), and the merging strategies that work. === bigdog [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr [06:14] mrevell: are you against having it in bzr then? [06:14] Also, 3-way vs. weave/knit, why you'd use one over the other, and degenerate cases. [06:14] mrevell: a deeper link will prevent us from radically changing the structure of the docs. [06:14] no, you can link to $version. [06:14] james_w: No, not at all, I was just picking up the point above that some of this might get too long for the internal help [06:14] mrevell: Change between two unsync'd things has bitten me too many times :) [06:14] Ah, thanks fullermd and bwinton [06:15] mrevell: ok. [06:15] So, should we aim for examples for each command? [06:16] And of course the pre-mentioned Fundamentals stuff; a good chapter up front on that will save your life many times over later on. [06:16] Yes, definitely. Particularly on the options; when you'd use --xyz on a given command, not just the quickie description of what it does. [06:16] mrevell: yes. Covering as many use cases for the command as possible. [06:16] Great. [06:16] "Why would I use --reprocess?" "What does --verbose actually mean for this command?" etc. [06:17] (we could make bzr help examples/command work). [06:17] james_w: Do you think there'd be some people who wouldn't want to see the examples? [06:18] no, but again consideration of keeping the default help output reasonably short. [06:18] right [06:18] I'm not suggesting removing all examples from the help output. [06:18] they are usually the most useful bit. [06:18] james_w: Just keeping it to a reasonable length [06:18] indeed. [06:18] I consider "bzr help xyz" to mean "I know how this works, remind me of the options". [06:18] fullermd: Great, thanks. [06:19] (the concensus may be that the online help should be more involved than that; just my reflex view) [06:19] Are there any commands that are missing entirely from bzr help, that you know of? [06:19] there are hidden commands, but few of those are useful. [06:19] (in general). [06:20] And even they have help; they just don't show up in 'help commands'. [06:20] james_w: I presume they're hidden for a reason, though? [06:20] some commands could do with a brusign up of the help, and a couple of examples. [06:20] not all have helpful help, but yes they are hidden for a reason. [06:21] mrevell: are we concentrating on the in-source docs? [06:22] Okay, so the main thing I draw from this is that we need examples in bzr help, covering as many use cases as possible. I also take note of " I consider "bzr help xyz" to mean "I know how this works, remind me of the options"." [06:22] james_w: Anything that's in doc in the trunk atm. [06:22] yes, with a short synopsis. [06:23] mrevell: great. [06:23] james_w: But I'd be interested to hear about docs that are on the wiki and should be moved to the branch. === abadger1999 [n=abadger1@136.245.4.252] has joined #bzr [06:23] yeah, I'm not sure about that. === dpm [n=dpm@p54A13896.dip0.t-ipconnect.de] has joined #bzr [06:24] james_w: Yeah, obviously it'd have to be a special circumstance. [06:25] Okay, unless anyone's got anything else to say about the user reference I'd like to move onto the user manual [06:25] go ahead. === phanatic [n=phanatic@ubuntu/member/phanatic] has joined #bzr === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr === p4tux [n=p4tux@189.169.70.141] has joined #bzr [06:29] I'd like to make the user manual flow a little more and take the user on a journey from introduction through to in-depth, advanced topics. [06:30] The basic question, though, is again: what is missing from what we have already? [06:30] is http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html the one you mean? [06:30] Well, not missing, but it's weird that the HTTP smart server doc is separate from, in a different section from, and not linked to, the page that talks about the rest of the smartserver interfaces. [06:31] ("not linked to from", that is) [06:31] james_w: Yes, that's it. [06:32] fullermd: It's linked from the page james_w referenced, isn't it? [06:32] I wonder if the User Manual and User Reference really should be so separate. It almost seems like it should be one manual, with a spectrum from the relatively linear (step above tutorials) to the more random-access (command reference) [06:33] Yes, but there's "Running a Bazaar server" under "Basic Topics", that says nothing about and doesn't link to the bzr+http doc, which is under Best Practices (somewhat incongruously) [06:33] fullermd: Right, yes, "best practices" does seem like the wrong place for it. [06:34] Now, bzr+http setup is pretty long and involved, so it probably should be external to the rather short, simple setup for the other types. But more closely related than it is. [06:34] I'd propose to turn the user manual intoa tutorial [06:35] that takes the user from the start of using Bazaar right through to more involved processes. I think the distinction between that tutorial and the user reference would be more concrete then. [06:36] So, anything that isn't part of the (new) tutorial moves from the user manual to the reference. [06:37] ISTM that there are 3 natural divisions. [06:37] One is the "quick start". That's the "bzr in 5 minutes", the "here-kid-the-first-one-is-free" stuff. [06:37] :) [06:38] 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. [06:38] Yep [06:38] And the third would be the reference. In-depth discussion of commands and use-cases, lists of config options and revspecs, etc. [06:39] The second two could be bundled together as a 2-part "book" potentially. Certainly there'd be a lot of references to (3) in (2), "For more info, see ...". [06:39] The first would stand alone, and operate more as a hook. [06:39] Sorry. I'm real full of very etheral handwaving, and not so much concrete :| [06:39] I agree with those divisions. The mini-tutorial (which I've proposed become "Bazaar in 5 minutes") matches the first division. [06:41] Great, thanks for the feedback. === fullermd shuts up for a while. [06:42] thanks very much for your input fullermd :) === thatch [n=thatch@pool-71-96-248-177.dfw.dsl-w.verizon.net] has joined #bzr [06:43] If anyone thinks of any other gaps in the documentation - i.e. specific areas where we don't have any or we have very sparse documentation for a particular Bazaar feature - feel free to mail me matthew.revell@canonical, or of course mail the bzr list :) [06:44] I'm holding another of these meetings tomorrow (Tues) at 08.00 UTC. [06:45] Thanks everyone :) [06:45] Meeting ends but feel free to contact me any time with docs suggestions. [06:46] thanks mrevell [06:46] OK. The rest of you can get words in edgewise now ;) === dpm [n=dpm@p54A12E75.dip0.t-ipconnect.de] has joined #bzr === cprov-lunch is now known as cprov === GaryvdM [n=chatzill@dsl-243-161-42.telkomadsl.co.za] has joined #bzr === grimboy [n=grimboy@85.211.237.147] has joined #bzr === mrevell is now known as mrevell-dinner === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr === marianom [n=marianom@ubuntu/member/marianom] has joined #bzr === Vernius [n=tomger@p508AF23C.dip.t-dialin.net] has joined #bzr === mvo_ [n=egon@p54A66BD0.dip.t-dialin.net] has joined #bzr === BasicOSX [n=BasicOSX@216-250-174-201.static.iphouse.net] has joined #bzr === phanatic_ [n=phanatic@dsl5400C5D3.pool.t-online.hu] has joined #bzr === phanatic_ is now known as phanatic === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr === fog [n=fog@debian/developer/fog] has joined #bzr === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has left #bzr [] === jaguarondi_ [n=david@82.243-246-81.adsl-dyn.isp.belgacom.be] has joined #bzr === mvo_ [n=egon@p54A66BD0.dip.t-dialin.net] has joined #bzr === Mez_ [n=Mez@ubuntu/member/mez] has joined #bzr === herzel104 [i=herzel@gateway/tor/x-3eac73957eb94f65] has joined #bzr [09:55] anyone in here figured out how to configure meld to work with the extmerge plugin? === statik is being thick about understanding how meld arguments match up to extmerge === cprov is now known as cprov-afk === schierbeck [n=daniel@130.225.237.208] has joined #bzr [10:14] phanatic: mjellow === bwinton [n=bwinton@mail.phantomfiber.com] has left #bzr [] [10:14] schierbeck: hey, what does that mean? :) [10:14] hello :) [10:15] what's the status on using "revision history"? i say we go for it! === dbn [n=chatzill@vpn-034.comnets.RWTH-Aachen.DE] has joined #bzr [10:18] Hi all [10:19] "all" being like 2 people. [10:20] Hi peng. May I ask you a question concerning bzr 0.90? [10:20] I have a problem using the bundle command. [10:20] You can ask any question, but I may not know the answer. [10:20] 0.91 is out, FYI. [10:21] :) I give it a try, then. [10:21] I have setup a remote repository using bzr serve. [10:21] I made a branch from that location, applied some changes and said bzr bundle [10:22] bzr now gives a traceback complaining that [10:22] 'RemoteRepository' object has no attribute '_make_parents_provider' [10:23] That's strange. [10:23] That's what I thought. That's why I came here ;) [10:23] The usual workflow is to keep one copy of the upstream branch on your computer, then to branch off of that to make changes. [10:23] Maybe it's a 'bzr serve' bug. [10:23] Report it on the mailing list, maybe? [10:24] Well, I guess it's not a 'bzr serve' bug. [10:24] It works well when the remote repository is not contacted via the bzr protocol [10:24] yeah, that sounds like a bug. [10:25] schierbeck: okay, i'll wait till tomorrow. if noone has anything against it, i'll merge "revision history" [10:26] Do you want me to file a bug report for this? [10:26] If you do, include steps to reproduce it and a full traceback .. [10:26] dbn: yes please. [10:27] Probably I should try out 0.91 first. Maybe this is already resolved ... [10:28] yes, it might be. === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr [10:32] Ok, thanks. I will gather the steps to reproduce the bug and file it in the bugtracker. [10:33] dbn: it is easy to reproduce here. [10:33] bzr bundle bzr+ssh://localhost/home/jw2328/devel/bzr/bzr.dev [10:38] james_w: Shall I include that line in the bug report then? Is that sufficient for you? === calin [n=calin@89.136.187.239] has joined #bzr [10:38] dbn: unless you have any more interesting information. I think the problem is obvious enough. === Gwaihir [n=Gwaihir@ubuntu/member/gwaihir] has joined #bzr [10:40] james_w: Ok, thanks. === luks [n=lukas@unaffiliated/luks] has joined #bzr === hsn_ [n=chatzill@234.114.broadband5.iol.cz] has joined #bzr [11:02] bzr packages for windows are on wiki listed as 0.91 but they are 0.90 [11:05] New bug: #147836 in bzr "bzr 0.90.0 bundle command fails with bzr remote repositories" [Undecided,New] https://launchpad.net/bugs/147836 === BasicOSX [n=BasicOSX@216-250-174-201.static.iphouse.net] has joined #bzr === pacharasil_ [n=astromme@12-214-205-206.client.mchsi.com] has joined #bzr [11:15] hsn_: thanks, that's a known issue. You can get 0.91 if you access them directly, rather than using the current links. === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr [11:23] james_w: should i fix wiki? === asak [n=alexis@201-0-38-199.dsl.telesp.net.br] has joined #bzr === GaryvdM [n=chatzill@dsl-243-161-42.telkomadsl.co.za] has joined #bzr === phanatic [n=phanatic@ubuntu/member/phanatic] has left #bzr [] [11:35] Is their anyone here that is familiar with the merge_sort code? [11:35] I am having a problem where by it does not return revision number 1 [11:36] But that revision is in the graph and in the mainline [11:37] Code here: http://codebrowse.launchpad.net/~bzr/bzr-gtk/trunk/annotate/szilveszter.farkas%40gmail.com-20071001083733-mn111f1k16ojsqd8?file_id=graph.py-20051016214152-ebf565808c860cf7#L47 [11:40] New bug: #147860 in bzr "[BUG] renaming + kind change == assertion failure" [Medium,Triaged] https://launchpad.net/bugs/147860 [11:43] Ok - found my problem. === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr [11:44] You need to have revision number 1 at index number 1 of the mainline. Hence mainline[0] needs to be something else like None. === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has left #bzr [] === fog [n=fog@debian/developer/fog] has left #bzr []