[12:07] <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?
[12:28] <Verterok> moin
[12:30] <Peng> MediaWiki?
[12:41] <Vantage13> is there an environment variable to set to specify a different bzr lib directory?
[08:49] <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 ?
[09:02] <pitti> hello
[09:02] <pitti> whoa, the first time in years that bzr really failed for me...
[09:03] <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
[09:03] <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/')
[09:04] <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.")
[09:05] <Lo-lan-do> You need to convert your branch to dirstate-with-subtrees or something
[09:07] <pitti> hm, 'dirstate-with-subtrees' does not exist, it is already 'dirstate', and it refuses to convert to 'knit'
[09:11] <Lo-lan-do> dirstate-with-subtree, sorry
[09:11] <vila> try dirstate-with-subtree
[09:11] <vila> :)
[09:11] <Peng> Are you planning to drop pycurl? One comment in a bug mentions it.
[09:12] <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"
[09:14] <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.
[09:15] <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.
[09:15] <ubotu> New bug: #147530 in bzr "pycurl http implementation peeks under the covers" [Low,Confirmed]  https://launchpad.net/bugs/147530
[09:16] <Lo-lan-do> I see.  But I guess bzr-svn could be a bit more explicit in its error messages then.
[09:16] <fullermd> Well, I don't think the error message is coming from bzr-svn.
[09:17] <Lo-lan-do> I don't know where it comes from, but I do know it's confusing :-)
[09:17] <pitti> meh, now bzr merge excepts out on me; I guess I'll revert the conversion and use classical patch for now
[09:17] <fullermd> It's just a 'normal' bzr, "Hey-your-formats-are-incompatible-I'm-dying-here!" cry.
[10:33] <vila> Peng: see bug #82086 about dropping pycurl
[10:33] <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
[10:34] <vila> fixing bug #147530 will at least gives a better error
[10:34] <ubotu> Launchpad bug 147530 in bzr "pycurl http implementation peeks under the covers" [Low,Confirmed]  https://launchpad.net/bugs/147530
[11:10] <fullermd> vila: What about the "stop making pycurl default if it's around" path that's been discussed a time or two?
[11:11] <vila> fullermd: and stop verifying site certificates by default ? I'm really no comfortable with that...
[11:11] <fullermd> Well, we're not verifying the certs by default for all the people who don't have pycurl installed.
[11:12] <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
[11:13] <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 ?
[11:13] <fullermd> I don't have it as a dependancy of the BSD port.
[11:13] <vila> hmm
[11:14] <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.
[11:14] <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
[11:15] <vila> fullermd: you can't have working setup with a self-signed cert unless bzr pycurl http implementation is patched
[11:15] <fullermd> Sure I can.  I can not have pycurl installed and be using urllib, without having any idea that it's a problem.
[11:15] <vila> thinking that an urllib setup works scares me !
[11:16] <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)
[11:16] <vila> Do you know what was my *first* proposed patch for bzr ?
[11:17] <fullermd> Renaming the command 'vila'?
[11:18] <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 :-)
[11:19] <vila> 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] <vila> So dropping pycurl while not providing certificate verification
[11:19] <vila> ... does not fit the bill :)
[11:20] <vila> I tried to summarize in bug #82086
[11:20] <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
[11:20] <fullermd> 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] <vila> Well, it's true that the subject has come quite often lately, may be a list discussion is in order then
[11:24] <vila> so that all personal preferences and implications can be exposed
[11:25] <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.
[11:26] <fullermd> My going across the network tends to mostly be bzr+ssh   :p
[11:57] <NamNguyen> abentley, ping
[11:58] <fullermd> Prob. be a while before he's around.
[11:58] <NamNguyen> alrighty ;-)
[11:59] <NamNguyen> i just hit a problem with bb
[11:59] <NamNguyen> 2nd time
[12:49] <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?
[12:49] <Lo-lan-do> Yes
[12:50] <Lllama> Lo-lan-do: cheers.
[01:12] <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.
[01:59] <matkor> Easiest way to see changes introduced in given revision or since given revno ? Prefereable like kdiff presents changes ?
[01:59] <Lo-lan-do> bzr diff -c 1234
[02:12] <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
[02:13] <GaryvdM> Then dose a RNFR /bzr-pushtree/trunk/.bzr/branch-lock/kasvrj7jcy.tmp/info
[02:13] <GaryvdM> That file dose not exist.
[02:13] <matkor> Lo-lan-do: bzr diff ... it is text only ... no graphical tool for that ?
[02:14] <Lo-lan-do> Oh.  Dunno, maybe in olive-gtk.
[02:14] <GaryvdM> There is bzr-gtk - but it will not show you a sisde by side diff
[02:15] <GaryvdM> Try https://launchpad.net/bzr-difftools/trunk
[02:15] <GaryvdM> err https://launchpad.net/bzr-difftools
[02:18] <harrisony> "353 MB .zip file" hmm pain
[02:18] <harrisony> oops wrong window, sorry
[03:55] <matkor> Is there easy way to test (using bzrlib) if at given path there is checkout or branch ?
[03:55] <gabe> hi, what can i do about this showing up in bzr st?    kind changed:
[03:55] <gabe>   emailer/steves_mailer (directory => tree-reference)
[03:55] <matkor> I do bzrlib.workingtree.open_containing(path) , what should be next ?
[04:22] <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
[04:23] <fullermd> AnMaster: 'bzr break-lock'
[04:23] <fullermd> (of course it's an option.  It's just a really bad one   ;)
[04:23] <AnMaster> fullermd, yes because uploading about 50 MB on 128 kbps up for just the main branch will be a PAIN
[04:24] <AnMaster> fullermd, I hope this won't leave it in a broken state or so?
[04:24] <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.
[04:25] <fullermd> But if it's just a stale lock from a lost connection or something, it'll be fine.
[04:25] <AnMaster> yep I know what it was
[04:26] <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
[04:26] <fullermd> That, I have no idea on.
[04:26] <AnMaster> because ssh is on non standard port on this host
[04:27] <LeoNerd> Can't you just use the .ssh/config  file in the usual way?
[04:27] <AnMaster> ah
[04:28] <AnMaster> LeoNerd, I normally do it like ssh -p port user@host but ok
[04:28] <LeoNerd> Yes; but the config approach has the advantage that all the SSH tools will use it
[04:28] <LeoNerd> And you don't have to think about it
[04:28] <AnMaster> true
[05:52] <mrevell> Hey guys - I'll be holding the first of our two Bazaar Documentation meetings here on the hour.
[05:54] <fullermd> What all ground are you intending to cover?
[05:56] <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.
[05:57] <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.)
[06:01] <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.
[06:01] <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   :|
[06:02] <mrevell> fullermd: Thanks. I'll get the meeting under way.
[06:02] <mrevell> Welcome to this Bazaar Documentation meeting! Thanks for coming.
[06:02] <mrevell> The purpose of today's meeting is to identify gaps in the current Bazaar documentation.
[06:02] <mrevell> My aim is to help the Bazaar team to find and plug those gaps in time for the 1.0 release.
[06:03] <mrevell> I've divided the agenda into:
[06:03] <mrevell> * Is the user reference complete?
[06:03] <mrevell> * What is missing from the user guide?
[06:03] <mrevell> * What do we want to add the "advanced topics" and "best practice" sections?
[06:03] <mrevell> So, who's here for the meeting? Say "me", if you're here to chat about the docs.
[06:03] <mrevell> me
[06:04] <james_w> me
[06:04] <Lo-lan-do> Not me, sorry, I'm here to pester jelmer about bzr-svn :-)
[06:04] <fullermd> me (somewhat)
[06:04] <mrevell> Thanks guys, we can keep things pretty informal :)
[06:04] <mrevell> So, my first question:
[06:05] <james_w> Lo-lan-do: I didn't forward your latest bug as you said that jelmer was already aware.
[06:05] <mrevell> What do you feel is missing from the user reference?
[06:05] <Lo-lan-do> james_w: Fine by me
[06:06] <james_w> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html
[06:06] <james_w> mrevell: ^ that one?
[06:06] <mrevell> james_w: That's it, yeah.
[06:07] <keir> examples
[06:07] <james_w> so that is generated from bzr help.
[06:07] <mrevell> james_w: My main concern is that every command should be covered, as it's also the bzr help
[06:07] <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.
[06:07] <mrevell> james_w: Right, yeah
[06:07] <james_w> it's a good way of getting something together though.
[06:08] <fullermd> Examples are a big thing (and good examples often cross command boundaries).
[06:08] <james_w> I agree that it is not complete, or ideal though.
[06:08] <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.
[06:08] <keir> examples are usually what i want in man page type help
[06:08] <keir> sometimes it's not obvious how to string together the arguments for a command
[06:09] <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.
[06:09] <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")
[06:09] <keir> usually, some command as only a couple 'common use cases'
[06:09] <james_w> fullermd: indeed. It might be useful to have online though.
[06:09] <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   :)
[06:10] <fullermd> Well.  I'm iffy on that.  If 'bzr help xyz' is more than a screenfull or two...
[06:10] <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).
[06:10] <james_w> yes, not by default, but available.
[06:10] <james_w> hmmm, short meeting.
[06:10] <fullermd> See?  The help was too long for him   ;)
[06:10] <mrevell> Hmm, got disconnected.
[06:10] <mrevell> :)
[06:10] <james_w> :)
[06:11] <mrevell> Would it be reasonable to include a link to web based help, if a description was too long for bzr help?
[06:11] <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.
[06:12] <james_w> mrevell: reasonable yes, distros can patch this to point to a local copy as well.
[06:12] <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...
[06:12] <james_w> fullermd: there is conflicts documentation, but it needs some work, and I agree it should be in the reference section.
[06:13] <bwinton> I agree with fullermd on the link-to-online-docs point.
[06:13] <mrevell> fullermd: Why would deeper linking be a problem? Perhaps I'm missing something obvious :)
[06:13] <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.
[06:14] <james_w> mrevell: are you against having it in bzr then?
[06:14] <fullermd> Also, 3-way vs. weave/knit, why you'd use one over the other, and degenerate cases.
[06:14] <bwinton> mrevell: a deeper link will prevent us from radically changing the structure of the docs.
[06:14] <james_w> no, you can link to $version.
[06:14] <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
[06:14] <fullermd> mrevell: Change between two unsync'd things has bitten me too many times   :)
[06:14] <mrevell> Ah, thanks fullermd and bwinton
[06:15] <james_w> mrevell: ok.
[06:15] <mrevell> So, should we aim for examples for each command?
[06:16] <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.
[06:16] <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.
[06:16] <james_w> mrevell: yes. Covering as many use cases for the command as possible.
[06:16] <mrevell> Great.
[06:16] <fullermd> "Why would I use --reprocess?"  "What does --verbose actually mean for this command?" etc.
[06:17] <james_w> (we could make bzr help examples/command work).
[06:17] <mrevell> james_w: Do you think there'd be some people who wouldn't want to see the examples?
[06:18] <james_w> no, but again consideration of keeping the default help output reasonably short.
[06:18] <mrevell> right
[06:18] <james_w> I'm not suggesting removing all examples from the help output.
[06:18] <james_w> they are usually the most useful bit.
[06:18] <mrevell> james_w: Just keeping it to a reasonable length
[06:18] <james_w> indeed.
[06:18] <fullermd> I consider "bzr help xyz" to mean "I know how this works, remind me of the options".
[06:18] <mrevell> fullermd: Great, thanks.
[06:19] <fullermd> (the concensus may be that the online help should be more involved than that; just my reflex view)
[06:19] <mrevell> Are there any commands that are missing entirely from bzr help, that you know of?
[06:19] <james_w> there are hidden commands, but few of those are useful.
[06:19] <james_w> (in general).
[06:20] <fullermd> And even they have help; they just don't show up in 'help commands'.
[06:20] <mrevell> james_w: I presume they're hidden for a reason, though?
[06:20] <james_w> some commands could do with a brusign up of the help, and a couple of examples.
[06:20] <james_w> not all have helpful help, but yes they are hidden for a reason.
[06:21] <james_w> mrevell: are we concentrating on the in-source docs?
[06:22] <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"."
[06:22] <mrevell> james_w: Anything that's in doc in the trunk atm.
[06:22] <james_w> yes, with a short synopsis.
[06:23] <james_w> mrevell: great.
[06:23] <mrevell> james_w: But I'd be interested to hear about docs that are on the wiki and should be moved to the branch.
[06:23] <james_w> yeah, I'm not sure about that.
[06:24] <mrevell> james_w: Yeah, obviously it'd have to be a special circumstance.
[06:25] <mrevell> Okay, unless anyone's got anything else to say about the user reference I'd like to move onto the user manual
[06:25] <james_w> go ahead.
[06:29] <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.
[06:30] <mrevell> The basic question, though, is again: what is missing from what we have already?
[06:30] <james_w> is http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html the one you mean?
[06:30] <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.
[06:31] <fullermd> ("not linked to from", that is)
[06:31] <mrevell> james_w: Yes, that's it.
[06:32] <mrevell> fullermd: It's linked from the page james_w referenced, isn't it?
[06:32] <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)
[06:33] <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)
[06:33] <mrevell> fullermd: Right, yes, "best practices" does seem like the wrong place for it.
[06:34] <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.
[06:34] <mrevell> I'd propose to turn the user manual intoa tutorial
[06:35] <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.
[06:36] <mrevell> So, anything that isn't part of the (new) tutorial moves from the user manual to the reference.
[06:37] <fullermd> ISTM that there are 3 natural divisions.
[06:37] <fullermd> One is the "quick start".  That's the "bzr in 5 minutes", the "here-kid-the-first-one-is-free" stuff.
[06:37] <mrevell> :)
[06:38] <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.
[06:38] <mrevell> Yep
[06:38] <fullermd> And the third would be the reference.  In-depth discussion of commands and use-cases, lists of config options and revspecs, etc.
[06:39] <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 ...".
[06:39] <fullermd> The first would stand alone, and operate more as a hook.
[06:39] <fullermd> Sorry.  I'm real full of very etheral handwaving, and not so much concrete    :|
[06:39] <mrevell> I agree with those divisions. The mini-tutorial (which I've proposed become "Bazaar in 5 minutes") matches the first division.
[06:41] <mrevell> Great, thanks for the feedback.
[06:42] <mrevell> thanks very much for your input fullermd :)
[06:43] <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 :)
[06:44] <mrevell> I'm holding another of these meetings tomorrow (Tues) at 08.00 UTC.
[06:45] <mrevell> Thanks everyone :)
[06:45] <mrevell> Meeting ends but feel free to contact me any time with docs suggestions.
[06:46] <james_w> thanks mrevell
[06:46] <fullermd> OK.  The rest of you can get words in edgewise now   ;)
[09:55] <statik> anyone in here figured out how to configure meld to work with the extmerge plugin?
[10:14] <schierbeck> phanatic: mjellow
[10:14] <phanatic> schierbeck: hey, what does that mean? :)
[10:14] <schierbeck> hello :)
[10:15] <schierbeck> what's the status on using "revision history"? i say we go for it!
[10:18] <dbn> Hi all
[10:19] <Peng> "all" being like 2 people.
[10:20] <dbn> Hi peng. May I ask you a question concerning bzr 0.90?
[10:20] <dbn> I have a problem using the bundle command.
[10:20] <Peng> You can ask any question, but I may not know the answer.
[10:20] <Peng> 0.91 is out, FYI.
[10:21] <dbn> :) I give it a try, then.
[10:21] <dbn> I have setup a remote repository using bzr serve.
[10:21] <dbn> I made a branch from that location, applied some changes and said bzr bundle
[10:22] <dbn> bzr now gives a traceback complaining that
[10:22] <dbn> 'RemoteRepository' object has no attribute '_make_parents_provider'
[10:23] <Peng> That's strange.
[10:23] <dbn> That's what I thought. That's why I came here ;)
[10:23] <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.
[10:23] <Peng> Maybe it's a 'bzr serve' bug.
[10:23] <Peng> Report it on the mailing list, maybe?
[10:24] <Peng> Well, I guess it's not a 'bzr serve' bug.
[10:24] <dbn> It works well when the remote repository is not contacted via the bzr protocol
[10:24] <james_w> yeah, that sounds like a bug.
[10:25] <phanatic> schierbeck: okay, i'll wait till tomorrow. if noone has anything against it, i'll merge "revision history"
[10:26] <dbn> Do you want me to file a bug report for this?
[10:26] <Peng> If you do, include steps to reproduce it and a full traceback ..
[10:26] <james_w> dbn: yes please.
[10:27] <dbn> Probably I should try out 0.91 first. Maybe this is already resolved ...
[10:28] <james_w> yes, it might be.
[10:32] <dbn> Ok, thanks. I will gather the steps to reproduce the bug and file it in the bugtracker.
[10:33] <james_w> dbn: it is easy to reproduce here.
[10:33] <james_w> bzr bundle bzr+ssh://localhost/home/jw2328/devel/bzr/bzr.dev
[10:38] <dbn> james_w: Shall I include that line in the bug report then? Is that sufficient for you?
[10:38] <james_w> dbn: unless you have any more interesting information. I think the problem is obvious enough.
[10:40] <dbn> james_w: Ok, thanks.
[11:02] <hsn_> bzr packages for windows are on wiki listed as 0.91 but they are 0.90
[11:05] <ubotu> New bug: #147836 in bzr "bzr 0.90.0 bundle command fails with bzr remote repositories" [Undecided,New]  https://launchpad.net/bugs/147836
[11:15] <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.
[11:23] <hsn_> james_w: should i fix wiki?
[11:35] <GaryvdM> Is their anyone here that is familiar with the merge_sort code?
[11:35] <GaryvdM> I am having a problem where by it does not return revision number 1
[11:36] <GaryvdM> But that revision is in the graph and in the mainline
[11:37] <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
[11:40] <ubotu> New bug: #147860 in bzr "[BUG]  renaming + kind change == assertion failure" [Medium,Triaged]  https://launchpad.net/bugs/147860
[11:43] <GaryvdM> Ok - found my problem.
[11:44] <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.