[00:02] <Peng> mwhudson: Doesn't help for redirects.
[00:03] <mwhudson> Peng: but proxypassreverse does
[00:05] <awilkins> Should it really take over 6 minutes to branch the Launchpad repository from one local disk to another?
[00:05] <lifeless> 'maybe'
[00:06] <awilkins> It's throwing a lot of CPU at it when I think it would be relatively quick to just... copy the folder.
[00:06] <awilkins> Now, that's just lazy. But still.
[00:07] <lifeless> branch validates data
[00:07] <lifeless> we don't know if its e.g. removable or network or trusted or not
[00:07] <lifeless> if you just want to copy the folder, I suggest you copy the folder.
[00:07] <awilkins> It just seems a lot of CPU time for a repo of ~ 300MB
[00:08] <lifeless> do you have the C extensions?
[00:08] <awilkins> Should do, it's from the PPA
[00:09] <thrope> mwhudson: links from the landing page with the list of repos all have https, but links from within a served repo dont any more
[00:09] <mwhudson> thrope: links in directory listings are *really* relative
[00:09] <mwhudson> foo
[00:09] <Peng> ...But they still invoke HTTP redirects cuz they leave off the trailing/. :D
[00:10] <mwhudson> Peng: you can fix that if you like
[00:11] <Peng> Hmm.
[00:13] <Peng> Oh. It's totally trivial to fix. Doing so now. :D
[00:17] <mwhudson> thrope: try bzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/relative-links
[00:21] <thrope> mwhudson: great - it works! thanks a lot!
[00:21] <mwhudson> thrope: awesome
[00:21] <mwhudson> thrope: you'll need to use proxypassrequest to handle the redirects
[00:24] <thrope> you mean proxypassreverse? or something else (dont know what proxypassrequest is)
[00:25] <Peng> Darn, it's a little bit trickier to add trailing slashes to breadcrumbs, cuz you have to avoid making the root link to //.
[00:26] <mwhudson> thrope: i mean that yes, sorry
[00:26]  * mwhudson needs lunch
[00:26] <thrope> there are a few problems poking around
[00:26] <mwhudson> ah ok
[00:26] <thrope> view branch changes goes to nn_review/changes/14start_revid=14
[00:27]  * mwhudson can believe it
[00:27] <thrope> gives internal server error
[00:27] <thrope> but https stuff is ok
[00:27] <mwhudson> thrope: where is that?
[00:27] <thrope> and "view changes to this file" button leads to nn_review/changesfilter_file_id=nnreview.py-20091126142852-yobx026pq984w1a0-1 which gives not found
[00:28] <mwhudson> thrope: ah stupid mistake
[00:28] <thrope> sorry nn_review is my branch, from nn_review/files/13 i click the view branch changes button
[00:28] <thrope> it works with the ? in by hand
[00:28] <mwhudson> thrope: pull again?  you want r397
[00:28] <mwhudson> i forgot to put the ? in
[00:31] <thrope> ah breadcrumbs (I think thats what their) called at the top are still non https (root)/nn_review at top of changes page
[00:32] <thrope> funny thing mouse over is https but actual link is http
[00:33] <thrope> anyway thanks a lot - I have to head off now
[00:33] <thrope> happy thanksgiving to any us folks (normal day here!)
[00:37] <mwhudson> Peng: can you review/test https://code.edge.launchpad.net/~mwhudson/loggerhead/relative-links/+merge/15298 ?
[00:37]  * mwhudson lunches
[00:42] <Peng> mwhudson: I'll test it, at least.
[00:42] <Peng> mwhudson: I have been fortunate enough to avoid learning anything about URL handling. :)
[01:41] <Peng> lifeless: Check finished. 945 inconsistent parents, but nothing worse.
[01:41] <Peng> Only took 26.5 hours. Nice.
[01:41] <lifeless> Peng: cool. check with vila - he has history there - but I suspect 'reconcile' is in order.
[01:42] <fullermd> bzr's pretty impressive; *I* was never able to reconcile my parents' inconsistencies...
[01:42] <Peng> lifeless: How do you reconcile something on LP, though?
[01:43] <lifeless> Peng: pull, reconcile, sftp/hitchiker and nuke the repo; push
[01:44] <lifeless> Peng: this is for the candidate converted maria, right?
[01:44] <lifeless> or 'spmdo reconcile url'
[01:44] <lifeless> spm: ^ :)
[01:44] <Peng> Heh.
[01:44] <Peng> lifeless: Yeah, it's for Maria.
[01:45] <Peng> lifeless: How do you reconcile a stacked branch?
[01:45] <lifeless> Peng: same same
[01:45] <Peng> It'll automatically reconcile the stacked-on repos just fine?
[01:45] <lifeless> no
[01:46] <lifeless> it reconciles the stacking branch and repo only
[01:46] <Peng> Oh.
[01:46] <Peng> Well, that's still OK.
[01:46] <Peng> I don't know which repo the inconsistent parents are in, though. :\
[01:47] <lifeless> you did 'bzr check' locally though,right ?
[01:47] <Peng> Yeah.
[01:47] <lifeless> so they are local
[01:47] <lifeless>  :)
[01:48] <Peng> But I have copies of everything locally.
[01:48] <lifeless> check checks only the local repo/branch
[01:49] <lifeless> gotta eat
[01:50] <Peng> And, actually, I don't think I've added any revisions to my MySQL repo since I last checked it, and there weren't any inconsistent parents then...
[01:52] <Peng> lifeless: If it only checked the...1400 revisions in the stacked branch, why the heck did it take 26 hours?
[01:57] <Peng> I'm reconciling LP over ssh, just to see how awful it is.
[02:05] <lifeless> Peng: not branch, repo
[02:06] <Peng> s/stacked branch/stacked branch's repo/, then.
[02:06] <Peng> ...One reconcile died with a KeyError.
[02:07] <lifeless> Peng: check has issues ;P
[02:10] <Peng> When reconcile says it's repacking, does that mean it's done reconciling?
[02:10] <Peng> Or is that part of reconcilnig?
[02:12] <Peng> Now another reconcile has crashed with the same KeyError.
[02:15] <Peng> And there goes the last one.
[02:15] <Peng> Yeah, _that_ makes me confident about the integrity of my repo. :P
[02:18] <spm> 'spmdo reconcile url' rofl
[02:18] <Peng> Oh hi. :D
[02:20] <spm> hey Peng, so what's up - am trying to put 2+2 together from the backscroll?
[02:21] <Peng> spm: I'm just reconciling a branch or two (lp:~mnordhoff/maria/5.1-2a and lp:~mnordhoff/maria/5.2-2a), including the copies on LP.
[02:23] <Peng> But reconcile crashes now. :\
[02:24] <Peng> Ah. It's bug #441125.
[02:24] <spm> ew
[02:27] <poolie> where does this "20 characters message" come from?
[02:28] <Peng> Maybe I'll stop using stacking, locally and maybe even on LP.
[02:28] <lifeless> poolie: ?
[02:28] <Peng> lifeless: It's in one of the recent mailing list messages about emacs.
[02:28] <spm> hrm. oki, digested that bug report. So I'm guessing this is going to need me to fiddle with backups or some such?
[02:28] <lifeless> Peng: if you're pushing up a fresh mainline thats been converted, you won't want it stacked.
[02:29] <Peng> lifeless: I pushed up lp:~mnordhoff/mysql-server/mysql-5.1-2a non-stacked, and then have all of my other branches (including Maria) stacked on it.
[02:30] <Peng> spm: Well, originally the "spmdo" was just to run "reconcile" on the two branches on LP. Then it turns out reconciling them fails, so it's moot.
[02:30] <spm> Peng: ahhh. bummer. ok.
[02:31] <Peng> I hate stacking. :(
[04:15]  * igc lunch
[04:56] <poolie> spiv, around?
[04:56] <poolie> i have some python weirdness for you:
[04:57] <poolie> http://pastebin.ubuntu.com/329072/
[04:57]  * spiv looks
[04:57] <poolie> i think in 2.5 and up 'exitfunc' is not a real method anymore, and
[04:57] <poolie> probably logging is causing the compatability method aluded to in http://bugs.python.org/issue2356
[04:57] <poolie> to activate
[04:58] <poolie> and if i remove that, it breaks
[04:59] <spiv> poolie: hmm, the stdlib docs do say it might not be set
[04:59] <poolie> oh?
[04:59] <spiv> poolie: file:///usr/share/doc/python2.6/html/library/sys.html#sys.exitfunc
[05:00] <spiv> (And that it's been deprecated since 2.4, but we knew that already I think)
[05:00] <poolie> mm
[05:00] <poolie> ok, this is it
[05:00] <spiv> poolie: so I suppose the correct thing to do is actually "exitfunc = getattr(sys, 'exitfunc', None); if exitfunc is not None: exitfunc()"
[05:00] <poolie> or to run atexit._run_exitfuncs()
[05:01] <poolie> or we can just say that there is nothing like that
[05:01] <poolie> but the getattr is probably a safer change
[05:02] <spiv> Yeah, we're stuck with either a deprecated interface (sys.exitfunc), or an undocumented one (atexit._run_exitfuncs).
[05:03] <poolie> yay
[05:03] <poolie> when in doubt, prefer the smaller diff
[05:03] <poolie> the good thing about this is that this patch is avoiding loading at least one file (atexit)
[05:03] <spiv> Although the *implementation* of atexit is actually to install _run_exitfuncs as sys.exitfunc.
[05:03] <spiv> So in practice it's the same thing.
[05:03] <poolie> probably not enough to matter, buta  small chance you'd have to wait until the disk head got to it
[05:03] <spiv> But getattr avoids an import ;)
[05:03] <poolie> exactly
[05:05] <poolie> thanks
[05:17] <igc> poolie: didn't you put the explorer website into the list of automatically refreshed ones?
[05:17] <poolie> i thought i did
[05:17] <igc> poolie: I pushed a change there an hour ago
[05:17] <igc> and it's not appearing yet
[05:17]  * poolie checks
[05:18] <poolie> at the moment it only runs once per day
[05:18] <poolie> it can be more
[05:18] <poolie> but now that it does the sphinx generation it actually takes a fair amount of work to do all of them
[05:19] <poolie> so i turned it down
[05:25] <igc> poolie: once a day ought to be fine for the core docs. Maybe bzr-migration-docs and bzr-explorer-website could be hourly. They ought to be far more lightweight
[05:25] <igc> poolie: I maybe I just need a way to do it on demand
[05:26] <igc> s/I/or
[05:30] <poolie> i'll just make it hourly for now
[05:30] <poolie> it'll kick off soon
[05:31] <poolie> we should probably move it all into a role account that you can get at but i don't really want to do that right now
[05:38] <Rotaerk_> can bazaar handle having a branch of one repository nested inside a branch of another repo
[05:38] <Rotaerk_> I'm thinking that I'd like my dependencies handled that way
[05:39] <Rotaerk_> i.e. one repo per solution.  if the main project in solution A depends on the main project in solution B, I create a branch of solution B's repo inside a folder in the branche of solution A's repo
[05:40] <Rotaerk_> that way the version of B that A depends on can be updated whenever, and easily
[05:41] <spiv> Rotaerk_: I don't know precisely what you mean by "solution", and I suspect what you mean by "repository" isn't quite what bzr means, but I think the answer may still be yes.
[05:43] <spiv> Rotaerk_: if you have branch of one project at foo/, and a branch of another project at e.g. foo/libs/bar, then that's fine by bzr.
[05:43] <Rotaerk_> hmm okay sounds good, thanks
[05:43] <Rotaerk_> "solution" and "project" are part of the visual studio code organization model
[05:43] <spiv> Rotaerk_: bzr won't keep track of which version of libs/bar you happen to have in foo/, but it won't get confused or anything like that.
[05:44] <Rotaerk_> hmm
[05:44] <spiv> Rotaerk_: so you can do "bzr pull" or "bzr commit" etc inside foo/libs/bar, and the fact that it's inside foo/ will be irrelevant
[05:45] <spiv> And similarly you can pull, commit etc in foo/ without disturbing the branch in libs/bar
[05:46] <Rotaerk_> okay time to try it
[05:46] <spiv> Yeah, that's the best way to figure this out I think :)
[05:46] <Rotaerk_> just didn't want to screw up my current repo if bazaar would be confused by it
[05:48] <poolie> igc: how now?
[05:48] <igc> poolie: excellent. thanks!
[05:48] <igc> poolie: http://doc.bazaar-vcs.org/explorer/en/tutorials/open-source-dev-gnome.html
[05:54] <poolie> very nice!
[05:55] <poolie> igc, i wonder if not specifically mentioning emacs would be sound better?
[05:55] <poolie> after all we'd be willing to provide site policy for any hosting site
[05:55] <poolie> it would make it look more like you're using emacs & savannah just as an example
[05:56] <igc> poolie: I'm not sure I understand what you're saying
[05:56] <Rotaerk_> if i created a branch and want to get rid of it, can I just delete the folder it's in, or is there a command I need to use
[05:57] <igc> the doc is explicitly aimed at the Emacs developers
[05:57] <igc> but generalised to be useful to others
[05:57] <poolie> i'm saying the document seems to have some tension about whether it's specifically for emacs, or just using emacs as an example
[05:58] <Rotaerk_> hmm nm, I guess I can just delete it... since bzr has to scan to find branches, it must not actually track them
[05:58] <poolie> it's just an observation, not a big problem
[06:00] <igc> poolie: it's meant to be general with Emacs as an example ...
[06:00] <igc> but good enough to show Emacs developers the "right" way to get started
[06:01] <igc> poolie: should I take out the note re savannah push policy perhaps?
[06:01] <poolie> given what you just said i'd probably write it as something like this
[06:02] <poolie> "explorer knows about the right way to publish to different hosting sites, but at the moment not how to publish to Savannah where emacs branches are hosted.   (Patches or information on how it should work gratefully accepted.)  Therefore we have to manually tell it where to push this branch...."
[06:04] <igc> poolie: ok
[06:04] <Rotaerk_> hmm darn
[06:06] <Rotaerk_> given branch of repo A at aaa, and branch of repo B at bbb, if I create a branch of bbb at aaa/bbb, I can't do "bzr add bbb" from aaa
[06:07] <Rotaerk_> it remains unknown
[06:08] <Rotaerk_> was hoping that revisions of A could contain snapshots of branches of B
[06:18] <spiv> Rotaerk_: no, unfortunately.  We'd like to support something like that, but it hasn't gotten past the experimental stage yet.
[06:19] <Rotaerk_> hmm I wonder if git or mercurial can do that
[06:19] <spiv> Rotaerk_: that's what I was trying to say when I said "bzr won't keep track of which version of libs/bar you happen to have in foo/"
[06:19] <Rotaerk_> ah I see
[06:19] <Rotaerk_> is there any other way to go about what I'm wanting to do?
[06:20] <Rotaerk_> i.e. have particular revisions of A dependent on particular revisions of B
[06:21] <Rotaerk_> i think SVN can handle this using "externals"
[06:21] <Rotaerk_> though I've only heard about it
[06:22] <spiv> Rotaerk_: there are some plugins and add ons that might help
[06:22] <Rotaerk_> ah this is actually listed as a limitation on the bazaar site
[06:22] <spiv> Rotaerk_: http://bazaar-vcs.org/ScmProj is one, there was also a mailing list thread touching on this recently
[06:23] <spiv> Rotaerk_: it starts at https://lists.ubuntu.com/archives/bazaar/2009q4/064637.html
[06:25] <Rotaerk_> hmm thanks
[06:35] <igc> poolie: how does one get permission to upload to our +downloads page. Is it joining ~bzr?
[06:36] <poolie> i think so
[06:37] <poolie> showing the current transfer rate is geeky provicialism (according to sjt)?
[06:37] <igc> poolie: can we add the guys making mac packages into there then?
[06:37] <poolie> of course
[06:38] <poolie> um
[06:38] <poolie> if you just add them to that team they'll get a lot of mail
[06:38] <poolie> it may be better to work out what lp role controls access, and then make that a different group
[06:38] <poolie> it may not be possibly
[06:38] <poolie> possible*
[06:38] <poolie> it's probably better also to add them to bzr-core
[06:40] <igc> poolie: the PPA packaging guys are in bzr, not bzr-core. hmm
[06:41] <igc> downloads sounds similar to PPAs conceptually wrt permissions?
[06:45] <poolie> so
[06:45] <poolie> the ppa is an example of one thing that sends a fair amount of mail to its owners
[06:45] <poolie> i trust the guys doing packaging of course
[06:46] <poolie> i don't mind adding them to any group
[06:46] <poolie> perhaps the easiest thing is to just add them to ~bzr and then if that's not working, try something else
[06:57] <Rotaerk> meh, I only wanted to nest revisions of B within a revision of A so that I could setup a reference from project A to project B, but instead I'll just build B and copy B.dll into A
[07:38] <vila> hi all
[07:39] <Peng> Hi. :)
[07:42] <spm> hey vila!
[08:16] <bignose> ‘bzr branch lp:foo’ is agonizingly slow. what protocol is being used when I specify the scheme ‘lp:’?
[08:16] <Peng> bignose: If you've run "bzr launchpad-login", bzr+ssh. Otherwise, http.
[08:17] <bignose> I don't have a Launchpad account. can I easily make ‘lp:foo’ use ‘bzr+http’?
[08:17] <Peng> LP doesn't support bzr+http.
[08:17] <bignose> argl
[08:18] <bignose> why on earth not?
[08:18] <Peng> Probably cuz all of the LP developers use bzr+ssh, so it's not important to them. :P
[08:18] <lifeless> bignose: time
[08:18] <lifeless> Peng: no
[08:19] <lifeless> Peng: we want to. Needs TUITS
[08:19] <bignose> it's not simply a matter of upgrading the Bazaar instance on Launchpad?
[08:19] <Peng> lifeless: TUITS?
[08:19] <Peng> bignose: It's a matter of...setting it up.
[08:19] <bignose> Peng: specifically, round tuits.
[08:19] <lifeless> http://www.myrtlewoodgallery.com/get_a_round_tuit.htm
[08:19] <lifeless> Peng: ^
[08:20] <bignose> as in, “We haven't got a round tuit”.
[08:20] <lifeless> bignose: its a deployment/testing issue
[08:20] <Peng> Ohhhhhhh.
[08:21] <bignose> hmm, perhaps there is something in Stephen J Turnbull's somplaints about the degree of difficulty in setting up a Bazaar server.
[08:21] <lifeless> Peng: a better one - http://www.stosyth.gov.uk/default.asp?calltype=sep03roundtuti
[08:22] <lifeless> bignose: its about 5 lines of apache config
[08:22] <lifeless> bignose: but we have loggerhead, which is fragile at scale, and we really don't want to destabilise that
[08:22] <lifeless> and they have to coexist on the same space.
[08:23] <bignose> okay. well, I can only agree with Stephen that it's a black eye for Bazaar when one's first likely interaction — branching an existing project— is dreadfully slow by default.
[08:24]  * igc dinner
[08:24] <lifeless> bignose: setting up is in fact documented - 'running an http smart server'
[08:25] <AfC> I can't agree. Setting up a bzr:// server was easy.s
[08:26] <bignose> right, but that doesn't affect that Launchpad doesn't have it enabled, which immediately raises the question of why it's difficult for the experts to do. (and most people asking that question are likely to come to the “because it's too difficult” conclusion)
[08:26] <lifeless> bzr+http is a little more fiddly, but not much.
[08:26] <bignose> um. what protocol does ‘bzr://’ run over? is it different from ‘bzr+http://’, ‘bzr+ssh://’?
[08:27] <bignose> it seems to me the read-only one is the important one for PR.
[08:27] <AfC> bignose: it runs over the bzr protocol
[08:27] <lifeless> omg the doc search is slow
[08:28] <Peng> bignose: bzr:// servers listen directly on TCP port 4155; they aren't tunnelled over SSH or HTTP or anything.
[08:28] <bignose> oh okay. well, that raises the question: if *that*'s the easy one to set up, why doesn't read-only ‘lp:foo’ use that protocol by default instead of slow ‘http://’?
[08:28] <lifeless> bignose: because lp isn't a typical deployment.
[08:29] <lifeless> theres a db with virtual filesystem and 'stuff'
[08:29] <lifeless> as well as private branches to consider
[08:29] <AfC> lifeless: (which is a shame, because otherwise it would promote bzr:// quite well)
[08:29] <bignose> but it's the most public one. “let's see how Bazaar performs over the network” is highly likely to lead to branching a project from Launchpad without an account there.
[08:29] <lifeless> http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/http_smart_server.html documents how to run a bzr+http setup
[08:30] <lifeless> running bzr:// from inetd is ridiculously simple for straight forward environments (and savannah is AFAIK - its no where near as complicated a setup as LP's production environment)
[08:30] <bignose> and hence branching from ‘lp:foo’, which leads to HTTP without specifically asking for it, which leads one to think that Launchpad and/or Bazaar are very slow over the network.
[08:31]  * fullermd still vaguely wishes he could setup bzr+http on a non-trivial setup...
[08:32] <lifeless> bignose: as I said, we want to do it. the team that is responsible also has a bunch of other things to do.
[08:32] <bignose> so I think this ties directly into Stephen's observations about PR and what Bazaar (and Launchpad, and Canonical, etc.) can do to improve image: get the most obvious Bazaar site working very fast by default.
[08:32] <lifeless> is it hard? not any harder than the other bugs they are working on. But they haven't gotten to it.
[08:34] <bignose> naturally. so perhaps, since Ian has published a guide, in response to Emacs developers needing to learn more about Bazaar, and specifically using Launchpad as a demonstration ... now is a good time to raise the priority of setting up a fast protocol by default for ‘lp:foo’ branch URLs.
[08:34] <bignose> to forestall a whole lot of Emacs developers, who might have otherwise been on the fence, having an abysmal first experience with Launchpad.
[08:35] <lifeless> I think that you should make this observation on the list.
[08:35] <bignose> okay, shall do.
[08:35] <lifeless> THe folk that need to see it are out drinking beer at the moment. ;)
[08:53] <bignose> lifeless: done, thanks.
[09:01] <bialix> hello
[09:02]  * fullermd waves at bialix.
[09:02]  * bialix waves back
[09:02] <bialix> hi fullermd :-)
[09:10] <Torty> hello
[09:10] <Peng> Hi.
[09:17] <stanman246> hi, not a bzr question, but i guessed i'll drop it anyway... Anyone using Krusader for filetransfers?
[09:20] <Torty> i have a question: it is possible to include the current Rev.number into my source files?
[09:21] <Torty> i.e. in sourcefile "###bzr-rev###" and bzr replace this with the current Rev. number?
[09:21] <Torty> i know in CVS/SVN it its possible
[09:22] <Torty> i think this replacement should be done by commit command
[09:23] <Torty> because only the currently commited files should be became the new rev.number
[09:23] <Torty> any idea?
[09:24] <Peng> Torty: Generally you make your build system do "bzr revision-info >version.txt" or somesuch.
[09:24] <Peng> Torty: But there is the bzr-keyword plugin if you want it.
[09:24] <Peng> Or is it "bzr-keywords"? I don't remember.
[09:28] <Torty> i think i dont know what you mean (advice: write simple english *g*)
[09:28] <Peng> Torty: The usual practice is to make your build system do it, using a command such as "bzr revision-info".
[09:29] <Peng> Torty: But there is a plugin that does what you want. See http://bazaar-vcs.org/KeywordExpansion
[09:29] <Torty> ok i read
[09:30] <Torty> ok it seems to be what i searching :-D thx
[09:30] <Peng> Torty: That page looks a little out-of-date. It might be better to start at https://launchpad.net/bzr-keywords
[09:30] <Torty> k
[09:36] <fullermd> The plugin functions more like PoC than usable code, for various reasons.  Some of the changes needed to really use it are only in 2.1, and I'm pretty sure some aren't anywhere yet.
[09:41] <Peng> Ah.
[09:42]  * vila cries, testtools doesn't support python2.4 (it requires functools) :-( <- lifeless
[09:43] <lifeless> vila: https://code.edge.launchpad.net/~lifeless/testtools/2.4
[09:43] <jml> has bzr's auto-resolve behaviour changed recently?
[09:43] <lifeless> jml: I don't think so
[09:43] <jml> vila, lifeless: actually: lp:testtools
[09:43] <lifeless> vila: but you probably want that branch + my 0.9.1 branch.
[09:44] <jml> ungh
[09:44] <jml> Using '=' to underline things confuses the auto-resolver.
[09:45] <lifeless> jml: oh yeah, sorry.
[09:45] <lifeless> use ---- perhaos
[09:45] <jml> problem for another day, I think.
[09:45] <lifeless> or ++++ actually, that shouldn't be used there and should be unique
[09:45]  * vila sends love to lifeless, jml and checks
[09:48] <fullermd> vila: By the by, 8.0 final release was finally cut.
[09:48] <vila> fullermd: Great, thanks for telling me, I'll upgrade asap
[09:50] <vila> jml, lifeless: lp:testtools still has the problem, trying 2.4 + 0.9.1 branches now
[09:51] <jml> vila, oops. pushed to wrong location
[09:51]  * vila jumps on the brake pedal
[09:52] <jml> vila, lp:testtools should have 2.4 now
[09:52]  * vila laughs at the commit message and wishes all commit messages were like that :)
[09:53]  * vila confirms --parallel=fork works again with 2.4  \o/
[09:54] <vila> 11 mins between tears and joy, who said bzr was slow ?
[09:55] <vila> yes, I know, that's a totally unfair reasoning :-D
[09:55] <fullermd> Man, that's pathetic.  CVS can go from joy to tears in SECONDS.
[09:57] <lifeless> jml: push 0.9. to trunk ? :)
[09:57] <jml> no, not now
[09:57] <lifeless> no?
[09:58] <jml> lifeless, I was writing the release announcement and uploading the tarball. Now I can do the branch bit :)
[09:59] <lifeless> jml: I would just push 0.9 to trunk again, is aall I meant
[09:59] <jml> lifeless, rather than merge?
[10:01] <lifeless> yes
[10:01] <lifeless> we haven't landed anything on trunk that we haven't also landed in 0.9
[10:02] <lifeless> if we had it would be different. Just a thought.
[10:02] <lifeless> I don't intrinsically care.
[10:04] <jml> done.
[10:04] <jml> that's a release, I think.
[10:05] <jml> crap. PyPI
[10:06] <lifeless> :)
[10:06] <jml> and setup.py
[10:06] <jml> dammit, I can't believe I need a release checklist for such a small project.
[10:07] <lifeless> you always need a checklist.
[10:07] <lifeless> write a tool.
[10:08] <fullermd> Sometimes I hate the day I internalized 'write a tool'...
[10:08] <lifeless> -> fud
[10:10] <bialix> vila?
[10:10] <bialix> lifeless: what;s tool?
[10:10] <vila> bialix: ?
[10:11] <bialix> vila: hello
[10:11] <bialix> what I should write in authentication.conf if I want to specify details for bzr+ssh
[10:11] <vila> bialix: hello :)
[10:11] <bialix> scheme = bzr+shh
[10:11] <bialix> ?
[10:11] <bialix> or just ssh?
[10:11] <vila> no, scheme = ssh, that's valid for both bzr+ssh and sftp since that's really the same scheme
[10:12] <bialix> oops
[10:12] <bialix> nice
[10:12] <bialix> vila: thanks very much
[10:12]  * vila thinks the problem has been raised already and a warning is emitted ?
[10:12] <Torty> Peng: i've installed new bzr and the plugin but i have problems to understand what i have now to do
[10:12] <vila> Or am I just dreaming that I wrote the fix ?
[10:12] <Torty> i mean the keywords-plugin
[10:13] <Torty> on Launchpad the documentation is missing
[10:13] <bialix> vila: works perfectly!
[10:14] <vila> cool
[10:14] <Peng> Torty: Did you see above what fullermd said about the bzr-keywords plugin?
[10:14] <Torty> on launchpad?
[10:14] <jml> lifeless, I'll write a tool after I have a checklist, probably.
[10:15] <jml> lifeless, anyway, release done.
[10:16] <Torty> ah - fullermd here on irc - no - i have to reboot my system
[10:16] <Torty> no chat-log active
[10:16] <Torty> can you paste me what he said
[10:16] <Peng> Torty: 09:36:46 < fullermd> The plugin functions more like PoC than usable code, for various reasons.  Some of the changes needed to really use it are only in 2.1, and I'm pretty sure some aren't anywhere yet.
[10:17] <Torty> thx - mom i try to translate ...
[10:18] <Peng> Torty: Short version: it's still experimental and doesn't work completely.
[10:18] <Torty> this means the plugin ist useable up from 2.1 version of bzr?
[10:19] <Torty> aha - but in future this replace-feature (bzr-keywords) will be working
[10:19] <fullermd> With versions before pretty recent dev head, the keywords won't update all the time when you perform bzr operations.
[10:19] <Torty> aha
[10:19] <fullermd> And with any version I know of actually existing, filtering in general can only be configured globally, so you can't turn them on in a single branch.
[10:19] <Torty> but the feature will be finialize in newer versions
[10:19] <Torty> good to know
[10:21] <Torty> what means also: if i want rev.# in my sources i have to do it by hand
[10:21] <Torty> or (bedder) dont include it in source files
[10:22] <Torty> ok thx - i wish you a nice weekend
[10:22] <Torty> bb
[10:56] <vila> fullermd: And people still don't believe that computers have feelings.... The freeBSD8 VM just crashed...And it runs from a different host than the one I use to do IRC....
[11:07] <fullermd> vila: 's what you get for running emacs on it   :p
[11:12] <vila> fullermd: pfff, not even, it was running unattended :)
[11:14] <vila> fullermd: more seriously, since it crashed, I may as well upgrade now, http://wiki.freebsd.org/8.0TODO is out of date ?
[11:15] <fullermd> Dunno.  The last edit date is, what, a week and a half back, or something?
[11:15] <fullermd> Not sure how actively it was maintained during the RC cycle.
[11:16] <vila> fullermd: it's ok, just found http://www.freebsd.org/releases/8.0R/announce.html
[11:16]  * fullermd glances at how recently the version control page was updated as long as he's bouncing around the wiki...
[11:16] <vila> hey ! vbox guest support !
[11:17] <vila> of course, just when I wanted to start migrating to kvm...
[11:17]  * fullermd . o O ( Last real update: 2008-01-19 )
[11:17] <fullermd> Well.  That's almost certainly not much changed since the last few RC's   :p
[11:18] <vila> .. may be, but it may also mean I need some tweaks I'm not aware of...
[11:19] <fullermd> I guess the topic fizzled out of major notice after src moved CVS -> SVN.  Owell.
[11:40] <drmabuse_> Hello! Anyone an idea how stacked branches differ from others (regular ones)?
[11:43] <Peng> drmabuse_: Stacked branches don't store all of the revisions locally.
[11:43] <Peng> drmabuse_: They should function exactly the same as a normal branch, more or less.
[11:43] <GaryvdM> drmabuse_: A stacked branch does not have all the revsions in it's repository. It has a url to the branch that it is stacked on, and if bzr needs any revisions that are not in it's repository, it gets them from the stacked on branch.
[11:44] <Peng> GaryvdM++
[11:44] <Peng> You put it very well. :)
[11:44] <drmabuse_> Ah, thank you!
[11:44] <GaryvdM> Peng: thanks
[11:44] <drmabuse_> Great!
[11:44]  * fullermd blinks.
[11:45] <fullermd> The heck...   how did I get a modified file in my bzr.dev tree...
[11:47] <fullermd> OK, what the hell?  log $FILE is showing 1 rev touching the file, log -n0 $FILE is showing 2, and there's no overlap between them.
[11:48] <fullermd> And none are actually direct edits, they're all merges.
[11:49] <fullermd> ...  OK, that's even weirder.  I revert it, and it STILL shows modified.
[11:50] <Peng> Kill dirstate?
[11:50] <Peng> (well, mv)
[11:50] <vila> what file is that ?
[11:50] <fullermd> Oh, I found it.
[11:50] <fullermd> Just snows to go you the sad state of content filtering.
[11:50] <fullermd> I still had a ~/.bazaar/rules file turning on keywords on *.txt, and doc/ja/user-reference/index.txt had something that ate.
[11:51] <Peng> \o/
[11:51] <fullermd> Of course, on the plus side, that does show that revert Does The [Hypothetically] Right Thing with filters now   :p
[11:51] <fullermd> Insofar as deleting 372 lines of the file is Right, anyway...
[11:53] <fullermd> Mmph.  And it compresses things that aren't valid keywords either.
[11:54] <fullermd> Still freaky what log is doing there, though.
[12:03] <GaryvdM> fullermd: What file is it?
[12:04] <GaryvdM> Oh nvm - doc/ja/user-reference/index.txt
[12:10] <GaryvdM> fullermd: bzr log doc/ja/user-reference/index.txt , and bzr log doc/ja/user-reference/index.txt -n0 work as expected for me.   ?
[12:12] <fullermd> Well, now that I've updated bzr.dev, both show only 1 rev.  Just different 1 revs.
[12:12] <fullermd> And still both just merges.
[12:14] <GaryvdM> fullermd: bzr log doc/ja/user-reference/index.txt -n0 shows me 4 revisions - http://pastebin.com/d100bf598
[12:15] <GaryvdM> fullermd: bzr qlog doc/ja/user-reference/index.txt also the same
[12:17] <fullermd> Hm.
[12:17] <fullermd> How odd.  I get that too, without -v.  But with -v, kaplooie.
[12:17] <fullermd> That's pretty marfed up.  Why the hell should -v affect ANYTHING like that?
[12:19] <GaryvdM> fullermd: yhea - thats def a bug IMHO
[12:21] <GaryvdM> Hi vila
[12:22] <GaryvdM> vila: Is there a way do detect if some code is being run from a test?
[12:22] <vila> meh, where should I put the comma ?
[12:23] <GaryvdM> I don't know?
[12:24] <vila> GaryvdM: :-) Is it: 'some code is, being run from a test' or 'some code is being run, from a test'
[12:24] <GaryvdM> vila: I got a test where a exception is being caught by qbzr error reported, which shows a nice gui error report, and the error does not get to the test.
[12:25] <GaryvdM> vila: so I want to disable qbzr's error handler if it is being run from a test.
[12:25] <vila> haaa, you want the code to realize it's run by the test ?
[12:26] <GaryvdM> yes
[12:26] <vila> Don't ever do that or the code police will come to arrest you
[12:26] <GaryvdM> lol
[12:26] <vila> Instead, the test should alter the environment
[12:26] <fullermd> Nah, as long as they check with log -v, they'll never find it being introduced  :p
[12:27] <vila> The former is known as 'test code in production code' and very frowned upon :)
[12:27] <GaryvdM> vila: ok
[12:27] <vila> the reason being that it's cheating really :)
[12:28] <vila> log -v can find more revisions touching a file :-/ I don;t remember the details but I think it has to do mainly with file deletions
[12:28] <fullermd> No, it finds less.  Much less.
[12:28] <fullermd> Or rather, it finds more, but gives up really quick.
[12:28]  * vila bangs head to wall
[12:29] <vila> err
[12:29] <vila> that's pretty unclear my dear friend :)
[12:29] <GaryvdM> fullermd: vlia is right, normal log file won't find a revisions that deletes a file
[12:29] <GaryvdM> -v will
[12:29] <GaryvdM> vila: compaire bzr log doc/ja/user-reference/index.txt -n0  to bzr log doc/ja/user-reference/index.txt -n0 -v
[12:30] <vila> fullermd: but log and log -v are on amanica plate again IIUC
[12:30] <vila> so filing bugs now may be a good idea
[12:32] <vila> GaryvdM: aaargh, vade retro satanas, I want to go have lunch, don't make me vomit :-(
[12:32] <GaryvdM> sorry
[12:32] <vila> that's pretty ugly :(
[12:33] <vila> err, can I really use pretty and ugly like that ?
[12:35] <vila> bbl, will have lunch anyway
[12:51] <GaryvdM> vila/fullermd: I've loged bug 489179
[12:56] <GaryvdM> vila: when you are back from lunch, would this be an acpetable way to "alter the environment" : http://pastebin.com/d75e9a627 ?
[13:22] <vila> GaryvdM: with the tweaks http://pastebin.com/m285da0a9 , yes
[13:22] <lifeless> vila: would like your feedback on assertThat (in testtools 0.9.1)
[13:23] <GaryvdM> vila: thanks
[13:23] <vila> and regarding that bug, log -v shows *only* the revisions touching the file, while log, once it found a revision, also displays the ones that merge it (I forgot that case earlier),
[13:24] <vila> so the bug is presumably about the "right" revision being lost while the merging ones are shown, because 4792.5.5 really add the file and I presume nobody ever touch it since
[13:24] <vila> lifeless: is that about the matchers I saw mentioned in the commit messages ?
[13:24] <lifeless> yes
[13:24] <lifeless> see NEWS and the MANUAL
[13:26] <thrope> is it possible to share subversion.conf between machines - to the checksums int here come from the svn repository or are they randomly generated (ie does it make any sense) - I guess I was hoping if I accessed the same repo on another machine the checksum would be the same
[13:32] <vila> lifeless: after reading NEWS and MANUAL, I'm still hungry :-) Now reading matchers.py
[13:33] <vila> that was quick :)
[13:33] <vila> I recognize that DocTestMatches as very closely resembling my needs in shell-like tests :)
[13:34] <lifeless> if you want to see it in use, look at test_testresult.py
[13:35] <vila> yeah, I see that... making doctest.ELLIPSIS the default sounds sensible... (I did that in the shell-like tests)
[13:36] <lifeless> vila: I haven't read the shell like stuff yet
[13:36] <lifeless> vila: did you use the doctest module?
[13:36] <vila> great minds etc
[13:36] <vila> yes I did use it
[13:37] <vila> so, the problem I have with assertThat is that the actual value comes first
[13:37] <lifeless> read it as an english sentence
[13:37] <vila> yeah, I know, that's the good part
[13:37] <lifeless> assert that foo doctestmatches thing
[13:37] <lifeless> its a bit cutey
[13:38] <lifeless> but otoh fairly memorable
[13:38] <vila> but then when I look at the tests, I stop "reading" and go into some matching mode
[13:38] <lifeless> I think you would adapt quite quickly - bzr already has inconsistency here
[13:38] <lifeless> the needle, haystack thin
[13:38] <lifeless> g
[13:39] <vila> hehe, you used the right words, I can adapt but inconsistencies make adaptation hard in the end
[13:40] <lifeless> I think its better to make this really nice
[13:40] <vila> anyway, as long as switching the args is invalid, it can hardly become a problem right ?
[13:40] <lifeless> so we can effectively argue for
[13:40] <lifeless> assertThat(thing, equals(other))
[13:40] <lifeless> yeah, it will blow up, unless thing is a matcher too :)
[13:41] <vila> hehe, when you start writing tests about matchers, I suspect the parameter order is already wired ;)
[13:42] <vila> assertThat(thing, equals(other)).... really nice
[13:42] <lifeless> doing not may require some care
[13:42] <lifeless> assertThat(thing, is(not(other))) would be nice to be able to write.
[13:43] <lifeless> but 'is(not(' really would be 'not(is(' in this language. which isn't english (though it is other languages))
[13:44] <vila> on the feedback front, reading MANUAL was... refreshing, there nothing I want to delete there
[13:44] <vila> Isn't there an english construct for assertThatNot ?
[13:45] <vila> failIf >
[13:45] <vila> failIf ?
[13:45] <lifeless> in english, 'the horse *is* *not* red'
[13:45] <lifeless> in this language, 'the horse *not* *is* red'
[13:45] <lifeless> vila: think bigger, more complex composed matchers
[13:45] <lifeless> gnight
[13:46] <lifeless> play. Use. Enjoy.
[13:46] <vila> :)
[13:46] <lifeless> was addDetails in the MANUAL?
[13:46] <lifeless> I forget if I added it there
[13:46] <vila> no
[13:46] <lifeless> if so - bzr log files. failed test work areas from disk. Possibilities abound.
[13:47] <lifeless> ok, I should add that. Please file a medium priority bug on testtools if you would
[13:47] <lifeless> its referenced from NEWS, I'm sure.
[13:47] <lifeless> ciao
[15:03] <jldupont> hi - I keep getting "Unexpected error while decorating: xxx.yyy" when using Bazaar Plugin for Eclipse... any clue?
[15:03] <beuno> jldupont, verterok is the developer for that plugin, maybe he will know
[15:04] <jldupont> verterok: I keep getting "Unexpected error while decorating: xxx.yyy" when using Bazaar Plugin for Eclipse... any clue?
[15:05] <verterok> jldupont: could you check the stacktrace in <workspace>/.metadata/.log ?
[15:06] <verterok> jldupont: also, what options do you have enabled in the decorator settings?
[15:06] <jldupont> verterok: http://jldupont.pastebin.com/d5663d1bf
[15:07] <jldupont> verterok:  I don't believe I have ever touched this... the only option checked at the moment is "Enable Status Overlay Decorator"
[15:07] <verterok> jldupont: ok, what version of bzr-xmloutput do you have installed?
[15:08] <verterok> jldupont: bzr plugins should show that
[15:09] <jldupont> verterok: how do I check that?  Windows->preferences->Bazaar??
[15:09] <verterok> jldupont: in a terminal: bzr plugins
[15:09] <jldupont> ok
[15:09] <jldupont> 0.8.3
[15:10] <verterok> jldupont: hmm, it's quite old, are you in windows or *nix?
[15:10] <jldupont> ubuntu
[15:10] <jldupont> is there a PPA for auto-update of that stuff?
[15:10] <verterok> jldupont: is the bzr-xmloutput  from the repository?
[15:11] <jldupont> hmmm... don't remember where I got that...
[15:11] <verterok> jldupont: "bzr plugins -v" should show the path
[15:11] <jldupont> what's the best way to install & keep up-to-date on this plugin?
[15:11] <jldupont> /usr/lib/python2.6/dist-packages/bzrlib/plugins/xmloutput
[15:12] <verterok> jldupont: ok, it's the package
[15:12] <jldupont> xmloutput 0.8.3
[15:12] <jldupont>     This plugin provides xml output for status, log, annotate, missing, info,
[15:12] <jldupont>     /usr/lib/python2.6/dist-packages/bzrlib/plugins/xmloutput
[15:13] <verterok> jldupont: try this: 1) uninstall bzr-xmloutput 2) mkdir -p ~/.bazaar/plugins; bzr branch lp:bzr-xmloutput ~/.bazaar/plugins/xmloutput
[15:14] <maxb> Semi-related, I have heard there are two Eclipse plugins for Bazaar, which one should I use?
[15:16] <verterok> maxb: qbzr-eclipse use qbzr for the dialogs, bzr-eclipse is a native plugin (pure java+SWT, except the interface with bzr)
[15:16] <jldupont> " bzr: ERROR: Target directory "/home/jldupont/.bazaar/plugins/xmloutput" already exists.  "
[15:17] <verterok> jldupont: so you already have it: cd ~/.bazaar/plugins/xmloutput && bzr pull
[15:18] <jldupont> it blew in my face:  http://jldupont.pastebin.com/d2f611ae9
[15:20] <verterok> jldupont: oh, you have bzr 1.13.1 and bzr-xmloutput is using a newer repository format :(
[15:21] <jldupont> where is the PPA for Bazaar again?
[15:22] <jldupont> is this it: https://launchpad.net/bazaar
[15:22] <verterok> jldupont: https://edge.launchpad.net/~bzr/+archive/ppa
[15:23] <jldupont> verterok: ok, thanks!
[15:26] <jldupont> hmmm... I've added the PPA to my sources but Synaptic doesn't show an upgrade to bzr...
[15:26] <jldupont> what's wrong?
[15:26] <jldupont> it concludes that 1.13.1 is latest.
[15:27] <jldupont> maybe it is taking the "ubuntu" default?
[15:28] <vila> jldupont: most probably you missed some step while adding the PPA ? You did add the key for it ?
[15:29] <jldupont> Yes I did add the key.
[15:29] <jldupont> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8c6ce1efd
[15:29] <vila> hmm, you refreshed the package list ?
[15:29] <jldupont> "reload" in Synaptic.
[15:29] <jldupont> yes
[15:29] <vila> ghaa
[15:30] <vila> let me start my hardy vm
[15:31] <jldupont> I went for apt-get update
[15:31] <jldupont> and back to Synaptic:  1.13.1
[15:32] <vila> 1.13.1-1 (hardy) or 1.13.1-1ubuntu0.1 (hardy-updates) ?
[15:33] <vila> boom
[15:34] <jldupont> vila: I must be Synaptic having the problem:  I do sudo apt-get install bzr  and I got upgraded....
[15:34] <jldupont> jldupont: vila: I must be Synaptic having the problem:  I do sudo apt-get install bzr  and I got upgraded....
[15:35] <jldupont> ... and now it shows up in Synaptic !\\
[15:35] <jldupont> not the first time I've had problems with Synaptic !
[15:36] <jldupont> note to self:  go with apt-get  if problem with Synpatic *before* bugging people.
[15:36] <jldupont> THANKS GUYS!
[15:38] <jldupont> ... and now Bazaar Eclipse plugin complains that bzr-xmloutput isn't found!!!
[15:38] <vila> weird
[15:38] <vila> jldupont: you're welcome
[15:38] <jldupont> what is the approved process for installing bzr-xmloutput ??
[15:39] <jldupont> it shows in Synaptic!
[15:40] <jldupont> ... and now "mark for reinstallation" in Synaptic takes care of the problem...
[15:40] <jldupont> let's just say I do not love Synaptic that much ...
[15:42] <jldupont> I still get a ton of "decorator" errors: http://jldupont.pastebin.com/m4b23cbe2
[15:42]  * vila leaves it to verterok :)
[15:42] <verterok> heh
[15:43] <verterok> jldupont: did you restarted bzr-eclipse?
[15:45] <jldupont> ... just did ( you can of course flame me good ! ) ... but now a new problem: http://jldupont.pastebin.com/d2d1e7b81
[15:48] <verterok> jldupont: could paste the whole traceback? or is just that?
[15:48] <jldupont> it was only that when I posted it... now, I tried doing a commit:  http://jldupont.pastebin.com/d4d5fb3c9
[15:49] <verterok> jldupont: looks like bzr-gtk is killing bzr
[15:50] <jldupont> what's the solution?
[15:50] <verterok> jldupont: removing bzr-gtk...maybe?
[15:50] <jldupont> get rid of it?  I just need eclipse pluing and cli
[15:50] <verterok> vila: do you know what's the status of bzr-gtk?
[15:51] <verterok> jldupont: yes, I think that removing/uninstalling bzr-gtk is enough
[15:51] <verterok> jldupont: or updating it
[15:52] <vila> verterok: what status ?
[15:53] <jldupont> got right of it... still blows up in my face!
[15:53] <vila> oh, hum, bzr-rebase seems to be a problem
[15:53] <jldupont> http://jldupont.pastebin.com/d3af2792e
[15:53] <vila> bzr-gtk should be upgraded from the PPA I think
[15:53] <jldupont> bzr-rebase: got rid of it too.
[15:54] <jldupont> http://i49.tinypic.com/x2lxmp.png
[15:55] <verterok> jldupont: you still have an old xmloutput installed
[15:55] <jldupont> maybe my repo of the old version is causing the trouble?
[15:57] <jldupont> xmloutput: 0.8.3
[15:57] <vila> \what PPA did you add exactly ?
[15:57] <jldupont> edgewall one
[15:57] <jldupont> https://edge.launchpad.net/~bzr/+archive/ppa
[15:57] <jldupont> jaunty
[15:58] <jldupont> /usr/lib/python2.6/dist-packages/bzrlib/plugins/xmloutput
[15:59] <vila> jaunty ??? 1.13.1 is the latest proposed in jaunty by default ???
[15:59] <MvG> Again I'm asking for someone to review changes to trac-bzr. This time https://code.launchpad.net/~gagern/trac-bzr/bug194277/+merge/15323 in particular, as it removes quite a large portion of (supposedly unused) code. I'd love a second opinion here!
[16:00] <vila> MvG: I know nothing about trac-bzr, but given the work your putting into it, you clearly seem to be the de-facto maintainer...
[16:00] <jldupont> vila: yes it seems.
[16:00] <MvG> And become so in little more than a week, or so it seems.
[16:00] <MvG> I feel like every time I fix a bug, I find a new one.
[16:00] <vila> as such, you'd better just take over the trunk and wait for people to complain or, more likely, thank you :)
[16:01] <MvG> I'll have done unreviewed commits in the past, and will likely do more in the future, especially if I get no reviews here.
[16:02] <MvG> On the other hand, I've gotten some very useful input from reviews, so I'd at least give people a chance to look things over.
[16:02] <vila> ha ok, I thought you didn't get any
[16:03] <vila> jldupont: ok, I misunderstood, I thought you were on hardy :-/
[16:04] <jldupont> vila: no probs.
[16:05] <jldupont> vila: I installed the latest xmloutput (from what verterok wrote earlier): still blows up in my face.
[16:06] <verterok> jldupont: did you removed the system wide installed xmloutput?
[16:06] <jldupont> verterok: yes.... got Synaptic to do it.
[16:06] <jldupont> is this ok?
[16:06] <verterok> yes
[16:06] <jldupont> I have zapped my .bzr from my project...
[16:06] <jldupont> rebuilding everything now...
[16:07] <verterok> jldupont: and did you updated the xmloutput in .bazaar/plugins ?
[16:07] <vila> jldupont, verterok: that shouldn't matter if the .bazaar/plugins one is loaded, which 'bzr plugins -v' should confirm
[16:07] <jldupont> xmloutput 0.8.6.dev
[16:07] <jldupont>     This plugin adds an option (--xml) to log and provides an xml version of some
[16:07] <jldupont>     /home/jldupont/.bazaar/plugins/xmloutput
[16:07] <verterok> jldupont: ok, good
[16:08] <verterok> jldupont: are you getting the same error?
[16:08] <jldupont> Exception in Decorator. The 'Bazaar' decorator will be disabled.
[16:09] <jldupont> http://jldupont.pastebin.com/d2908bb17
[16:11] <bialix> MvG: you may want to set some limit for waiting of review: say 1 day. I fnobody answers, then simply go on and commit your improvements
[16:12] <jldupont> verterok:  any clue?
[16:12] <bialix> MvG: thank you for working on trac-bzr btw
[16:12] <verterok> jldupont: you removed the .bzr dir?
[16:12] <MvG> bialix: I'm committing when I tire of waiting for reviews...
[16:12] <bialix> MvG: I'm still have to find a time to test your changes, busy at work too much
[16:12] <jldupont> verterok: Yes I did.
[16:12] <MvG> The more central a change, the more I want it in trunk before working on, and the more impatient I am with reviews.
[16:13] <verterok> jldupont: please add it again, or remove the project from bzr-eclipse control in eclipse
[16:13] <bialix> MvG: when I know that review in qbzr or bzr-explorer may wait weeks, I clearly say that I will wait no more than week and if nobody subject will land it
[16:13] <verterok> jldupont: it will fail as eclipse have it mapped to bzr but there is no .bzr
[16:13] <jldupont> verterok: oh, wait a sec
[16:14] <bialix> MvG: there is too little people who can and most important want to review your changes
[16:14] <bialix> MvG: that said you can develop as you wish
[16:14] <bialix> MvG: i.e. don't wait for review at all
[16:15] <MvG> Already doing so for minor changes.
[16:15] <MorbusIff> g'day. i've got bzr log bzr:// working just fine. but a bzr log bzr+ssh:// complains that it's Not a Branch. No error about ssh auth or connecting. Just Not a Branch.
[16:15] <jldupont> verterok: ()@!_)( Eclipse is all confused now!
[16:16] <bialix> MorbusIff: what if you try sftp:// instead?
[16:16] <vila> MorbusIff: what path are you specifying ? '~' support has changed recently between sftp and bzr+ssh
[16:17] <MorbusIff> bialix: same erorr.
[16:17] <MorbusIff> vila: i'm specifying the path to a branch in both cases. example.com/branchname.
[16:17] <jldupont>     Error while executing push
[16:17] <jldupont>     RemoteRepository(bzr+ssh://bazaar.launchpad.net/~jldupont/tinycouch/trunk/.bzr/)
[16:17] <jldupont> is not compatible with
[16:17] <jldupont> CHKInventoryRepository('file:///home/jldupont/workspace/tinycouch_trunk/.bzr/repository/')
[16:17] <jldupont> different rich-root support
[16:17] <bialix> so there is really not a branch
[16:17] <vila> a full path then ?
[16:17] <jldupont> what do I do now??
[16:17] <jldupont> delete from LP ?
[16:17] <MorbusIff> bialix: but when i run bzr://, it works fine, with the same path.
[16:18] <MorbusIff> bzr://example.com/whee works, bzr+ssh://example.com/whee does not (complaining that it's not a branch)
[16:18] <bialix> MorbusIff: look into .bzr.log, you'll find there some debug info, maybe it helps to identify problem
[16:18] <MorbusIff> vila: using a full path causes both bzr:// and bzr+ssh:// to report Not a Branch.
[16:19] <MorbusIff> bialix: getting a traceback.
[16:19] <MorbusIff> doesn't personally tell me much though. i don't code python/bzr.
[16:20] <bialix> edit private urls and pastebin
[16:20] <bialix> then we can look and suggest something
[16:21] <MorbusIff> http://pastebin.com/m1aca9352
[16:21] <bialix> right now you can test via any ssh client if you can read sftp://example.com/whee/.bzr/format
[16:22] <bialix> perhaps you've got permission denied problem
[16:22] <bialix> are you sure your local login name and your login name on the server is the same?
[16:22] <MorbusIff> they are not, but i'm forcing the remote name in .bazaar/authentication.conf.
[16:22] <bialix> maybe you need to explicitly specify them in URL?
[16:22] <bialix> just for testing
[16:22] <MorbusIff> tried that before here, and same error.
[16:23] <bialix> MorbusIff: can you test via your ssh client if you can read sftp://example.com/whee/.bzr/format
[16:23] <bialix> ?
[16:24] <MorbusIff> yeah, i'm getting there.
[16:24] <bialix> what it means?
[16:24] <MorbusIff> i'm still in the process of testing that. tlaking to someone else at the moment.
[16:26] <MorbusIff> yeah, that was it, actually.
[16:26] <MorbusIff> the full path iw as giving was wrong.
[16:26] <MorbusIff> so the test failed.
[16:26] <jldupont> verterok: vila:  just to close the loop:  I deleted the branch on LP, delete my .bzr on my side, closed eclipse, re-init everything by hand through CLI, restarted eclipse... and now it works!
[16:26] <MorbusIff> when i gave the right full path, bzr log works now under bzr+ssh
[16:26] <jldupont> thanks for your precious time guys!
[16:30] <verterok> jldupont: cool :)
[16:31] <Imperion> um, is anyone willing to lend their Bazaar expertise and help me out with this?
[16:31] <Imperion> s/this/something/
[16:31] <bialix> it depends
[16:31] <Imperion> what on?
[16:31] <bialix> on your question, of course
[16:32] <bialix> just ask first
[16:32] <Imperion> designing and organizing the repository/branches
[16:32] <bialix> so what is your question
[16:33] <Imperion> just a sec
[16:34] <GaryvdM> Hi bialix and vila
[16:34] <bialix> Hi Gary!
[16:34] <Imperion> my project consists of a core executable and several modules
[16:34] <Imperion> the modules depend on files in the core for the interfaces, etc.
[16:35] <Imperion> what's the recommended way to set this up?
[16:35] <GaryvdM> bialix, vila: I'm very eger to here what you guys think about lp:~garyvdm/qbzr/just_show_tests
[16:35] <bialix> GaryvdM: I'm about to look at your branch right *now*
[16:35] <GaryvdM> :-)
[16:37] <bialix> gosh, I don't run bzr log for ages, forgot leading q...
[16:38] <bialix> GaryvdM: ok, I've ran it
[16:38] <bialix> looks terrible as you expected :-)
[16:38] <bialix> but I can live with that
[16:39] <bialix> but maybe if we can made those tests optional or control them somehow -- it will be nice
[16:39] <bialix> vila: ping
[16:39] <GaryvdM> bialix: The other option is to just init and run initial_load, but not show the widow.
[16:39] <vila> bialix: pong ?
[16:40] <GaryvdM> bialix: this would mean that the paint methods don't get tested.
[16:40] <bialix> vila: have a couple of minutes for qbzr>?
[16:40] <vila> bialix: I'm upgrading it to 2a and looking at gary's branch
[16:40] <bialix> GaryvdM: no, if we can I'd better test all we can
[16:40] <GaryvdM> ok
[16:41] <bialix> GaryvdM: this flashing windows is a bit annoying, but I understand the price.
[16:41] <chx> if i run bzr serve --directory=/reall/long/path is there a way to replace bzr co bzr+ssh://example.com/real/long/path/branch with simply bzr co bzr+ssh://example.com/branch
[16:41] <vila> GaryvdM: meh, that's 46 revisions on top of trunk ???
[16:41] <bialix> vila: in the past there were interactive tests for bzr itself
[16:42] <GaryvdM> vila: no - just 2
[16:42] <bialix> vila: is it possible to make part of test suite switchable?
[16:42] <dOxxx> Imperion: Whatever makes sense for the language you are using. If the core executables and modules all make a single logical project unit, then they can all go into a single bzr branch
[16:42] <bialix> chx: yes
[16:42] <chx> bialix: And how...?
[16:42] <vila> bialix: interactive tests make no sense for automation in my mind, what are you talking about ?
[16:43] <Imperion> dOxxx: okay
[16:43] <chx> bialix: I read the help for both co and serve and saw no way :/
[16:43] <chx> bialix: some conf file?
[16:43] <bialix> chx: you mix bzr serve and bzr+ssh
[16:43] <chx> oh i do not even need bzr serve when urnning bzr+ssh?
[16:44] <chx> that ... makes sense, i suppose?
[16:44] <bialix> chx: no
[16:44] <bialix> bzr+ssh launch bzr serve via ssh automatically
[16:44] <vila> GaryvdM: if I run 'bzr qlog trunk just_show_tests' it shows 46 additional revisions, what's up ?
[16:44] <chx> bialix: aaaaaaah
[16:44] <bialix> vila: do you have old trunk? new trunk is trunk2a
[16:45] <vila> bialix: aaaaaaaaaaaaaaargh
[16:45] <vila> I updated old trunk :-(
[16:45] <vila> I *upgraded* old trunk
[16:46] <bialix> that's fine, run pull --remember lp:qbzr now :-)
[16:46] <vila> right
[16:46] <vila> only 2 revisions now
[16:46] <bialix> Imperion: every branch is separate entity
[16:46] <vila> aaargh again, I ran 'pull --overwrite' and forgot --remember, you guys drive me nuts ;)
[16:46]  * bialix said --remember, not overwrite
[16:47] <bialix> vila: we don't want, honestly
[16:47]  * vila did it before bialix gave the right invocation :)
[16:47] <bialix> rats, I've late
[16:48] <chx> bialix: ok then is there a config value like the user=joe in authentication.conf to supply a sort of base bath?
[16:48] <vila> GaryvdM: so, a couple of remarks
[16:48]  * GaryvdM listens
[16:49] <Imperion> bialix: meaning
[16:49] <Imperion> ?
[16:49] <vila> instead of doing try/finally, use addCleanup, that avoids errors and indentations
[16:49] <bialix> chx: mmm, no. But I think you can try to use settings in authorized_keys on the server
[16:49] <bialix> Imperion: do you want all your modules to live in separate branches?
[16:49] <chx> bialix: like....?
[16:49] <vila> GaryvdM: i.e. self.addCleanup(win.close) just after the win is created
[16:50] <chx> bialix: or set the home directory of the bzr user.
[16:50] <bialix> chx: look in contrib/bzr_access to get some ideas
[16:50] <chx> i will
[16:51] <GaryvdM> vila: we have code that runs when the windows close (like saveing the window sizes.) What would happen if there was and error in that code?
[16:51] <vila> GaryvdM: don't override trace.report_exception unconditionally, you will regret it one day or another, do that in a setUp() and again use addCleanup to restore the original
[16:51] <bialix> Imperion: you can put your entire project into one big branch, or use separate branches for every module
[16:51] <Imperion> bialix: all of the parts depend on the core
[16:51] <vila> GaryvdM: don't worry, errors are allowed during cleanup methods, but they generally indicate deeper problems
[16:51] <bialix> Imperion: yes, but do your modules have thevalue by itself? to reuse them in other similar project?
[16:52] <Imperion> no
[16:52] <Imperion> they're useless without the core
[16:52] <bialix> Imperion: then put all modules into one big branch with core
[16:52] <bialix> Imperion: just think why you call them modules and separate from core?
[16:53] <GaryvdM> vila: Re overriding report_exception: What would be a good way to make that common among lots of test? (can you think of an example in bzrlib?)
[16:53] <bialix> Imperion: in bzr world branch is main thing, it's often synonym to repo in other systems
[16:54] <GaryvdM> vila: The big question is, is it ok to show and hide the gui from the test suit like that?
[16:54] <vila> GaryvdM: define a base class or a mixing that all test classes that requires the feature will use
[16:54] <GaryvdM> ok
[16:54] <Imperion> bialix: they're modules because they're interchangeable with other modules with the same interface
[16:54] <bialix> GaryvdM: I wonder if we actually can use QtTest
[16:54] <Imperion> bialix: e.g. multiple video driver modules
[16:54] <vila> GaryvdM: yes it is, bzr-gtk does that
[16:54] <vila> or did
[16:54] <bialix> Imperion: so they have value by itself? with other core?
[16:55] <Imperion> sorry?
[16:55] <vila> hmm, let me try a trick or two
[16:55] <bialix> Imperion: there are several reasons to not put modules into the same branch as core
[16:56] <bialix> Imperion: because once you put them there you'll have problems to split this branch later
[16:56] <vila> hehe, it works :)
[16:56] <Imperion> bialix: modules depend on the core to compile
[16:56] <bialix> Imperion: but there is one big reasons to do so: much simpler to clone entire project
[16:56] <GaryvdM> bialix: Yes - QTest will help when we want to test things like clicking on a button.
[16:56] <vila> GaryvdM: http://paste.ubuntu.com/329520/
[16:57] <bialix> GaryvdM: In my undertsanding QtTest can help to avoid actually show the GUI?
[16:57] <bialix> Imperion: what you need called nested trees
[16:57] <vila> bialix: look at my pastebin, no more windows showing up :-D
[16:57] <Imperion> bialix: explain?
[16:57] <bialix> Imperion: but they are not implemented yet
[16:58] <Imperion> >_>
[16:58] <GaryvdM> vila: I'm not sure if that will cause paint events to run - I run with --coverage to check
[16:58] <bialix> Imperion: you can organise several separate branches into complex project
[16:58] <vila> GaryvdM: could be, let me know
[16:58] <bialix> and work with such construct as with one big branch
[16:58] <bialix> vila: hehe, nice
[16:58] <GaryvdM> bialix: As far as I can see from the docs, no
[16:59] <bialix> Imperion: there is 3rd party tools to manage this problem though
[16:59] <bialix> Imperion: config-manager utility; scmproj, externals plugins
[17:00] <Imperion> mhmm
[17:00] <bialix> Imperion: I'm the author of scmproj
[17:00] <bialix> scmproj is somewhat emulation of nested trees
[17:00] <bialix> Imperion: do you familiar with svn?
[17:00] <bialix> or CVS?
[17:00] <Imperion> no
[17:01] <bialix> Imperion: no other VCS experience?
[17:01] <Imperion> nope
[17:01] <bialix> ok
[17:01] <Imperion> my project is hosted on Launchpad
[17:01] <Imperion> will this be possible? :S
[17:01] <bialix> is and will in last 2 sentences are conflict
[17:02] <bialix> yes, it's possible
[17:02] <vila> Imperion: why do you want to separate the modules if they require trunk ? (I.e. they make no sense without trunk)
[17:02] <bialix> what is your project? it's open source as I understand
[17:02] <Imperion> vila: I don't want anything, I'm asking for advice
[17:02] <Imperion> bialix: 2D isometric RTS engine, https://launchpad.net/catom
[17:02] <Imperion> the code currently available is old
[17:02] <Imperion> I've refactored everything
[17:03] <bialix> vila: Imerion said the modules can be changed by similar with the same interface, sounds like pluggable architecture for me
[17:03] <Imperion> bialix: it is
[17:03] <Imperion> and I'm wondering about improving the organization of it
[17:03] <bialix> vila, Imperion: therefore I'd suggest to not put plugins into the same branch as core
[17:03] <vila> Imperion: sry, my advice will then be: don't separate modules from trunk if there is a strong dependency, just keep them in the same branch
[17:04] <Peng> After 80 hours, "bzr check" on 1.14 MySQL is *still* at "[####\               ] checking commit contents:inventories 0/2". I might give up soon.
[17:04] <Imperion> dun dun dun
[17:04] <vila> bialix: that's just asking for trouble if they should always be kept synchronized
[17:04] <bialix> the truth is: you can merge all your separate modules into core branch easily but not vice versa
[17:05] <bialix> Imperion: so you need some experiments
[17:05] <Imperion> I wonder how I'll fix the CMake script to work with this
[17:05] <MorbusIff> if i checkout a bzr branch, is my commit access to it allowed or unallowed, barring any other configuration?
[17:05] <vila> haaa, GaryvdM is back !
[17:06] <bialix> back from Ubuntu
[17:06] <vila> GaryvdM: why don't you use a VM instead of a double boot ?
[17:06] <GaryvdM> in ubuntu
[17:06] <GaryvdM> vila: Yes I should
[17:07]  * bialix does not know cmake specific, can't say much useful
[17:08] <bialix> Imperion: single branch with all modules + core would be much simpler to you right now, given in mind lack of good nested trees support
[17:08] <Imperion> okay
[17:09] <bialix> I'm working on new design of scmproj, I'm hope I'll have better support of critical features soon
[17:12] <GaryvdM> vila: The window still flashes for me :-(
[17:12] <GaryvdM> vila: and the paint methods don't get run.
[17:13] <GaryvdM> vila: I'm going to make your other changes though.
[17:13] <vila> GaryvdM: forget about the cheap trick then, we may want to try harder when I add the plugins to babune
[17:14] <vila> GaryvdM: but even there you may add some feature check to ensure there is a usable display
[17:14] <GaryvdM> vila: yes - I hope to still find a solution.
[17:15] <vila> GaryvdM: don't spend too much time on it now, it's better to have tests that requires some feature than no tests :)
[17:15] <GaryvdM> vila: but for now, it's a start in the right direction I believe.
[17:15] <GaryvdM> vila: yes
[17:15] <vila> GaryvdM: definitely !!
[17:16] <vila> GaryvdM, bialix : gtg, have a nice week-end !
[17:17] <GaryvdM> Bye vila - Thanks for the help.
[17:17] <bialix> gtg?
[17:17] <GaryvdM> got to go
[17:17] <vila> gotta go
[17:17] <bialix> bye vila, thanks!
[17:51] <bialix> GaryvdM: I'm ok with your new flashing tests
[17:52] <bialix> GaryvdM: btw, one observation about exception dialog reporter
[17:53] <bialix> if I click X button on this dialog or press Esc then it treats this as Ignore. In most cases the problem too serious and we need to actually close the window
[17:54]  * bialix going home
[17:54] <bialix> bye GaryvdM, bye all
[18:03] <Peng> beuno: ping
[18:03] <beuno> Peng, hi dude
[18:04] <Peng> beuno: You approve lp:~deuns-martinez/loggerhead/flup? I'd be happy to tweak and land it.
[18:04] <beuno> Peng, I do, I think that with the tweaks it's good enough
[18:05] <beuno> and he's gone to the trouble of signing the contributor agreement, submitting the branch, etc
[18:06] <Peng> beuno: So...want me to go ahead and do that?
[18:06] <beuno> Peng, yes!  thank you
[18:06] <Peng> OK. :)
[18:09] <Peng> Done.
[18:09] <beuno> thanks Peng!
[18:10] <Peng> :)
[18:34] <servilio> hi! do the karmic versions of bzr & bzr-svn work OK under Ubuntu Hardy?
[18:34] <beuno> servilio, probably not
[18:34] <beuno> there are some depenency issues with python-central, if IIRC
[18:35] <Peng> There aren't Hardy versions you can use?
[18:36] <servilio> beuno, Peng: just enabled the backports in hardy but didn't see it, now trying to debbuild using karmic source repos, but wanted to quick ask first
[18:36] <servilio> I'd prefer to build from source packages
[18:37] <Peng> There's probably a PPA.
[18:38] <Peng> servilio: Try https://edge.launchpad.net/~bzr/+archive/ppa
[18:41] <servilio> Peng: looking at https://launchpad.net/~bzr/+archive/ppa?field.series_filter=hardy
[18:41] <servilio> Peng: thanks for the suggestion1
[18:41] <servilio> !
[18:42] <Peng> servilio: Don't thank me until you confirm that the PPA versions of bzr + bzr-svn + subvertpy are all compatible...
[18:45] <servilio> Peng: shouldn't the source package specify when it could not be built by using minimum versions for its requirements?
[20:14] <roychri> I created a new test project and I pushed to my server using sftp.  No errors.  When I try to branch off using http, I get : "bzr: ERROR: Unknown working tree format: ''"
[20:14] <roychri> I searched for that error in google but found nothing :(
[20:18] <maxb> What a weird error
[20:18] <maxb> Perhaps you should publish a test repo on your server that people can use to reproduce the bug
[20:22] <roychri> maxb: I published a test repo on my "dreamhost" account using sftp and I can branch off from there.
[20:22] <roychri> maxb: I cannot do it from this internal apache web server that the infra team setup.
[20:22] <roychri> maxb: They did not set it up for me to publish bzr branches so they are not willing to help me out
[20:23] <roychri> I can do it but I am on my own :(
[20:23] <maxb> So, to clarify, you are using "dumb" http
[20:24] <roychri> yes
[20:24] <roychri> sftp to publish and dumb http to branch from.
[20:25] <abbec> i have a problem with bazaar on nfs4 share
[20:25] <abbec> anyone that can help?
[20:28] <maxb> roychri: Perhaps you could see if using -Derror or -Dhttp shows any useful information
[20:28] <roychri> passing that to bzr cli?
[20:29] <roychri> interesting
[20:30] <roychri> maxb: http://pastebin.com/d5852206f
[20:31] <abbec> i have a problem with running bzr stat on an nfs4 share... anyone that can help?
[20:31] <maxb> roychri: bzr 1.3.1? That's like, ancient history! :-)
[20:32] <roychri> maxb: oh... I simply did "apt-get install bzr".
[20:32] <roychri> maxb: I did not realized it was archaic
[20:32] <maxb> Ubuntu or Debian?
[20:32] <roychri> ubuntu 8.04
[20:32] <maxb> There is an official PPA carrying the latest release
[20:32] <maxb> https://launchpad.net/~bzr/+archive/ppa
[20:33] <Peng> roychri: What does http://server5591.lan/code/testyyy/.bzr/checkout/format look like?
[20:34] <roychri> Peng: no checkout in .bzr
[20:34] <roychri> there is a http://server5591.lan/code/testyyy/.bzr/branch/format file however.
[20:35] <roychri> maxb: Thanks for the PPA, I will give it a try
[20:35] <Peng> roychri: What happens if you try to visit http://server5591.lan/code/testyyy/.bzr/checkout/format in a browser, though?
[20:35] <Peng> roychri: Also, is ther eany sort of proxy involved?
[20:35] <Peng> there any*
[20:36] <abbec> i have a problem with running bzr stat on an nfs4 share... anyone that can help?
[20:36] <abbec> if i run bzr stat on the nfs4 share everthing hangs up
[20:37] <roychri> Peng: hmmm. you might be on to somethnig. I am not getting 404.
[20:37] <roychri> Peng: nice.  You got it!
[20:37] <Peng> :D
[20:37] <roychri> Peng: There was an .htaccess in the parent folder.
[20:37] <roychri> http://server5591.lan/.htaccess
[20:38] <roychri> With some rewriterules that was screwing things yup
[20:38] <Peng> Does it work now?
[20:38] <roychri> yup
[20:38] <roychri> Branched 1 revision(s).
[20:39] <Peng> Perfect. :)
[20:40] <roychri> Thank you Peng and maxb for your help today.
[20:47] <abbec> i have a problem with running bzr stat on an nfs4 share... anyone that can help?
[20:47] <abbec> if i run bzr stat on the nfs4 share everthing hangs up
[20:48] <Peng> "Hangs up"? Are you sure it's not just slow?
[20:50] <abbec> yes
[20:50] <abbec> i am sure
[20:50] <abbec> every other command works though
[20:50] <abbec> https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/403697
[20:50] <abbec> this bug describes the same behaviour
[20:51] <abbec> Peng: it works with nfs3 and bzr stat works with nfs4 if there has not been any changes
[20:52] <abbec> Peng: but if there is changes it hangs on bzr stat
[20:52] <Peng> Sorry, I don't know much about this.
[20:52] <abbec> anyone else?
[20:54] <abbec> bzr diff and other commands work
[20:55] <dOxxx> abbec: you could try emailing the mailing list, you may reach a broader audience and increase your chances of finding somebody who knows something about it
[20:55] <abbec> dOxxx: ok... how do i do that?
[20:56] <dOxxx> abbec: https://lists.ubuntu.com/mailman/listinfo/bazaar
[20:56] <dOxxx> you'll need to subscribe to post
[20:56] <abbec> dOxxx: thx
[21:04] <maxb> Anyone knowing lots about bzr-svn layouts here?
[21:05] <maxb> If I have a repository containing many projects *not all at the same depth from the repo root* what should I do?
[21:05] <rittyan> Hi all. Can't connect to answers.launchpad.net (some network problem). I am using git for 1,5y and now I am in a company where bzr is popular. I considered switching and I have a question about a feature I use 100% of time in git: interactive add. Is there something like that? I found shelve feature, but it looks like stash in git (i.e. isn't the one I am after)
[21:06] <GaryvdM> rittyan - Not in the core, but I think there is a plugin.
[21:06] <GaryvdM> let me search
[21:07] <maxb> https://edge.launchpad.net/bzr-interactive ?
[21:08] <dOxxx> rittyan: are you referring to something like the git staging area?
[21:09] <GaryvdM> maxb: yes that's it
[21:10] <maxb> jelmer: Hi, is there any bzr-svn layout configuration that will enable it to deal with a svn repository with multiple projects (trunk tags branches in each) *not all at the same depth from the repo root*?
[21:10] <jelmer> maxb: custom/wildcard branch layout
[21:11] <rittyan1> (sorry for repeating, I got disconnected) Hi all. I am using git for 1,5y and now I am in a company where bzr is popular. I considered switching and I have a question about a feature I use 100% of time in git: interactive add. Is there something like that? I found shelve feature, but it looks like stash in git (i.e. isn't the one I am after)
[21:11] <rittyan1> i.e., can I commit hunks or lines I pick from a file, instead of whole file
[21:11] <maxb> So I'd have to enumerate each project separately in the bzr-svn config?
[21:11] <dOxxx> rittyan: Somebody suggested trying bzr-interactive
[21:12] <GaryvdM> rittyan1: https://launchpad.net/bzr-interactive
[21:12] <jelmer> maxb: You can use multiple asterisks in the wildcard layout
[21:13] <maxb> branches = */branches/*;*/trunk  ?
[21:14] <dOxxx> rittyan: also, you can use shelve to accomplish something like git's staging area. you shelve the changes you don't want, commit the rest and then unshelve.
[21:14] <rittyan1> dOxxx: troublesome
[21:14] <rittyan1> and that plugin looks... "new", according to bugs
[21:14] <jelmer> maxb: for example
[21:15] <rittyan1> also, as I understand, plugin => no support in gui
[21:15] <jelmer> maxb: asterisks will only cover one directory level
[21:15] <GaryvdM> rittyan1: I'm one of the devlopers of qbzr. I hope to add support for that soon.
[21:15] <jelmer> maxb, you might need "*/trunk; */*/trunk; */*/*/trunk", etc
[21:15] <rittyan1> dOxxx: I do series of commits at once, making them small and per-feature from big changes. Shelving/Unshelving is definitely troublesome with such workflow :<
[21:16] <dOxxx> rittyan: yeah. although to be honest, shelve -> commit is pretty much the same amount of effort as stage -> commit, if you ask me. :)
[21:16] <dOxxx> rittyan: if you're using this to separate feature commits, perhaps you should be trying feature branches.
[21:17] <rittyan1> feature branch is something like creating a branch per feature? Like, `git branch ticket-1234`
[21:17] <dOxxx> rittyan: yes. usually used in conjunction with a shared repository so as to save disk space and make the branching quick.
[21:18] <rittyan1> I use that workflow already :) it's just isn't wise to use it to add a function (one commit), then put this function to use (another commit), for example
[21:19] <rittyan1> damn, I am addicted, it seems :/ without hope to switching
[21:19] <dOxxx> rittyan: for sure, it's best used in a somewhat coarse manner, like a bug per branch, etc.
[21:23] <dOxxx> hmmm
[21:23] <dOxxx> rittyan: comment #10 and #16 on http://tomayko.com/writings/the-thing-about-git are interesting
[21:24] <dOxxx> rittyan: something that may also be useful to you is bzr-pipeline or bzr-loom
[21:34] <rittyan1> dOxxx: I don't get what it says. I never had any problems with testing or whatsoever, hm :<
[21:35] <dOxxx> rittyan1: it's more of a general principle thing. The changes committed using git's staging area have not been tested on their own as you're committing them.
[21:35] <dOxxx> rittyan1: anyway, I'm just saying it's an interesting perspective. I personally found the staging area quite useful in some cases when I was using git a while back.
[21:35] <rittyan1> care to share what do you do when you write a function, put it to use, make cosmetic changes (you are on a coding spree) and then you need to make 3 commits of it?
[21:36] <dOxxx> rittyan1: my usual working environment uses cvs, so in that case I cry. ;)
[21:36] <rittyan1> what about your after-work life :)
[21:37] <dOxxx> rittyan1: but using bzr, I would use shelve to separate the changes
[21:37] <dOxxx> rittyan1: or if the cosmetic changes are closely related to the function I added, I would probably just include it in the one commit
[21:38] <dOxxx> rittyan1: commit history doesn't have to be an exact replica of the process you went through to make the changes.
[21:38] <rittyan1> of course, that's why I spent an hour today moving back and forth commits for 3 prev. weeks, squashing or "fixing" then a bit
[21:38] <rittyan1> before pushing to public
[21:39] <dOxxx> rittyan1: using git or bzr?
[21:39] <rittyan1> I am using git
[21:40] <rittyan1> I never tried bzr yet, but a lot of people at work do
[21:40] <rittyan1> I am preparing myself :)
[21:41] <dOxxx> rittyan1: as I understand it, when you merge stuff from one git repo to another, the target repo gets the individual commit messages. so if you commit with messages "1", "2", "3" and then merge to another repo, that repo will have revisions with messages "1", "2", "3", right?
[21:41] <dOxxx> hmm
[21:41] <dOxxx> although I think I'm mixing up my terminology. merge is not push. :)
[21:42] <rittyan1> hmm I am not sure I got it, but what you say looks correct to me. Also, I used merge only once maybe, in 1.5y of using git
[21:42] <rittyan1> I am rebase kind of user
[21:43] <lifeless> moin
[21:43] <rittyan1> (i.e. try to stack commits from one branch on top of another and fix conflicts if there any)
[21:43] <rittyan1> moin lifeless
[21:43] <dOxxx> anyway, the point I was trying to make is that using feature branches and merging them into a trunk means that the "messy" nature of the commits on the feature branch are hidden.
[21:44] <dOxxx> because the merge appears as a single revision with your merge commit message on the trunk
[21:45] <rittyan1> dOxxx: yes that's why I don't like merging :))
[21:45] <dOxxx> rittyan1: however, bzr does expose the individual commits of the merge if you want
[21:46] <dOxxx> rittyan1: check out this example: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/4832
[21:46] <rittyan1> what at I should take a closer look there?
[21:46] <rittyan1> ah! got it
[21:47] <dOxxx> if you follow the link "4831.1.1 integration" on that page, that takes you to the branch vila merged into trunk
[21:47] <rittyan1> except that I don't see any individual commits there
[21:47] <dOxxx> on the page for vila's branch you can see 4815.3.8 quiet-serve
[21:47] <dOxxx> that's *my* feature branch
[21:48] <dOxxx> if you then click the view history link you'll see the individual commits
[21:48] <dOxxx> but note that all this info is coming from the bzr.dev trunk repo
[21:48] <dOxxx> the bzr GUI log tool, qlog, shows it quite a nice way
[21:49] <rittyan1> I think that I should give it a try
[21:49] <rittyan1> and see if I like it
[21:49] <rittyan1> because anyway, sooner or later I will probably have to face bzr
[21:49] <rittyan1> like it or not :/
[21:49] <dOxxx> it's not that bad ;)
[21:50] <rittyan1> and one more question: there must be rebase, I bet. Interactive one? :)
[21:51] <GaryvdM> rittyan1: Here is a screen shot of those revisions in qlog: http://imagebin.ca/view/IjcR0oL.html
[21:51] <rittyan1> GaryvdM: looks like typical git log in gui
[21:51] <rittyan1> except that green node has trailing pink changes that have no parent
[21:52] <GaryvdM> the parent is off the screen
[21:52] <rittyan1> this is that? commits existed during merge?
[21:52] <rittyan1> ah, right
[21:52] <dOxxx> rittyan1: yes
[21:52] <GaryvdM> rittyan: note that you can also colapse and expand those merges, like a tree
[21:53] <dOxxx> rittyan1: there is a plugin for rebase/rewrite
[21:53] <GaryvdM> rittyan1: Yes - there is rebase, via plugin. See http://bazaar-vcs.org/Rebase
[21:53] <rittyan1> does it mean that on public repos people will know about my private <s>life</s> commits?
[21:54] <dOxxx> if it's merged, yes
[21:54] <dOxxx> you could always email patches ;)
[21:55] <GaryvdM> Hopefully you don't commit you private life to a public repo ;-)
[21:57] <dOxxx> brb, disconnecting vpn
[21:59] <rittyan1> hmm, thanks for help
[21:59] <rittyan1> honestly it all sounds very limited, no offence... I am just used to something bizzare it seems
[21:59] <rittyan1> you are great bunch of guys, thank you o/
[22:00] <GaryvdM> rittyan1: Any time.
[22:00] <dOxxx> rittyan1: you're welcome
[22:07] <dOxxx> what's the diomatic way in python to represent an abstract method in an abstract class?
[22:07] <dOxxx> i.e. as a hint that subclasses must implement this method
[22:07] <GaryvdM> raise NotImplemented
[22:08] <dOxxx> aha
[22:08] <Peng> No, NotImplementedError.
[22:08] <dOxxx> thanks
[22:08] <GaryvdM> Yes, sorry thats what I ment.
[22:09] <Peng> NotImplemented is for use in comparison methods. You return it if you don't know how to compare with the other object.
[22:09] <lifeless> raise NotImplementedError(self.methodname)
[22:10] <dOxxx> where 'methodname' is the actual name of the method?
[22:11] <Peng> dOxxx: Where "self.methodname" is an expression that evaluates to the method object itself.
[22:11] <Peng> def foo(self): raise NotImplementedError(self.foo)
[22:11] <dOxxx> Peng: gotcha
[23:20] <gutworth> when do we get branch specific eol patterns?


