[00:02] luke-jr: yes, use bzr:file-ids as revprop [00:02] luke-jr: and set that on a revision in which the file was introduced [00:03] luke-jr: alternatively, "bzr reconcile" might do what you want [00:14] jelmer: another problem that I just thought of... :/ [00:15] somehow I'll need to rebase the merged branches :\ [00:15] I suspect I'm going to want to introduce 2 new revs for each original bzr rev [00:15] a rebased one and a merge of the rebased one and the original one [00:16] or perhaps I can have the rebased one list the original one as a parent... hmm [00:34] jelmer: I can't find that mapping spec [00:36] luke-jr: specs/mappingv4.txt [00:40] ah [00:40] README had referred to some weird path :( [00:51] bzr:file-ids revprop doesn't seem to do anything :( [00:51] nor bzr:skip :/ [00:56] luke-jr: have you erased the cache ? [00:56] luke-jr: also, have you set other bzr: revprops? [00:58] yes; not yet [00:58] bzr:skip looks to just be poorly documented [00:58] I expected to be able to set it on svn-r1 and get bzr to skip over that rev [01:01] luke-jr: this is a design document, not a document aimed at users so they can set their own revision properties [01:01] anyhow, bzr:file-ids still seems to be ignored [01:01] do I need to set other properties to make it take effect? (perhaps bzr:mapping-version?) [01:01] luke-jr: bzr:skip only means bzr-svn can avoid checking any other bzr-svn metadata for that revision [01:02] luke-jr: yes, you need to set more than just bzr:file-ids [01:02] luke-jr: at least bzr:mapping-version and bzr:root IIRC [01:03] what should they be? [01:04] the real repo has no bzr:mapping-version at least. :/ [01:04] luke-jr: I would recommend running "bzr reconcile" and checking what that sets [03:00] bzr nested trees rock way better than git subtree merge =) [03:02] I now do $ bzr merge svn://svn.server.org/path/to/external [03:02] and get everything i want =)! in the correct subdir of my project ;-) [03:06] xnox: I was under them impression that nested trees hadn't landed. Am I confused or are you working off a dev branch? [03:06] jbowtie, by reference nested trees are not here yet. [03:07] jbowtie, but you can do this $ bzr branch URL subdir/ [03:07] $ bzr join subdir [03:07] $ bzr ci -m "Merging external code from any URL" [03:07] and from now on you can do [03:07] $ bzr merge URL [03:07] to update the code [03:08] but this makes history of that subdir part of your history [03:08] join & split have landed in bzr a while ago [03:08] xnox: Oh, OK. I'd never seen the join/split commands before, must read release notes more in future. [03:09] xnox: That gives me the benefits of svn:externals under Bazaar, right? [03:09] jbowtie, when we have by reference trees you will be able to have stuff like externals where that code is almost not part of your history & has independed branch on it's own. [03:09] jbowtie, almost =) [03:10] xnox: Almost is good enough for most of my scenarios. [03:10] jbowtie, yes almost good =) [03:11] if you want to work & submit patches to that external you are better off branching it on it's own, then try to commit stuff in your containing project [03:11] "then" = "than" [03:12] OK, my TFS plugin seems to be working well enough for read-only access to TFS repositories. (Microsoft Team Foundation Server) [03:13] Just need my manager to sign off on my pushing it to Launchpad. [03:15] xnox: Does pull update the joined directory, or do you have to explicitly merge? [03:15] jbowtie, you have to do merge [03:16] jbowtie, cause history has diverged from both places. [03:16] jbowtie, with by-reference nested trees you will be able to just pull [03:16] jbowtie, but we don't have that yet =) [03:17] jbowtie, I have svn import running of 2 projects on launchpad. With one having svn:external to the other [03:17] jbowtie, to update to latest code after the intial $ bzr join [03:17] I have to do $ bzr merge URL-super [03:17] $ bzr merge URL-external [03:18] then I have locally everything tip-top [03:20] xnox: Thanks, that makes everything clear. Will definitely start using join for a couple of projects. [03:20] jbowtie, your welcome =) I should blog about it ;-) [03:23] Hmmm...how do you provide tests for something that talks to a proprietary foreign VCS? [03:30] jbowtie, depends on which one.... =) but generally it is bzr protocol tests. And you right a test stub using bzr-test framework which does the intended behaviour. (documented, speced) etc... such that it can be run automated without having access to that VCS [03:38] xnox: Tricky. But just realised I can capture HTTP output and replay that during tests for the actual "talk to a VCS" class. [03:38] =) nice [03:39] which VCS are you working on? or is it top-secret? [03:39] Microsoft Team Foundation Server. [03:39] there have been issues with bitkeeper...... [03:39] No secret, just ugly, ugly code. [03:39] jbowtie, aha =) that beast. [03:40] are you switching to bzr from that? [03:40] xnox: Yes, getting my team to, anyway. I can checkout and pull updates from TFS now. [03:41] jbowtie, publish code on lp. I'm pretty sure loads of people will find it useful [03:41] xnox: Pushing updates to TFS is possible but needs a bit more work so that round-tripping is a bit more solid. [03:41] jbowtie, is there bzr plugin for VS? [03:42] xnox: Just waiting for manager to sign off on publishing to Launchpad. [03:42] xnox: Not that I know of but project in question is using Eclipse anyway. [03:42] jbowtie, aha =) https://edge.launchpad.net/bzr-visualstudio [03:42] it's for 2005 though [03:43] xnox: Once I've published the TFS work I'll have a look at updating that. [03:44] I want to update the plugin developer's guide with info on writing a VCS plugin, but can't find it in launchpad. [03:47] Probably I'll just end up blogging it. [04:01] hi, bzr 2.1.1 on windows doesn't print any messages in any command. Does anybody know why? [04:04] For example, when I do "bzr pull", the message "Using saved parent location..." is not printed; when I do "bzr pack", the message "repacking..." is not printed [04:05] and bazaar.conf does not have likely related setting [04:05] echo-area: That's not what I'm seeing (just checked) [04:05] echo-area: Does bzr --version print anything? === timchen1` is now known as nasloc__ [04:12] jbowtie: um, my description was a bit wrong. Something is printed, but the other information is not. "bzr --version" indeed prints version information. But for "bzr pull", only the list of changes is printed, the information like "Using saved parent location..." and about the fetching progress is not printed. For "bzr pack", nothing is printed [04:15] and I remembered when I used bzr 2.1.0, that information was printed [04:15] echo-area: AFIAK that hasn't changed in 2.1.1 - certainly the saved parent thing is happening on my Windows box. [04:16] echo-area: Does a "bzr info" show that there is a saved parent? [04:17] echo-area: Don't forget, you can always use the verbose switch (-v), might mention something useful. [04:18] jbowtie: I tried "bzr pack -v", but still, nothing is printed. It's so strange [04:18] echo-area: The only thing that springs to mind is that one of your streams (stdout, stderr) is being redirected somehow. [04:19] echo-area: I've had that happen to me once or twice, where stuff printed to stderr got captured by a debug utility. [04:19] jbowtie: I guess so, but how come a plain "bzr pack -v" redirects? [04:21] echo-area: No idea, and that's just a guess anyhow. Are you using PowerShell by any chance, or the standard command shell? [04:22] jbowtie: I'm using C:\WINDOWS\system32\cmd.exe. [04:23] echo-area: Hmm. Maybe bzr pack has nothing to do? [04:25] jbowtie: I don't know, but I guess not, since every time I run "bzr pack" on a Linux box, there is information printed. But this is not a problem until now, so I think I can live with that [04:28] echo-area: OK. Let us know if you have any other issues, I can at least run a quick test on another Windows box for comparison. [04:29] Hi. Can I pull from branches other than master with bzr-git? [04:30] jbowtie: okay, thank you :) [04:31] I tried 'bzr git-import' which gives me a tree, but then I can't push/pull after that. [04:44] dcoles: Are you trying to merge the changes from the other branch into yours, or switch to using it as your parent branch? [04:46] jbowtie: Ideally, I just want to check it out to work on it and then be able to push changes to that branch [04:47] Trouble I'm having is I can't think how to provide the branch in the git+ssh url [04:48] hm [04:51] dcoles: I'm not a git user; but looking at the documentation for bzr-git that might not be possible. [04:51] dcoles: Could you clone the git branch into another location, the use bzr to check that out? [04:52] Yeah. I was worried about that. I even went to the extent of browsing the bzr-git sourcecode [04:53] jbowtie: That might be the way of doing it. Just make sure you "checkout" the right git branch [04:54] I'm not a git user either, but learning _far_ too much about it looking after a project's git repository ;) [04:55] bzr-git currently can only interact with the master branch in a git repo aiui [04:56] mwhudson: Righto. That makes sense. [05:39] Is Bazaar 2.x packaged anywhere for RHEL? [05:39] jbowtie: http://wiki.bazaar.canonical.com/DistroDownloads#CentOS/RHEL perhaps? [05:40] Looks like it should already be in yum. [05:40] dcoles: That only has 1.3.1 - pretty old [05:41] Ah. That's a shame. :S [05:52] And of course gcc is not installed on the RHEL box I want to install it on. [05:56] I saw some rumors about it being included in RHEL6, but who knows when that is coming out [05:57] One might assume it might be possible to nab from Fedora, but who knows what kind of dependancies that would try and drag with it. [06:00] dcoles: There's always the long way - spin up a CentOS image, install gcc, build the RPM, scp to the server, install. Bleh. [06:00] Yuck. At least bzr is a reasonably nice package to build [06:01] Hopefully one of the lurkers will feel guilty enough to update the yum repository. [06:02] * jbowtie looks around for anyone with a guilty look. [06:02] jbowtie: I tried the "git clone x, git checkout branch; bzr branch x y" method. It works. But you have to do a 'git reset --hard' after you dpush back. [06:03] And using bzr in the git repo seems to crash bzr when I try and commit (not sure if that's a legal use of bzr or not) [06:03] dcoles: Important thing is that you are not stuck, glad I could help with that much. [06:04] :) [06:04] I could always just use git.... blehgh [06:04] dcoles: I'll keep an eye on the Bazaar blueprints during UDS, maybe we can get someone to do something about that. [06:05] Well, I think the current block was "colocated branches" [06:06] dcoles: Personally I'll probably work on cleaning up the documentation, it's getting a little hard to find details I need. [06:06] But even just being able to do bzr co git+ssh://example.com/repo#branch would be quite nice. [06:07] Indeed. I've been pestering jelmer about a lot of the bzr-git stuff. [06:07] There's also quite a few references to bzr-git being "read only", despite having dpush now. [06:09] I'd love to sit down and hack on the plugin one afternoon. It's really neat except for one or two little bugbears. [06:17] dcoles: It's not like you need commit access. ;) [06:18] Whoops, gotta go, have a train to catch. [06:19] Cya [06:19] Whoops. Too late. [07:45] hi all [08:29] hi all [08:29] how come, that in my working copy I get the latest revision when doing bzr log [08:29] and when I go the parent branch, [08:29] then it shows a couple of revisions back? [08:30] (sorry for using CRLF as punctuation) [08:34] sivang, ? what does `bzr status` show in both directories? [08:34] and what is bzr info in both of them [08:58] xnox: let me check [10:22] xnox: in one dir, a bunch of unknowns [10:25] xnox: in the other : [10:25] :~/ccforms_renamed$ bzr status [10:25] bzr: ERROR: No WorkingTree exists for "file:///home/sivan/ccforms_renamed/.bzr/checkout/". [10:26] sivang, so looks ok to me. Depending on what you are trying to do [10:26] and what type of checkout you use [10:27] sivang, if you do `bzr info` in both of them it should tell you what are the relationships, if any, between those two branches [10:27] xnox: so the one that does now show all the revision in log, is the push target of the working copy [10:28] I wouldn't assume he's using [explicit] checkouts at all. It just sounds like he's got two branches that are at different places, which is... well, normal. [10:28] xnox: how can I make it show all the revision, since when I check out from it or bracnh, it doesn't get revision up to the last one [10:28] Why do you think they SHOULD have the same revs? [10:28] fullermd: I use the push target is the parent branch or repo [10:28] fullermd: or am I not? [10:28] Sure, but did you push them? [10:28] 'missing' is also your friend here. [10:28] sivang, what do you mean by "working copy" - checkout, lightweight checkout, or branch? [10:29] xnox: okay, so I see bzr lingo thickens the plot a bit [10:29] xnox: I init'd a a dir [10:29] xnox: commited into it [10:29] xnox: and then pushed to a "backup" location [10:30] oops [10:30] forgot to push [10:30] geez [10:30] now it is synced [10:30] sivang, =) [10:30] * sivang turns to be the lolipop figure in Bugs Bunny film [10:31] xnox: so, is there a book ? an oreilly book already so learn all things bzr from start to finish ? [10:31] * sivang googles for the difference between a checkout, lw checkout and bracnh [10:31] there's is no repo notion right? [10:31] (like in svn) [10:32] sivang, http://doc.bazaar.canonical.com/bzr.2.1/en/ [10:32] but still, if I have a parent branch [10:32] sivang, yes there is but a lot different from svn [10:32] parent branch: /home/sivan/ccforms_renamed [10:32] sivang, do this [10:32] xnox: I remember lifeless talking lots about the difference [10:32] in a temporary location [10:32] $ bzr init-repo . [10:32] $ bzr info [10:33] * sivang tries [10:33] $ bzr init branch-a [10:33] shared repo with trees? what does that mean? [10:33] $ cd branch-a && bzr ci --unchanged -m "my first commit" [10:33] $ cd ../ [10:34] $ bzr checkout branch-a branch-b [10:34] $ bzr info branch-b [10:34] $ cd branch-a [10:34] $ bzr ci --unchanged -m "checkout branch-b should be out-of date now" [10:34] $ bzr info branch-b [10:34] $ bzr status branch-b [10:35] Checkout of a branch is similar to svn, where commits in the checkout will end up in the branch [10:35] xnox: okay, so what I was looking actually instead of just a branch, is to creat e a repo and so commits will work against it? [10:36] xnox: I wanted commits from the local machine, and from another remote machine to end up in the same source tree [10:36] xnox: with revisions and everything [10:36] xnox: so I can either work on my desktop or from the remote server transparently [10:37] sivang, that would be dangerous cause you might override working tree on the server & desktop [10:37] sivang, what you should do is this [10:37] xnox: I want to have a working tree at a seperate location [10:37] 1) create a branch on the sever [10:37] xnox: just a "shared repo" is that the right term? [10:38] sivang, repo is where the revisions are stored but repo still has to have branches in it so that there is a *named* location to push to. [10:38] So on the server create a repo & branch underneath it [10:38] when you are on the desktop do $ bzr checkout $URL-branch-on-server [10:39] when you are on the server do $ bzr checkout /path/to/branch/on/server [10:39] Always commit to checkouts *of* the branch on server [10:39] this way whenever you make or update a checkout you will get latest code from your "central" branch [10:40] sivang, http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/central_intro.html [10:42] xnox: I see, but when commiting to a checkout that means commiting to the .bzr inside the workign copy [10:42] xnox: how do I get those updates to the parent branch in the central repo ? [10:42] sivang, no it will commit on the server [10:42] xnox: ok, I will dio some reading :) [10:42] sivang, if you look into the .bzr dir inside you will notice it has three major folders: [10:43] xnox: bzr got some feature rich since last time I used it for hubackup [10:43] repository, branch, checkout [10:43] yes [10:43] even when I jsut init a dir, [10:43] in the repository it stores raw bytes, in the branch it stores references as to which revision this branch points at and in checkout it stores the current status of the working tree [10:43] which means I created a new branch right? [10:43] when you do $ bzr init it creates all three [10:44] when you do $ bzr init-repo DIR [10:44] it will create $ DIR/.bzr/repository [10:44] such that all branches underneath $ DIR store there bytes together & efficiently sharing them [10:44] when you do $ bzr checkout $URL [10:45] the docs are nice muchly improved [10:45] xnox: I create a mirror of the branch ? [10:45] so to speak [10:46] it will place bytes in a shared-repo if present, and then create a working directly (checkout) with no separate branch. Intead it will put reference "saying when I commit in this working tree, take my local bytes but commit in the target branch" [10:46] ah [10:46] cool, so like a mirror [10:46] yes [10:46] xnox: thanks dude [10:46] sivang, furthermore you can have lightweight-checkouts [10:46] xnox: which are? [10:47] those do not have their own repository and are usefull when you are working with large repositories [10:47] Don't get hung up on the difference between light and heavy checkouts... [10:47] do the significance of a repo is just to share bytes? [10:47] Heavies make a local cache of the revs; lights don't. [10:47] then you will have a tree-less repository such that all branches do not have working tree in them (cause it's a 100MiB big) [10:47] right , so for large repos heavy are better [10:47] You probably only want to use a light checkout when the branch is on the local disk, or possibly close by on a very fast network. [10:48] and you will have one lightweight checkout which just represents a working-tree attached to a particular branch. And then you can do $ bzr switch [10:48] fullermd: right, so when I work on the server, light-checkout [10:48] to jump from one branch to another [10:48] fullermd: on the desktop at home, heavy [10:48] sivang, yes repo is to share bytes [10:48] xnox: this is different from svn so deeply [10:48] xnox: a repo is a dir mostly there :) [10:49] sivang, locally. Two repositories with bytes never will mirror each other. You can only push branches around which will take the bytes with them & put their bytes in the repos [10:50] xnox: so when I init'd the local folder I worked on, and then pushed it to my backup location, what was the relationsip and what happened between them? [10:50] sivang, you got heavy & light right [10:50] sivang, you have (branch & repo & checkout) <-----> (branch & repo) [10:51] unless you did $ bzr co /path/to/branch on the server [10:51] xnox: so due to the face that there was no relationship between them, just a push target, revision did not automatically got updated at the push target [10:51] then you have (branch & repo & checkout) <-----------> (branch & repo & checkout) [10:51] sivang, "not automatically" on commit on either of them [10:51] xnox: what causes the automatic update relationship to occur ? [10:52] Thinking of automatic vs. non-auto is likely to wind up more confusing. [10:52] When you make a commit, it goes onto the branch you're working on. So the question is always, what branch am I working on? [10:52] (repo & checkout ) <------------> (branch & repo) <-----------------> (repo & checkout) [10:52] If you have a checkout, the branch is the thing you `bzr co $THING`'d. [10:53] If you did a `bzr branch $THING`, your local dir is its own branch. [10:53] fullermd: right, okay it starts to be clearer now [10:53] fullermd, yeap nice explaination [10:53] 'push' and 'pull' are commands you use to move existing revs from one branch to another. [10:53] fullermd: nice, so back to DRCS [10:53] * xnox says what's DRCS? [10:54] Distributed revisionc ontrol [10:54] the co and repo is the bzr support for centreal rc [10:54] no ? [10:54] That's one way of thinking about it... [10:54] Better, though, to think of it Branch-centric. [10:54] and working with branches is good'o distributed, when you have a merge action between them [10:55] sivang, yeap. If you have one branch on the server and you have multiple checkouts it's like having svn server & checkouts [10:55] Using co is a way to get multiple working trees all on a single branch. [10:55] cool [10:55] thank yo guys! [10:55] Are you with Canonical btw? [10:55] * xnox no [10:55] Which is similar to what you do with a centralized system. But thinking of it around branches probably keeps things straighter. [10:55] You may want to peruse some of the stuff at http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs [10:56] http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief particularly for some background vocabulary, and http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevHandling for some talk about push/pull/etc. [10:58] fullermd: thanks, irssi logged it and I shall read it! [10:58] now , off to lunch. [12:02] Which Launchpad project do I need to contribute to the documentation? [12:04] documentation of bzr? [12:04] ok [12:05] jbowtie: documentation of bzr? [12:05] Yes, documentation of Bazaar. I want to clean up a few of the less maintained corners. [12:05] Those empty sections in the admin guide also bug the heck out of me. [12:08] is there a way to make 'bzr commit' not throw an error if there's nothing to commit, without allowing it to commit an empty revision? [12:09] jbowtie: There's a bzr-doc team with a mailing list, but it's just handled through the normal bzr project. [12:09] we spent the weekend converting from CVS, and we were taking advantage of the fact that cvs will gladly do nothing when nothing has changed in a bunch of our automated scripts [12:09] jbowtie: File bugs, file merge proposals, whatever. [12:09] faceprint: Ahh... That's a pretty obscure request, and I doubt bzr has a knob somewhere to do it. [12:10] Peng_: Sorry, are you saying the docs are somewhere in the bzr source tree? [12:10] jbowtie: Yes. [12:10] faceprint: I'm not sure I understand what you're asking for? [12:10] jbowtie: Not, like, the wiki, but most of the documentation is. [12:10] faceprint: --unchanged is not what you're after? [12:10] jelmer: I think what he's after is that he wants the exit code to be 0 even if nothing has changed. [12:11] faceprint: Probably not hard to write some Python to accomplish that, but... [12:12] jelmer: i have scripts that grab the latest versions of certain files, or re-compute certain files (yes, this is kind of an abuse of version control, but it's what we have), and then commit them if there are changes. We had been just running cvs commit after generating the new version, and if there were changes they got committed. If the files ended up identical, everything just exited silently [12:12] if I use --unchanged, I'm going to add another 10 or so revisions to my repository every morning with empty commits [12:12] Peng_: OK, I see the admin guide, but not the plugin developer's guide. [12:14] faceprint: you could do some scripting to find out if there are any changes to commit [12:15] yeah, I started down that path, and realized that bzr stat doesn't seem use return codes at all, so I'm actually going to have to look at its output [12:15] it isn't a huge deal, and honestly if this is the only hiccup in this transition, i'm a very happy guy (knock on wood) [12:16] Peng_: That can't be everything. The migration guides for users of other VCS, plugin docs, plugin developer guide - none of that's in the bzr tree. [12:16] faceprint, $ bzr commit returns exit code 3 when there is nothing to commit [12:16] e.g. pointless commit [12:16] And why is there a project called bzr-alldocs that doesn't contain all docs? [12:16] xnox: which doesn't help me in deciding whether to run bzr commit or not ;-) [12:17] faceprint, just run it and catch and check that exit code. Or is there someother logic apart from "when changes -> commit; when no changes -> do not commit" [12:17] jbowtie: bzr-alldocs is for bazaar.canonical.org website [12:18] really, I'm just trying to avoid cron email from all these scripts, but don't want to send stderr to /dev/null in case something actually IS wrong [12:18] faceprint, ok another one $ bzr diff exits 0 if there is no diff, exits with 1 if there is diff and hence there are changes [12:18] faceprint, is this better? [12:19] ah, that'll work. don't know why I didn't think of diff earlier [12:19] bialix: OK, so documentation is split up across multiple sites? [12:20] No wonder the docs are such a mess. [12:20] jbowtie: which kind of documentation? [12:20] faceprint, if you generate new files you will need to somehow add them to the tree though [12:20] jbowtie: if you can do better, please do [12:20] luckily these are just existing-file changes i'm concerned with [12:20] thanks for your help! [12:20] jbowtie, all documentation is linked from bazaar.canonical.com. There a few small about developing bzr inself in the bzr source tree. [12:20] jbowtie: part of documentation is auto-generated from online help (bzr help xxx) [12:21] back [12:22] xnox: I think that's where I'm getting confused. [12:23] I see 14 categories on the Documentation Table of Contents. [12:23] jbowtie, go there click documentation and that's the full maintained, canonical location for all documentation. [12:23] I see 8 categories in the bzr source tree. [12:23] So where are the other 6 categories sourced from? [12:24] jbowtie, from the doc-strings within the codebase inside bzrlib/ [12:24] in each command / function [12:24] jbowtie: are we talking about http://doc.bazaar.canonical.com/bzr.2.1/en/ ? [12:24] bialix: Yes. [12:25] jbowtie, well FAQ & BzrGlossary are just links to random pages online and are not real docs [12:25] If I want to correct something in both the "System Admin Guide" and the "Developer Docs", where do I go to edit that? [12:25] jbowtie: Core documentation coming from bzr sources [12:25] Related links from other places [12:26] jbowtie: core docs coming from bzr_tree/doc/end [12:26] jbowtie: core docs coming from bzr_tree/doc/en [12:26] sorry [12:26] jbowtie: Ooh! I thought there was a project, but I couldn't find it when I checked. [12:26] bialix: OK, so the "System Admin Guide" is in the bzr tree, since it's in the core section. [12:27] jbowtie: correct [12:27] doc/en/admin-guide [12:27] bialix: But how do I track down the 6 "Related Links" projects? Or are they not in Launchpad anywhere? [12:27] http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/files/head%3A/doc/en/ [12:28] jbowtie: look at the links [12:28] xnox & faceprint: 'bzr diff' doesn't show executable bit changes, so it might not include them in the exit code either... [12:28] jbowtie: Desktop Guide coming from Bazaar Explorer [12:28] FAQ is launchpad page [12:28] Glossary is wiki page [12:28] Developer Docs again from bzr tree [12:29] bialix: Wait, what? Where are the Developer Docs? [12:29] wanna screenshot? [12:30] here is http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/files/head%3A/doc/developers/ [12:30] * bialix is not sure where from coming migration and plugins guide [12:30] igc is our docs master, but he's offline this week [12:30] bialix: Well, that's somewhat more helpful. [12:31] you can send the question to the ML though [12:31] maybe jam knows [12:31] bialix: But of course the Plugins Guide was the one I had a big patch for since I just wrote a plugin. [12:31] (... or poolie) [12:32] bialix, bzr/doc/en/upgrade-guide$ for the migration guide [12:32] xnox: thx [12:33] jbowtie: here is plugin guide sources http://bazaar.launchpad.net/~bzr/bzr-alldocs/trunk/files/head%3A/plugins/en/ [12:33] xnox: That isn't right, the Survival Guide doesn't exist at all in that location. [12:33] 4 ./doc/en/user-guide/plugins.txt [12:33] 4 ./doc/en/user-guide/writing_a_plugin.txt [12:34] I guess other docs need to look in the alldocs first [12:34] My links are *from* the bzr tree [12:34] so which once are we still missing? [12:34] bialix: Umm. OK. So "alldocs" only has the Plugin Guide? [12:35] so far I have found everything in the tree [12:35] jbowtie, Plugin Guide is in the just *bzr* tree [12:35] xnox: is not true [12:35] xnox: http://bazaar.launchpad.net/%7Ebzr/bzr-alldocs/trunk/annotate/head%3A/plugins/en/plugin-development.txt [12:36] xnox: Part of the problem is that not all the docs are in the tree. [12:36] xnox: Otherwise I would be less confused. I hope. :) [12:36] xnox: There is some double-up of coverage. [12:36] jbowtie: will be nice if you collect this info on the wiki.bazaar.cacnonical.com, if you don't mind [12:37] bialix: Will do; am logging this and will update the wiki in the morning (very late night in my time zone). [12:38] jbowtie: cool, thanks [12:38] bialix: So if I track down the source for the "Migration Guide" - especially the "Survival Guide" subsection, we'll know where everything is. [12:38] * bialix nods [12:42] bialix, xnox: Thank you both very much, kept me from giving up on contributing documentation. [12:42] jbowtie, i've never seen Survival Guide ever before [12:42] WTF =) this needs fixed [12:42] xnox: You probably didn't need it. :P [12:44] All right, I'm off to bed, will update the wiki in the local morning hopefully to be followed by merge requests. [12:46] there is this page as well http://bazaar.launchpad.net/~ian-clatworthy/bzr-explorer-website/trunk/files/head:/en === mrevell is now known as mrevell-lunch === nlisgo_ is now known as nlisgo === mrevell-lunch is now known as mrevell [13:27]