[01:08] igc is explorer now in the mac packages? [01:08] re bug 483083 [01:08] Launchpad bug 483083 in bzr-mac-installers "No bzr-explorer in Mac desktop bundle 2.0.1" [Undecided,Confirmed] https://launchpad.net/bugs/483083 [01:09] mwh, spiv does python -O do anything aside from turn off assertions? [01:10] poolie: it makes __debug__ 0 [01:10] and anything else? [01:10] python -h says "optimize bytecode slightly" [01:11] i didn't think that was controlled by -O [01:12] this is re bug 147927 [01:12] Launchpad bug 147927 in bzr "use python -O (assertions off) when running installed copy" [Low,Confirmed] https://launchpad.net/bugs/147927 [01:14] poolie: what mwhudson says [01:15] I think the "optimize bytecode slightly" is alluding to omitting the bytecode of "if __debug__:" blocks. [01:17] so the bug's obsolete? [01:19] I think so, yes. [01:20] And we've sort-of replaced what that would do with the -D flags. [01:20] which are better i think [01:22] ok closed [01:28] If somebody could review https://code.edge.launchpad.net/~jelmer/bzr/branch-names/+merge/21197 that would be much appreciated, it's the next step for colocated branches. [01:36] it was on my list but it's a long list :) [01:36] so [01:36] it looks pretty good [01:37] i had some qualms about the earlier patches needing to insert 'name' into quite so many places [01:37] but it's not really your fault [01:37] i feel those classes could do with a scrub [01:37] do you want to talk about that patch or do you just want a +1? [01:38] poolie: I'm happy to talk about it [01:38] i mean, do you have any concerns? [01:38] it looks ok to me [01:38] poolie: Ideally I'd like a +1 but it'd also be good to know what you think of the general direction my patches are going in and what plans you have for that API in general. [01:39] i think it's good [01:39] i feel there's a lot of duplication in bzrdir.py [01:40] poolie: Yeah, there's quite a few places that have a name parameter. I'm not sure how we could best abstract that out though. [01:40] anyhow [01:40] i don't think we should block your stuff [01:41] if you get around to deleting a lot of code from bzrdir or branch.py it would make me happy :) [01:41] ok :-) [01:48] poolie: explorer is in the mac packages for Snow Leopard (10.6) but not earlier IIUIC [01:48] * igc out for a few hours [01:49] thanks [02:22] spiv: hi [02:24] spiv: https://bugs.launchpad.net/bzr/+bug/537888 <--- This link contains my patch to the doc. [02:24] Ubuntu bug 537888 in bzr "on documentation of stacked branches" [Medium,In progress] [02:26] poolie: should be able to review (properly, skim read looks fine) and get that in this arvo. [02:26] no rush [02:27] hello echo-area [02:27] poolie: hi [02:27] oops, i started a proposal for that but i didn't paste the link [02:32] spiv, want to read https://code.edge.launchpad.net/~mbp/bzr/doc-stacking/+merge/21694 [03:07] echo-area: will look, thanks! [03:52] Is there a way to force a revert even if it ends up in an error (file not versioned, ...) ? [03:53] Adys: what error are you getting? revert should always work I think. [03:53] adys@azura:~/src/bzr/xflight$ bzr revert *.txt [03:53] bzr: ERROR: Path(s) are not versioned: CMakeCache.txt [03:53] Oh, I see. [03:54] i dont see a --force option [03:55] revert thinks you're trying to revert a file it doesn't know anything about, but I guess what you actually want is for it to ignore the unversioned file(s) matched by *.txt and revert the rest? [03:57] I suppose you could do something like: bzr revert `bzr status -S -V *.txt | cut -b 5-` [03:57] But I don't think we have a builtin option for that, but it would be good to add. [04:03] Adys: I've filed https://bugs.edge.launchpad.net/bzr/+bug/541676 [04:03] Ubuntu bug 541676 in bzr "Add --ignore-unversioned option to revert" [Low,Confirmed] [04:03] cheers spiv [04:05] and ya its not a big deal to me, just thought it'd be something good to have builtin as well [05:37] back [07:30] Is there a way to return a list of files that have changed from revision x to the latest revision [07:34] And then to create a patch file between a specified version and the latest revision [07:35] well, the latter is easier [07:37] nlisgo: for the latter: bzr diff -r REV..-1 [07:38] nlisgo: (although you may find 'bzr send' to be better than generating plain diffs, depending on what you are doing) [07:39] nlisgo: for the former: bzr status -r REV..-1 [07:40] thanks very much spiv. I shall give them a go. [07:50] That worked fantastic spiv. Thanks very much! [07:50] what would the command be for send? [07:51] bzr send -o -r REV..-1 > patchfile [07:55] igc: ping (perhaps) [07:56] bzr send ./ -o ../myfile.patch -r REV..-1 [07:56] nlisgo: typical use of 'bzr send' is to tell it which branch you are 'sending' to [07:56] nlisgo: and then it works out exactly what info to include [07:58] * spiv is off for the day [07:58] G'night all! [07:58] spiv: night - thanks for help [07:58] nlisgo: no probs [08:43] hi all, oops forgot to do that hours ago [08:44] Is there some lovely LOSA around to have a look at pqm, it seems hung in an unusual way [08:44] i.e. the make has been done but the selftest step reported nothing for... ~1 hour [09:35] I have problems branching from an SVN repository. bzr keeps saying «bzr: ERROR: Not a branch: "/branches/src/gioele-api/XXX".». I successfully branched from other branches of the same SVN in the past. How can I debug this? [09:41] gioele: what does "bzr svn-layout" on that repository tell you? [09:43] jelmer: that I have to modify ~/.bazaar/subversion.conf ;) === quicksil1er is now known as quicksilver [09:50] hi jelmer, vila [09:50] thumper: pong [09:50] 'morning Ian, Vincent [09:50] * vila waves back === jpds_ is now known as jpds [09:55] hi guys [10:33] huh ? No more bzr_man.html created by 'make docs' ? What did I miss ? [10:38] wow, that was already lost in 2.1 [10:38] igc: does this ^ ring a bell ? [10:38] vila: I guess it was the part of what igc did for new documentation [10:38] hi bialix [10:39] do you really need an html? [10:39] hi igc [10:39] I need to test modifications to bzrlib/help_topics/en/configuration.txt [10:39] vila: I think the file is now called index.html [10:39] whre ? [10:39] under doc/en/user_reference [10:40] try it, no index.html there [10:40] vila: do you have sphinx installed? [10:41] I ran 'make docs' and got no complains, [10:41] I then installed sphinx, search the makefile, run make html-sphinx, still no sugar [10:41] make docs is the docutils stuff which is effectively dead [10:42] it ends up saying The HTML pages are in _build/html but there is no _build dir here [10:42] nm, let's start again [10:42] try doc/en/_build/html [10:42] I need to test modifications to bzrlib/help_topics/en/configuration.txt, what should I do ? [10:42] the _build directory is relative to the sphinx config file (in doc/en) [10:42] vila: bzr help conflicts? :-P [10:43] rats [10:43] typo [10:43] heh [10:43] vila: make html-sphinx is the right command [10:43] look in doc/en/_build/html for the results [10:43] igc: there are also quite a few warnings during make html-sphinx [10:44] vila: yes, I/we need to fix those [10:44] vila: the old docutils stuff has to go first [10:44] indeed [10:44] because many of the warnings are a consequence of trying to support do slightly different doc systems [10:45] where is configuration.txt output now then ? [10:45] s/do/two/ [10:46] under doc/en/_build/html/user-reference [10:46] vila: it will be called configuration-help.html [10:47] vila: the -html prefix is necessary to prevent namespace clashes with std sphinx docs (like search.html) [10:47] ENOTFOUND [10:48] vila: is anything in doc/en/_build? [10:48] doc/en/_build/html/user-reference/configuration-help.html finally [10:49] now, how do I know what kind of markup can be used ? [10:50] vila: good question :-) [10:50] vila: you can use any sphinx markup you like for nice html [10:50] vila: the trouble is nice text for command line users [10:51] :-/ Ok, nm, the table of contents answer my precise question here, I used the wrong underline char before, now it's indeed a subsection [10:51] so we tend to stick with plain text with some limited markup [10:51] i.e. [10:52] :: at the end of a line for introducing examples [10:52] :doc:`foo-help` for cross-references (get turned into `bzr help foo` in the text output [10:53] yeah, except I have some text to describe the example so using Examples:: doesn't work, I can use it for each example though [10:54] cough, sphinx always rebuild everything ? [10:54] vila: inside command docstrings, subsections like Examples can be introduced by using :Examples: and indenting text within that by a character [10:54] :text: what's that ? [10:54] rest ? sphinx ? [10:55] vila: have a look in builtins.py at cmd_log for example [10:55] :text: is a bzr-ism for marking subsections inside a docstring [10:55] I'm not inside a docstring [10:56] vila: it doesn't apply to a plain text file though [10:57] vila: here's the doc on sphinx: http://sphinx.pocoo.org/contents.html [10:57] ha good [10:58] thx [10:58] does it generate texinfo output ? [10:58] :-P [10:59] LaTeX files ! I feel younger by the minute :) [10:59] vila: :-) [11:00] vila: we generate our PDF manuals via LaTeX fwiw [11:00] if I "bzr push" an svn imported branch, will this create an svn commit for each bzr commit? [11:00] from latex files getting texinfo should be trivial (at least in theory, oooh, I love those theories :) [11:00] vila: however, we don't have a PDF verison on the User Reference because ... [11:01] keeping things working for docutils means that sphinx can't build the LaTeX [11:01] hence my keenness to drop support fro docutils [11:03] gioele: I believe so but jelmer will know for sure [11:03] gioele, for every commit in mainline, yes [11:03] jelmer: with which date? all with the current date and time? [11:03] got to go [11:03] night all [11:04] igc: thx for the help and last question: our official doc in the sphinx one now right ? At least for 2.2 ? [11:04] igc: it would be good to clarify things a bit here === mnepton is now known as mneptok [11:56] Hi, any bzr devs around for a couple of questions? I am working on backporting bzr to hardy and would like to clarify whether there are anything to be concerned about [11:59] mok0: there are hardy packages in the bzr PPA: https://edge.launchpad.net/~bzr/+archive/ppa?field.series_filter=hardy [12:00] spiv, I know [12:00] spiv: I'd like to hear to what extent they have been tested [12:00] AFAIK they work just fine. I don't know of any reports of problems. [12:00] spiv: any pitfalls we (backporting team) should be aware of? [12:01] The main issue we've had with packaging has tended to be making sure the plugins are all up to date with the version of bzr [12:01] spiv: OK, sounds good [12:01] Do you mean packaging issues or bzr issues? I run from source on Hardy and have had no issues. [12:02] Peng, I mean issues with the plugins. I also have no problems with bzr iteself [12:02] So bzr itself doesn't have very tough dependencies (just Python, basically), but if you upgrade bzr without upgrading plugins that tends to cause grief if you expect e.g. bzr-svn to work. [12:03] spiv: right. subvertpy is on it's way to the hardy backports archive as we speak [12:03] mok0: *nod* [12:04] spiv: When that becomes available, I can test bzr-svn etc. [12:04] mok0: packages that depend on bzr (mainly just plugins, although maybe also loggerhead?) is where I'd expect potential problems. So if you're aware of that then I think you know about as much as I do :) [12:05] spiv: I wasn't, thanks, [12:06] In terms of testing, we do occasionally hear people grumble when we break or not update the PPA, so I assume people are testing it. It'd be nice if LP could give some sort of stats that indicate usage though. [12:06] spiv: Indeed it would [12:06] (Easier said than done, I'm sure) [12:06] * spiv -> bed [12:06] Heh [12:06] mok0: good luck, and thanks for backporting :) [12:06] spiv: goodnight spiv, and thanks [12:07] My pleasure :-) [12:07] * mok0 < lunch === Chex_ is now known as chex [13:20] is there a way of installing bzr 1.18 on fedora 12? [13:25] bzr 1.18? Why? That's quite old. [13:26] i know, but a project i'm working on needs 1.18 to work properly [13:27] ...Why? [13:28] i don't know, i haven't worked on it myself yet [13:29] Bazaar is nearly completely backwards-compatible... [13:29] I suspect their need <2a format [13:30] andyjb23: I can suggest format1 plugin to force using old default format with bzr >= 2.x [13:30] what does that mean? [13:31] the main thing changed between 1.18 and 2.x is new default repository format, now called 2a [13:32] my plugin force to use old format named pack-0.92 instead [13:32] IIRC 1.18 supports 2a, though. It probably sucks a bit, but it works [13:32] you may ask your team about the reasons behind 1.18 [13:33] You don't need the plugin. It's just so that you don't have to remember to do "bzr init-repo --pack-0.92". Which is good. [13:33] Peng: if you have to support even older bzr clients, believe me you don't want to use 2a [13:35] also 2a is rich-root format. and therefore any unexpected format upgrade will give you big problems [13:37] so do i need this plugin or just to use --pack-0.92 every time i use bzr? [13:37] it's up to you [13:38] but both make it behave like bzr 1.18? [13:38] but you'd better to understand the reasons behind the choice of 1.18 only [13:38] andyjb23: not really [13:39] bialix: this is my first encounter with bzr, i'm just following instructions written by someone else on the project about a year ago [13:39] i will ask when he wakes up though [13:40] 1.18 was released about half year ago [13:40] one can't write such instructions 1 year ago [13:40] hold on, history says instructions are 5 months old, sorry [13:40] andyjb23: Please do ask him. It most likely isn't actually necessary to use an old version. [13:41] * bialix nods [13:41] thanks === mbarnett` is now known as mbarnett === beuno is now known as beuno-lunch === deryck is now known as deryck[lunch] === beuno-lunch is now known as beuno === deryck[lunch] is now known as deryck === salgado is now known as salgado-upgradin === radoe_ is now known as radoe === maxb_ is now known as maxb [18:44] is it possible to retroactively revert a revision? [18:44] eg, remove the revision (and its modifications) from the branch's history completely [18:45] uncommit [18:46] luke-jr: Not once that revision is public. [18:46] by which I mean, in someone else's repository. [18:46] If that revision is only on your disk, you could branch from the point before that revision... [18:46] then replay all of the history after that onto the branch. [18:46] and throw away your "tainted" branch. [18:47] NfNitLoop: can the replay part be automated sanely? [18:47] /easily [18:47] I *think* rebase might be able to do that? [18:47] hmm [18:47] I thought rebase was a git cmd [18:47] there's a bzr-rebase plugin. [18:47] ah [18:47] ok [18:47] I'm considering releasing some internal code, but I'd need to strip customer-specific changes ;) [18:48] the problem is... [18:48] not a good idea to publish customer credit card numbers and such :) [18:48] those branches would be divergent. [18:49] hmm [18:49] meaning you wouldn't be able to merge from that branch to your internal branch. [18:49] because "rebase" basically takes the commit message and the diffs and commits them as completely new (unrelated) revisions. [18:49] what if I do the branching inside Subversion using cherry-picking, and use bzr-svn to bridge with the real world? [18:49] so a merge across those branches would see them as needing lots of merging. [18:49] since Subversion supports cherry picking properly [18:50] Sure, that could work. === davidstrauss_ is now known as davidstrauss === salgado is now known as salgado-afk