[13:57] <colan> are any of the site admins around, or is this just for dev?  there's some content that should be removed.
[14:16] <dobey> spam in bug reports?
[14:25] <colan> dobey: no, someone posted my e-mail address in a reply to a public ticket.  i've since set "hide my e-mail" in my profile, so this would be a one-time request for a removal.
[14:27] <dobey> what bug?
[14:41] <colan> dobey: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1332398
[14:45] <dobey> ok, what i thought. someone replied via e-mail and included the quoted mail in the reply. and your acocunt wasn't set to "hide my e-mail" when you posted a reply on the bug 19 hours ago?
[15:55] <colan> dobey: correct, but now that box is checked. so may i request that my address be removed from that post?  it won't happen again.
[15:56] <colan> i didn't even know it was possible to reply by e-mail! :)
[16:42] <dobey> colan: i don't think so. editing content of valid replies is not generally something that is done
[16:43] <dobey> colan: you can ask a question at https://answers.launchpad.net/launchpad to see if an admin will do it
[16:43] <colan> dobey: it's not really editing so much as redacting personal information.  ok thanks, will check it out.
[16:43] <dobey> colan: or you can ask the person who replied to hide their comment on the bug, and then reply in a new comment on the web site so your e-mail won't be shown
[16:44] <colan> dobey:  hmmm. ok, that's another good option.
[17:54] <teward> how long after depwait is encountered before ppa builds retry?
[18:55] <mapreri> teward: from my experience, less than 10 minutes
[18:56] <teward> mapreri: after how many depwaits does it just trigger fail:unmet deps
[19:22] <mapreri> teward: well, this I don't know. I always fixed my depwait uploads in short time