#bzr 2007-10-01 <jaguarondi_> 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? <Verterok> moin <Peng> MediaWiki? <Vantage13> is there an environment variable to set to specify a different bzr lib directory? <matkor> 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 ? <pitti> hello <pitti> whoa, the first time in years that bzr really failed for me... <pitti> 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 <pitti> 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/') <pitti> any idea about that/ bzr upgrade'ing the debian svn checkout doesn't work either ("Cannot convert to format <RepositoryFormatKnit1>. Does not support rich root data.") <Lo-lan-do> You need to convert your branch to dirstate-with-subtrees or something <pitti> hm, 'dirstate-with-subtrees' does not exist, it is already 'dirstate', and it refuses to convert to 'knit' <Lo-lan-do> dirstate-with-subtree, sorry <vila> try dirstate-with-subtree <vila> :) <Peng> Are you planning to drop pycurl? One comment in a bug mentions it. <Lo-lan-do> 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" <fullermd> 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. <fullermd> 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. <ubotu> New bug: #147530 in bzr "pycurl http implementation peeks under the covers" [Low,Confirmed] https://launchpad.net/bugs/147530 <Lo-lan-do> I see. But I guess bzr-svn could be a bit more explicit in its error messages then. <fullermd> Well, I don't think the error message is coming from bzr-svn. <Lo-lan-do> I don't know where it comes from, but I do know it's confusing :-) <pitti> meh, now bzr merge excepts out on me; I guess I'll revert the conversion and use classical patch for now <fullermd> It's just a 'normal' bzr, "Hey-your-formats-are-incompatible-I'm-dying-here!" cry. <vila> Peng: see bug #82086 about dropping pycurl <ubotu> 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 <vila> fixing bug #147530 will at least gives a better error <ubotu> Launchpad bug 147530 in bzr "pycurl http implementation peeks under the covers" [Low,Confirmed] https://launchpad.net/bugs/147530 <fullermd> vila: What about the "stop making pycurl default if it's around" path that's been discussed a time or two? <vila> fullermd: and stop verifying site certificates by default ? I'm really no comfortable with that... <fullermd> Well, we're not verifying the certs by default for all the people who don't have pycurl installed. <vila> 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 <vila> 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 ? <fullermd> I don't have it as a dependancy of the BSD port. <vila> hmm <fullermd> 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. <vila> 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 <vila> fullermd: you can't have working setup with a self-signed cert unless bzr pycurl http implementation is patched <fullermd> Sure I can. I can not have pycurl installed and be using urllib, without having any idea that it's a problem. <vila> thinking that an urllib setup works scares me ! <fullermd> ("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) <vila> Do you know what was my *first* proposed patch for bzr ? <fullermd> Renaming the command 'vila'? <vila> 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 :-) <vila> Now, call me stubborn, but all my http-related activity is aimed at dropping pycurl support (while providing a better urllib impl. though) <vila> So dropping pycurl while not providing certificate verification <vila> ... does not fit the bill :) <vila> I tried to summarize in bug #82086 <ubotu> 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 <fullermd> Oh, I'm not proposing dropping pycurl; I'm mostly questioning whether it makes sense to use it by default when it appears. <vila> Well, it's true that the subject has come quite often lately, may be a list discussion is in order then <vila> so that all personal preferences and implications can be exposed * fullermd nods. <fullermd> 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. <fullermd> My going across the network tends to mostly be bzr+ssh :p <NamNguyen> abentley, ping <fullermd> Prob. be a while before he's around. <NamNguyen> alrighty ;-) <NamNguyen> i just hit a problem with bb <NamNguyen> 2nd time <Lllama> 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? <Lo-lan-do> Yes <Lllama> Lo-lan-do: cheers. <GaryvdM> 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. <matkor> Easiest way to see changes introduced in given revision or since given revno ? Prefereable like kdiff presents changes ? <Lo-lan-do> bzr diff -c 1234 <GaryvdM> 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 <GaryvdM> Then dose a RNFR /bzr-pushtree/trunk/.bzr/branch-lock/kasvrj7jcy.tmp/info <GaryvdM> That file dose not exist. <matkor> Lo-lan-do: bzr diff ... it is text only ... no graphical tool for that ? <Lo-lan-do> Oh. Dunno, maybe in olive-gtk. <GaryvdM> There is bzr-gtk - but it will not show you a sisde by side diff <GaryvdM> Try https://launchpad.net/bzr-difftools/trunk <GaryvdM> err https://launchpad.net/bzr-difftools <harrisony> "353 MB .zip file" hmm pain <harrisony> oops wrong window, sorry <matkor> Is there easy way to test (using bzrlib) if at given path there is checkout or branch ? <gabe> hi, what can i do about this showing up in bzr st? kind changed: <gabe> emailer/steves_mailer (directory => tree-reference) <matkor> I do bzrlib.workingtree.open_containing(path) , what should be next ? <AnMaster> 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 <fullermd> AnMaster: 'bzr break-lock' <fullermd> (of course it's an option. It's just a really bad one ;) <AnMaster> fullermd, yes because uploading about 50 MB on 128 kbps up for just the main branch will be a PAIN <AnMaster> fullermd, I hope this won't leave it in a broken state or so? <fullermd> 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. <fullermd> But if it's just a stale lock from a lost connection or something, it'll be fine. <AnMaster> yep I know what it was <AnMaster> 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 <fullermd> That, I have no idea on. <AnMaster> because ssh is on non standard port on this host <LeoNerd> Can't you just use the .ssh/config file in the usual way? <AnMaster> ah <AnMaster> LeoNerd, I normally do it like ssh -p port user@host but ok <LeoNerd> Yes; but the config approach has the advantage that all the SSH tools will use it <LeoNerd> And you don't have to think about it <AnMaster> true * AnMaster goes to read up on syntax of it * AnMaster swears loudly at trac-bzr <mrevell> Hey guys - I'll be holding the first of our two Bazaar Documentation meetings here on the hour. <fullermd> What all ground are you intending to cover? <mrevell> 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. <bwinton> 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.) <fullermd> 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. <fullermd> 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 :| <mrevell> fullermd: Thanks. I'll get the meeting under way. <mrevell> Welcome to this Bazaar Documentation meeting! Thanks for coming. <mrevell> The purpose of today's meeting is to identify gaps in the current Bazaar documentation. <mrevell> My aim is to help the Bazaar team to find and plug those gaps in time for the 1.0 release. <mrevell> I've divided the agenda into: <mrevell> * Is the user reference complete? <mrevell> * What is missing from the user guide? <mrevell> * What do we want to add the "advanced topics" and "best practice" sections? <mrevell> So, who's here for the meeting? Say "me", if you're here to chat about the docs. <mrevell> me <james_w> me <Lo-lan-do> Not me, sorry, I'm here to pester jelmer about bzr-svn :-) <fullermd> me (somewhat) <mrevell> Thanks guys, we can keep things pretty informal :) <mrevell> So, my first question: <james_w> Lo-lan-do: I didn't forward your latest bug as you said that jelmer was already aware. <mrevell> What do you feel is missing from the user reference? <Lo-lan-do> james_w: Fine by me <james_w> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html <james_w> mrevell: ^ that one? <mrevell> james_w: That's it, yeah. <keir> examples <james_w> so that is generated from bzr help. <mrevell> james_w: My main concern is that every command should be covered, as it's also the bzr help <fullermd> I feel that having the 'reference' generated from the online help is a wrong path; the needs of the two cases are totally different. <mrevell> james_w: Right, yeah <james_w> it's a good way of getting something together though. <fullermd> Examples are a big thing (and good examples often cross command boundaries). <james_w> I agree that it is not complete, or ideal though. <fullermd> 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. <keir> examples are usually what i want in man page type help <keir> sometimes it's not obvious how to string together the arguments for a command <james_w> yeah, a clear statement for each about whether it modifies the working tree, uses network etc. might be good to have as well. <fullermd> 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") <keir> usually, some command as only a couple 'common use cases' <james_w> fullermd: indeed. It might be useful to have online though. <fullermd> 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 :) <fullermd> Well. I'm iffy on that. If 'bzr help xyz' is more than a screenfull or two... <james_w> 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). <james_w> yes, not by default, but available. <james_w> hmmm, short meeting. <fullermd> See? The help was too long for him ;) <mrevell> Hmm, got disconnected. <mrevell> :) <james_w> :) <mrevell> Would it be reasonable to include a link to web based help, if a description was too long for bzr help? <fullermd> 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. <james_w> mrevell: reasonable yes, distros can patch this to point to a local copy as well. <fullermd> 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... <james_w> fullermd: there is conflicts documentation, but it needs some work, and I agree it should be in the reference section. <bwinton> I agree with fullermd on the link-to-online-docs point. <mrevell> fullermd: Why would deeper linking be a problem? Perhaps I'm missing something obvious :) <fullermd> 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. <james_w> mrevell: are you against having it in bzr then? <fullermd> Also, 3-way vs. weave/knit, why you'd use one over the other, and degenerate cases. <bwinton> mrevell: a deeper link will prevent us from radically changing the structure of the docs. <james_w> no, you can link to $version. <mrevell> 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 <fullermd> mrevell: Change between two unsync'd things has bitten me too many times :) <mrevell> Ah, thanks fullermd and bwinton <james_w> mrevell: ok. <mrevell> So, should we aim for examples for each command? <fullermd> And of course the pre-mentioned Fundamentals stuff; a good chapter up front on that will save your life many times over later on. <fullermd> Yes, definitely. Particularly on the options; when you'd use --xyz on a given command, not just the quickie description of what it does. <james_w> mrevell: yes. Covering as many use cases for the command as possible. <mrevell> Great. <fullermd> "Why would I use --reprocess?" "What does --verbose actually mean for this command?" etc. <james_w> (we could make bzr help examples/command work). <mrevell> james_w: Do you think there'd be some people who wouldn't want to see the examples? <james_w> no, but again consideration of keeping the default help output reasonably short. <mrevell> right <james_w> I'm not suggesting removing all examples from the help output. <james_w> they are usually the most useful bit. <mrevell> james_w: Just keeping it to a reasonable length <james_w> indeed. <fullermd> I consider "bzr help xyz" to mean "I know how this works, remind me of the options". <mrevell> fullermd: Great, thanks. <fullermd> (the concensus may be that the online help should be more involved than that; just my reflex view) <mrevell> Are there any commands that are missing entirely from bzr help, that you know of? <james_w> there are hidden commands, but few of those are useful. <james_w> (in general). <fullermd> And even they have help; they just don't show up in 'help commands'. <mrevell> james_w: I presume they're hidden for a reason, though? <james_w> some commands could do with a brusign up of the help, and a couple of examples. <james_w> not all have helpful help, but yes they are hidden for a reason. <james_w> mrevell: are we concentrating on the in-source docs? <mrevell> 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 "<fullermd> I consider "bzr help xyz" to mean "I know how this works, remind me of the options"." <mrevell> james_w: Anything that's in doc in the trunk atm. <james_w> yes, with a short synopsis. <james_w> mrevell: great. <mrevell> james_w: But I'd be interested to hear about docs that are on the wiki and should be moved to the branch. <james_w> yeah, I'm not sure about that. <mrevell> james_w: Yeah, obviously it'd have to be a special circumstance. <mrevell> Okay, unless anyone's got anything else to say about the user reference I'd like to move onto the user manual <james_w> go ahead. <mrevell> 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. <mrevell> The basic question, though, is again: what is missing from what we have already? <james_w> is http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html the one you mean? <fullermd> 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. <fullermd> ("not linked to from", that is) <mrevell> james_w: Yes, that's it. <mrevell> fullermd: It's linked from the page james_w referenced, isn't it? <fullermd> 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) <fullermd> 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) <mrevell> fullermd: Right, yes, "best practices" does seem like the wrong place for it. <fullermd> 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. <mrevell> I'd propose to turn the user manual intoa tutorial <mrevell> 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. <mrevell> So, anything that isn't part of the (new) tutorial moves from the user manual to the reference. <fullermd> ISTM that there are 3 natural divisions. <fullermd> One is the "quick start". That's the "bzr in 5 minutes", the "here-kid-the-first-one-is-free" stuff. <mrevell> :) <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. <mrevell> Yep <fullermd> And the third would be the reference. In-depth discussion of commands and use-cases, lists of config options and revspecs, etc. <fullermd> 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 ...". <fullermd> The first would stand alone, and operate more as a hook. <fullermd> Sorry. I'm real full of very etheral handwaving, and not so much concrete :| <mrevell> I agree with those divisions. The mini-tutorial (which I've proposed become "Bazaar in 5 minutes") matches the first division. <mrevell> Great, thanks for the feedback. * fullermd shuts up for a while. <mrevell> thanks very much for your input fullermd :) <mrevell> 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 :) <mrevell> I'm holding another of these meetings tomorrow (Tues) at 08.00 UTC. <mrevell> Thanks everyone :) <mrevell> Meeting ends but feel free to contact me any time with docs suggestions. <james_w> thanks mrevell <fullermd> OK. The rest of you can get words in edgewise now ;) <statik> 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 <schierbeck> phanatic: mjellow <phanatic> schierbeck: hey, what does that mean? :) <schierbeck> hello :) <schierbeck> what's the status on using "revision history"? i say we go for it! <dbn> Hi all <Peng> "all" being like 2 people. <dbn> Hi peng. May I ask you a question concerning bzr 0.90? <dbn> I have a problem using the bundle command. <Peng> You can ask any question, but I may not know the answer. <Peng> 0.91 is out, FYI. <dbn> :) I give it a try, then. <dbn> I have setup a remote repository using bzr serve. <dbn> I made a branch from that location, applied some changes and said bzr bundle <dbn> bzr now gives a traceback complaining that <dbn> 'RemoteRepository' object has no attribute '_make_parents_provider' <Peng> That's strange. <dbn> That's what I thought. That's why I came here ;) <Peng> The usual workflow is to keep one copy of the upstream branch on your computer, then to branch off of that to make changes. <Peng> Maybe it's a 'bzr serve' bug. <Peng> Report it on the mailing list, maybe? <Peng> Well, I guess it's not a 'bzr serve' bug. <dbn> It works well when the remote repository is not contacted via the bzr protocol <james_w> yeah, that sounds like a bug. <phanatic> schierbeck: okay, i'll wait till tomorrow. if noone has anything against it, i'll merge "revision history" <dbn> Do you want me to file a bug report for this? <Peng> If you do, include steps to reproduce it and a full traceback .. <james_w> dbn: yes please. <dbn> Probably I should try out 0.91 first. Maybe this is already resolved ... <james_w> yes, it might be. <dbn> Ok, thanks. I will gather the steps to reproduce the bug and file it in the bugtracker. <james_w> dbn: it is easy to reproduce here. <james_w> bzr bundle bzr+ssh://localhost/home/jw2328/devel/bzr/bzr.dev <dbn> james_w: Shall I include that line in the bug report then? Is that sufficient for you? <james_w> dbn: unless you have any more interesting information. I think the problem is obvious enough. <dbn> james_w: Ok, thanks. <hsn_> bzr packages for windows are on wiki listed as 0.91 but they are 0.90 <ubotu> New bug: #147836 in bzr "bzr 0.90.0 bundle command fails with bzr remote repositories" [Undecided,New] https://launchpad.net/bugs/147836 <james_w> hsn_: thanks, that's a known issue. You can get 0.91 if you access them directly, rather than using the current links. <hsn_> james_w: should i fix wiki? <GaryvdM> Is their anyone here that is familiar with the merge_sort code? <GaryvdM> I am having a problem where by it does not return revision number 1 <GaryvdM> But that revision is in the graph and in the mainline <GaryvdM> Code here: http://codebrowse.launchpad.net/~bzr/bzr-gtk/trunk/annotate/szilveszter.farkas%40gmail.com-20071001083733-mn111f1k16ojsqd8?file_id=graph.py-20051016214152-ebf565808c860cf7#L47 <ubotu> New bug: #147860 in bzr "[BUG] renaming + kind change == assertion failure" [Medium,Triaged] https://launchpad.net/bugs/147860 <GaryvdM> Ok - found my problem. <GaryvdM> You need to have revision number 1 at index number 1 of the mainline. Hence mainline[0] needs to be something else like None. #bzr 2007-10-02 <lifeless> yay net fuckage <mpt> Ok, this may be a silly question <mpt> But is there any way to revert to how a file/tree looked on a particular date? <mpt> Short of first using bzr log to find the newest revision before that date? <Peng> bzr revert -r date:2007-09-30 <Peng> See 'bzr help revisionspec'. <mpt> Neat! <Peng> Yeah. <mpt> And that's not mentioned directly in "bzr revert --help" because revisionspec is also used by diff <mpt> hmm <lifeless> mpt: we should add a seealso to revisionspec I guess <lifeless> brb <mpt> lifeless, it already says "See 'help revisionspec' for details", I just didn't realize that the "details" would be interesting or relevant to ARG <mpt> because they were on a separate line <mpt> which is an accident of how long "-r ARG, --revision=ARG" is <Peng> mpt: A lot of commands use -r. <poolie> hi <lifeless> mpt: this is true, but can we make it more clear <poolie> mpt, lifeless, hello <lifeless> poolie: just filed a bug <poolie> thanks <ubotu> New bug: #147916 in bzr "support for checkout of readonly url has regressed" [Undecided,New] https://launchpad.net/bugs/147916 <spiv> http://live.gnome.org/iogrind looks shiny <lifeless> is it a blocktrace wrapper? <spiv> lifeless: the page says <spiv> iogrind works in 3 parts: <spiv> * tracing the application using valgrind <spiv> * snapshotting the filesystem <spiv> * simulating the trace, against a snapshot to visualise. <lifeless> hmm <lifeless> should use blktrace ;) <lifeless> no need for snapshot <lifeless> jelmer: yo <ubotu> New bug: #147927 in bzr "use python -O (assertions off) when running installed copy" [Undecided,New] https://launchpad.net/bugs/147927 <lifeless> poolie: another patch sent in <jelmer> lifeless: hi <lifeless> your commit mails still say file:/// <lifeless> you need a public_url entry in your config <jelmer> whoops <Verterok> moin <Verterok> 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' <Verterok> 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 <lifeless> Verterok: its a feature <lifeless> 1 - changed <lifeless> 2 - unrepresentable changes <lifeless> 3 - error <lifeless> 0 - no change <Verterok> lifeless: thanks, now you tell me, It's a nice feature :D <lifeless> could you file a bug though, bzr help diff should list this <Verterok> ok, I'll do that <ubotu> New bug: #147938 in bzr "bzr help diff should list the meaning of exit values" [Undecided,New] https://launchpad.net/bugs/147938 <poolie> lifeless, are you sure bug 147916 is real? <ubotu> Launchpad bug 147916 in bzr "support for checkout of readonly url has regressed" [High,Incomplete] https://launchpad.net/bugs/147916 <lifeless> yes <lifeless> but I may be wrong <lifeless> or misjudging some root cause <lifeless> spiv: damn this patch is long <poolie> spiv, can you explain why you want bug 106898? <ubotu> Launchpad bug 106898 in bzr "put_bytes should raise a specific exception when given unicode" [Undecided,New] https://launchpad.net/bugs/106898 <lifeless> spiv: review sent <poolie> lifeless, i can't reproduce any failure with readonly branches, nor find a likely report in mail <poolie> there may well be one that i can't find <poolie> but for now, i'm going to just work on the other bit - better message when trying to commit to a readonly branch <lifeless> ok <poolie> i think it may be enough to (add a test and) just make that error a user error <poolie> and check the message is reasonable <lifeless> bbiab, fooding <poolie> is it just me or is BB timing out a lot? <lifeless> just you ? <lifeless> as in, it works for me <lifeless> spiv: ping <spiv> lifeless: pong <lifeless> you promised me a review :) <spiv> lifeless: thinking of which, lp reviewers meeting in a couple of minutes... <lifeless> oh crud <lifeless> my stomach has just decided to throw spasms at me <spiv> It dislikes the launchpad review team that much? ;) <lifeless> unrelated I think, but I'm going to do a runner * lifeless toilets <poolie> tmi <spiv> 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. <poolie> i guess the heart of it is <poolie> i'm not sure how much we should have apis promise they will reject invalid input <spiv> In that they should reject it, but not promise specifically how? <spiv> i.e. we should test simply for Exception in test_put_bytes_unicode and stop worrying about the details? <lifeless> poolie: I think its reasonable to promise when its a cheap promise; and/or the api is at the edge of a subsystem <poolie> that seems like a good guideline <poolie> spiv, well, why are you writing this test? <spiv> I don't really remember why I wrote it. (Or if I wrote it or just touched it?) <spiv> But it seems good to ensure that put_bytes will not silently accept unicode strings as if they are bytes. <spiv> 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. <poolie> yes, that's true <poolie> i would probably add TypeError or ValueError or both to the list of exceptions it can raise <poolie> i don't think we need to test that it raises one particular exception <poolie> i think declaring a new class would almost certainly be excessive <spiv> I agree that a new class would be excessive. <spiv> 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. <lifeless> well <spiv> Hmm, and ideally, it should raise when fed u'foo', not just u'\u1234', according to my argument above :) <lifeless> TypeError requires LBYL <spiv> (But the test currently only tests with u'\u1234') <poolie> spiv, i agree that it should do this <poolie> check the actual type rather than just whether it's convertible <lifeless> well <lifeless> the point is that it shouldn't be converted at all <lifeless> poolie: 139478 would be the regression <poolie> bug 139478 <ubotu> Launchpad bug 139478 in bzr "UnlockableTransport running update in checkout of readonly branch" [Medium,Triaged] https://launchpad.net/bugs/139478 <poolie> now that bug numbers are 6 digits maybe ubotu and the markup code should just always recognize them. <poolie> i'm working on those two now <lifeless> spiv: so, is that review pending? or no-comment ? <spiv> lifeless: pending <lifeless> k <ubotu> New bug: #147986 in bzr "branch in test root directory can cause confusing results" [Medium,Confirmed] https://launchpad.net/bugs/147986 <poolie> mrevell, hi <mrevell> hi poolie <mrevell> Over the 30 - 45 minutes, we're going to be discussing Bazaar documentation. <mrevell> Welcome to the meeting and thanks for coming :) <mrevell> The aim of this meeting is to identify gaps in the current Bazaar docs. <mrevell> Yesterday we had a similar meeting and the main issues raised were: <mrevell> * We need examples for as many use cases as possible for each command in bzr help/user reference. <mrevell> * We need good coverage of what sort of conflicts can happen, how you can provoke them, and how to clean them up. <mrevell> * We should make the split between user reference and user manual clearer. <mrevell> So, I'd be keen to hear what you guys feel we're currently missing. I'd like to cover: <mrevell> * The user reference: do we have an entry for each command, should we cover more advanced topics in the user reference? <poolie> that's a good list <Lo-lan-do> Two meetings a day? WHat kind of bureaucratic monster has #bzr become? <mrevell> Lo-lan-do: The other was yesterday my time :) <fullermd> He's just trying to have one without me around. <Lo-lan-do> mrevell: Mine too, but one every twelve hours still qualifies as two daily here :-) <mrevell> * The user manual: should this become a straight tutorial, with the reference materials moving into the user reference? <mrevell> Lo-lan-do: Fair point :) <poolie> Lo-lan-do, they won't repeat daily <lifeless> btw, <mrevell> So, starting with the user reference: have you noticed any obvious gaps in bzr help? <lifeless> packs are now annotation-free; this means their initial commit for any experimentation will be 30 seconds faster than they were yesterday. <lifeless> and I'm going to eat, sorry mrevell I will read and comment on minutes though, if there are any <mrevell> lifeless: thanks <poolie> mrevell, i think there are some gaps, <mrevell> lifeless: I'll post minutes to the bazaar list later today * lifeless waves <lifeless> ciao <poolie> there's a gap that the commands are not always explained from the right perspective of the person first reading about the command <mrevell> poolie: Ah, interesting. <poolie> a good example might be, um <poolie> well, an ok example is 'bzr help send' <poolie> it seems a bit like it just jumps into the details <mrevell> poolie: Yeah, I can see that. <poolie> i think the other thing that may be happening with the manual vs reference <poolie> is that the reference is taken from the materials in the help text <poolie> if we stick with this distinction, the online help will be all reference-type material, not introductory <poolie> and i'm not sure that's quite right <poolie> maybe it's ok, as long as they have a brief introduction to whatever topic they're talking about <mrevell> Right, yeah, I agree the online help should continue to have an introduction to each topic and should ease the reader into it <poolie> mrevell, did people say more yesterday about what that split should be? <mrevell> poolie: Just a moment, I'll put out a quote. <mrevell> fullermd suggested dividing the documentation along these lines, which I broadly agree with: <mrevell> fullermd One is the "quick start". That's the "bzr in 5 minutes", the "here-kid-the-first-one-is-free" stuff. <mrevell> 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. <mrevell> fullermd And the third would be the reference. In-depth discussion of commands and use-cases, lists of config options and revspecs, et <mrevell> Although I take the point that the reference must include introductory material for the online help. <fullermd> You can model those three as "get the flavor of bzr/get a recipe for a quick project contribution", "learn bzr", and "reference bzr". <poolie> that sounds pretty good <mrevell> 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. <mrevell> Thanks fullermd also <poolie> i think the only thing to do is to go through them one by one with new-user glasses on <mrevell> poolie: I have those glasses :) <poolie> 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 <poolie> the purpose * pbor would like a tips-and-tricks page/FAQ with quick oneliners for common stuff <mrevell> thanks pbor <pbor> I just expressed the desire to have it not to write it, so nothing to thank me about :) <mrevell> 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 <mrevell> pbor: Thanks for the suggestion :) <mrevell> poolie: Although obviously we can make the writing as tight as possible <poolie> pbor, yes, i think a faq would be a good idea - <poolie> particularly a single clearly-identified faq <poolie> i've been wondering if we should use answers.launchpad.net for that <poolie> (which i posted about recently) <poolie> it has some advantages, like trying to guide people who have new questions to the existing answers <mrevell> poolie: So, I like the idea of ensuring the most important info is in the first 1 - 5 sentences <poolie> and linking to bugs if the answer relates to a bug, though at the moment only weakly so <poolie> ok <poolie> i agree that sometimes it is hard to fit it in that limit <poolie> this is partly a problem of knowing just how much you ought to explain <poolie> obviously we don't want every command's help going from first principles <mrevell> poolie: I'll tkae an action item of looking at a good way of using the Answers FAQ system for bzr <mrevell> I'd like to move onto the user manual, unless anyone has more to say about the user reference. <poolie> sure <poolie> so for the manual <mrevell> I think the user guide's weakest point, at the moment, is in advanced topics. <mrevell> Perhaps some material could move out of the current tutorial <mrevell> into advanced topics * fullermd somewhat disagrees. <mrevell> fullermd: Please go ahead <fullermd> Well, it could just be a taxonomy issue, in what we want to have where. <poolie> 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 <fullermd> 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. <fullermd> The current User Guide is just a collection of rather independent articles. It's random-access. <fullermd> (that may be a more meta position than we want to go into, though) <mrevell> fullermd: I agree that we need to make the user guide more cohesive, and that each section should progress naturally one to the next. <fullermd> 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. <fullermd> (in fairness, that doesn't seem to be what the current UG is _trying_ to do, so...) <poolie> i agree about cohesion and flow too <poolie> i think that's because it's acreted rather than because it's particularly what people want <fullermd> Yah. It's more a "Hey, we have these docs; we better link to them all". <poolie> so what, if anything, would be the difference between such a guide, and an extended tutorial? <mrevell> 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 <poolie> it seems like they might cover the same concepts and commands <poolie> but a tutorial has more of a continuing worked example <fullermd> 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. <poolie> mrevell, what kind of thing are you thinking of as 'further reading'? <fullermd> 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. <mrevell> poolie: For example: hosting a team branch in Launchpad, or running a bzr smart server. <fullermd> Well, that comes back to my opinion about the place of 'bzr help'. But I think I'm minority there. <mrevell> poolie: Topics that aren't essential to everyday use of bzr <fullermd> I think the User Guide should very much reference the User Reference for more in-depth coverage. <mrevell> poolie: and perhaps that won't be applicable to everyone. <fullermd> 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. <poolie> actually i disagree about that particular case <mrevell> fullermd: I think my concern there is that it's not necessarily a clean break between the two. <mrevell> poolie: Ah, okay. Well, perhaps using some of the community's tools such as bzr-svn. <poolie> ok, so the guide should give you a map to most of the content in the reference? <fullermd> I picture the guide as giving you a solid working understanding. Read it, then you can comfortably use bzr for your projects. <fullermd> 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. <mrevell> fullermd: Do you think all of that should be in the online help? <poolie> my default position for the online help <fullermd> 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. <poolie> (i'm willing to change) <poolie> is that, well, what fullermd just said, pretty much <poolie> 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 <mrevell> right <poolie> ok <poolie> so on the guide in particular <poolie> i think we want to get rid of the section called 'tutorial' <mrevell> poolie: Yeah, and make the guide itself work as a tutorial <mrevell> poolie: in that progresses the user through each topic <mrevell> coherently <poolie> maybe a good place to start would be to just change it's index.txt to incorporate an outline of what should be there <fullermd> 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 :( <mrevell> 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. <poolie> at the moment 'configuration' is one of the first topics <poolie> did you get enough feedback on the 5 minutes doc? <poolie> i glanced at it and it looked godo <poolie> good <mrevell> 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 <mrevell> Someone said one part was a little too "cutesy", which I think was a fair comment. <mrevell> 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. <mrevell> Unless anyone has anything further they'd like to add, I'll close the meeting and continue discussion on the list. <poolie> just one more thing <mrevell> yeah? <poolie> one more open issue is this: there are several ways <poolie> you can set up to use Bazaar <poolie> so at the moment we have centralized_workflow; we could also talk about team branches, or using pqm, or other thnigs <poolie> similarly, shared repositories vs standalone branches vs checkouts <poolie> there's potential for confusion <poolie> i guess <fullermd> Well, for the latter, I think a good Fundamentals piece will cover that well (as I blathered about at excruciating length on the list) <poolie> we should be clear about what the mainstream method is <mrevell> right <mrevell> but present the alternatives and why you might want to use them <fullermd> 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. <poolie> the former? <fullermd> The workflows <fullermd> 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. <poolie> ok <fullermd> 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. <poolie> and then maybe the reference should describe the constituent parts <fullermd> 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 <fullermd> 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. <mrevell> 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. <fullermd> Not sure how to split that between Guide and Reference, though. The whole would be too big and deep for Guide. <fullermd> (obviously, I'm a big "understand the concepts, then the 'real' instances are Obvious(tm)" guy. That may be a blind spot.) <poolie> tutorials as such do tend to start out with specific examples <poolie> anyhow, that gives us something good to go on with <poolie> thanks, mrevell <poolie> i'm done if you are <mrevell> fullermd: I worry that starting with the concepts could overwhelm people. <mrevell> but obviously there's basic ground that needs to be covered to understand what follows <mrevell> yes, thanks poolie <mrevell> poolie: I have some great action points and input from these two meetings <fullermd> Yeah. It's a problem :( <mrevell> I'll write the meetings up for the list and come up with a first draft contents for the tutorial. <mrevell> I think I'll be relying heavily on community input for the more advanced topics. <mrevell> Thanks everyone. <vila> poolie: ping <vila> poolie: err, a bite late maybe :-/ <fullermd> Is it a bug that heavy checkouts don't inherit the branch nick from their branch? * fullermd thinks it is... <Enquest> How can I make sure that "bzr add" ignores a few directories <poolie> Enquest, add them to .bzrignore <Enquest> poolie, could you point me to the docs for this <Enquest> Where is .bzrignore located? <Enquest> on my home tree on the server tree? <poolie> Enquest, just in the root of your source tree <Enquest> there is no file there .bzrignore? <Enquest> I have to create it <Enquest> ? <poolie> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/tutorial.html <poolie> search for 'ignor' <poolie> you can either create it, or use the 'bzr ignore' command <poolie> to create it and add patterns to it <ubotu> New bug: #148030 in bzr "Heavy checkouts don't inherit nick" [Undecided,New] https://launchpad.net/bugs/148030 <pbor> 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? <fullermd> I don't think that way, no... <fullermd> (at least, necessarily) <pbor> 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 <pbor> usually it goes: "I want to fix this with a patch, how do I get the code" <pbor> when I start a new project and I pick a vcs chances are that I am already familiar with the vcs I pick <fullermd> Well, but the steps of using it are pretty much the same, and it's simpler to start describing in isolation (IMO) <gabe> Enquest: bzrignore is in your home dir <pbor> 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" <fullermd> Well. That gets into why I *HATE* quick-start docs. <pbor> 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 <sabdfl> hey revisionistas <vila> sabdfl: hi <sabdfl> vila: what's news in bzr-land? <sabdfl> is there a bundle-buddy page where I can see what's in the queue for review and landing? <jelmer> sabdfl: see http://bundlebuggy.aaronbentley.com/ <vila> Well, I don't follow as closely as I wish, but lifeless is working on big improvements with pack formats <vila> http://bundlebuggy.aaronbentley.com/ will show you all pending patches <vila> bulk of lifeless work does not appear there of course only bits he can merge now to bzr.dev <vila> also, spiv is working on some smart server improvements also not shown on BB <vila> but both their works are supposed to land for 0.92, so soon <sabdfl> thanks vila, that's a nice list <vila> sabdfl: you're welcome, but take it with a grain of salt, that's mostly my personal view, I may miss some parts <vila> sabdfl: and finally, mrevell is working on the doc, but you should know that ;) <fullermd> And I'm just sitting around stirring up trouble, as usual. <vila> and giving good hints for docs ;) <fullermd> Well, yeah, in the sense that "someone else should write them the way I think they should be" ;p <sabdfl> heh <sabdfl> every good project has a good curmudgeon <lifeless> vila: the packs patch is pretty small now, the review I got today gets rid of the largest non-format delta <lifeless> anyhow, its *sleep* time, just dropping by for a last minute irc fix ;) <vila> lifeless: glad to know :) Will tell it to sabdfl :) <vila> lifeless: have a good night <lifeless> 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 <sabdfl> light lifeless <Lllama> Afternoon all. Anyone managed to get Trac
{'channel': 'bzr', 'month': 10}