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