[00:15] <hexsprite> hi bzr people ;) i have been using git-svn and wonder if bzr-svn has the same limitations.  particularly i want to be able to share bzr repositories between my laptop and my desktop and be able to merge between them using bzr and then commit via svn from either of them... possible?
[00:15] <lifeless> totally possible
[00:15] <hexsprite> great!
[01:40] <ianm_> how do you force unlock a directory?
[01:40] <lifeless> bzr break-lock
[01:42] <ianm_> thanks
[01:54] <cerw> hi there
[01:54] <lifeless> hi
[01:54] <cerw> i have question our repos is getting too big, we are using for archive mainly, can i somehow remove some old revision, without demiging the repo ?
[01:55] <lifeless> not trivially no
[01:56] <lifeless> you need to do a rebase operation skipping the bits you don't want
[01:56] <lifeless> how big is too big?
[01:56] <cerw> it's about 70G
[01:56] <cerw> but the think is we dont need to keep all the repos
[01:57] <cerw> we are using it for deploying
[01:57] <cerw> everyday new version of release and taging them, that works great
[01:57] <cerw> but we need to keep only maybe 20days old tags, the oder onnes we can trash..
[01:59] <cerw> waht is rebase about?
[02:00] <lifeless> rebase rewrites history; what you want to do can be described as rewriting history
[02:00] <lifeless> there is also stacked branches which may help you and still keep history
[02:00] <lifeless> are you deploying binary files?
[02:00] <cerw> yeap it's final product, so some binary some scripts
[02:01] <cerw> anad lots of data
[02:05] <cerw> so i can remove revisions using rebase?
[02:07] <lifeless> with some effort yes
[02:07] <lifeless> its not exactly polished at the moment
[02:08] <lifeless> someone posted a recipe to the list I think
[02:15] <cerw> i am just playing with it now and it looks it it rewrutes each revision again
[02:15] <cerw> not sure if i want that
[02:15] <cerw> can i start branch and tell it to start it from some revision?
[02:16] <cerw> then i can split it ..
[02:21] <cerw> ok so is there way i can copy branch startinfr from some Revision?
[03:47] <NfNitLoop> So, out of curiosity, I tried to reproduce this bug w/ 1.9rc1 & 0.4.14:  https://bugs.launchpad.net/bzr-svn/+bug/248289
[03:47] <NfNitLoop> but I apparently can't commit to a bound svn branch.
[03:48] <NfNitLoop> I get the error:  ValueError: invalid property value 'branch-nick' for None
[03:48] <NfNitLoop> I'm not sure if that's a bzr error or bzr-svn.
[03:51] <poolie> NfNitLoop: can you put the traceback from ~/.bzr.log into a new bug please?
[03:51] <NfNitLoop> ok.   for bzr alone?
[04:05] <poolie> for the command that gave you the error
[04:05] <NfNitLoop> er, well, it was just 'bzr', but I'm not sure if it's the interaction with svn that cause it.
[04:05] <NfNitLoop> in any event, the bug is here:  https://bugs.launchpad.net/bzr/+bug/293440
[04:49] <NfNitLoop> Wow.
[04:49] <NfNitLoop> I just learned about stacked branches.
[04:49] <NfNitLoop> That's nice!
[04:49] <NfNitLoop> I should keep a closer eye on bzr-land. :)
[04:59] <NfNitLoop> Is there a way, once I've got a stacked branch...
[04:59] <NfNitLoop> to unstack it?
[05:00] <NfNitLoop> sortof like unbind?
[05:01] <lifeless> not really; just branch from it locally without the stacked parameter and it will copy everything
[05:01] <lifeless> there is an internal api
[05:01] <NfNitLoop> Yeah, I just tried that...
[05:01] <lifeless> bt, its internal:P
[05:01] <NfNitLoop> and it didn't go very well. :p
[05:01] <lifeless> oh? it should work, what went wrong
[05:01] <NfNitLoop> NotImplementedError: <bound method VirtualInventoryTexts.iter_lines_added_or_present_in_keys of <bzrlib.plugins.svn.versionedfiles.VirtualInventoryTexts object at 0x13d48f0>>
[05:02] <lifeless> file a bzr-svn bug for that
[05:04] <NfNitLoop> it *did* warn me that stacking was experimental in bzr-svn. :p
[05:18] <cerw> hi there
[05:19] <cerw> can i make a copy (branch) from current repository, but stariung by soe REVISION? i dont want to keep the whole repo..
[05:34] <jkakar> I'm trying to merge a branch and getting this error: http://paste.ubuntu.com/67126/
[05:34] <jkakar> Any suggestions on how to proceed?
[05:34] <mkanat> Is there an "up and revert in one command" command?
[05:50] <poolie> mkanat: no
[05:51] <poolie> jkakar: :/ sorry for the bad message
[05:51] <poolie> one of them is a rich-root repository probably
[05:51] <poolie> bzr info will tell you
[05:51] <poolie> upgrade the other one to 1.9-rich-root
[05:52] <spiv> And "bzr info -v" will tell you if "bzr info" just says "unnamed".
[05:58] <poolie> that is getting to the top of my shit list
[07:00] <vila> hi all
[07:06] <spiv> vila: hi
[09:20] <SuperMMX> hi, guys, is it possible to add hooks only for a specific branch ?
[09:36] <matkor> Hi ! What would be better (faster over slow network) for distributing mostly RO version of given branch ? checkout ? --lightweight checkout ? else ?
[09:38] <AfC> Well, a lightweight checkout will only work if you have real time access (over your network) to the actual branch, wherever it is.
[09:44] <matkor> AfC: I have branches spread over vpn ... but find doing bzr update (over plain checkout) long process, I wonder if there is way to speed it up ...
[09:44] <matkor> I am using sftp://
[09:44] <Peng_> Using bzr+ssh would be faster.
[09:44] <Peng_> You should make sure you're using the latest version of bzr you can, and that your branches aren't in the old knit format.
[09:45] <Peng_> Other than that, there's not much you can do.
[09:45] <AfC> Yeah, I wouldn't particularly expect sftp:// to be fast for much of anything.
[09:46] <matkor> Peng_: I will switch to bzr+ssh than .. I think I follow all upgrade suggestions seen in bzr CLI , so I suspect I am up to date in terms of branches format ...
[09:46] <AfC> I mean, sure, if your VPN never breaks and has really low latency and is really fat, then sure, run lightweight. But it sounds like you have the opposite than, that which is *just* the situation where you want to have full (distributed version control) branch information locally. So, {shrug}
[10:14] <matkor> AfC: Mostly what I do is bzr update (downloading newer version) over VPN, really really rarely  I need history or make comit ...
[10:15] <AfC> matkor: do you do `bzr status` and `bzr diff`?
[10:16] <matkor> AfC: yes
[10:16] <matkor> and bzr missing <remote>
[10:17] <matkor> in --lightweight checkout it's not possible withou network connection ?
[10:17] <AfC> As I understand it, no.
[10:18] <AfC> The whole point of distributed version control is to get the data to the other side of the bottleneck.
[10:19] <AfC> and like I said, if you're complaining about your VPN's speed...
[10:19] <AfC> But more to the point, why don't you try all this yourself and see?
[10:19] <matkor> mhmm... OK so will switch to bzr+ssh and see if it helped with my feelings. Thank you very much, AfC, Peng_
[10:19] <AfC> You're a smart person. If it works acceptably for you, then fine.
[10:20] <AfC> I certainly would *NEVER* recommend this sort of thing to anyone, but I believe strongly in the premises of decentralized version control and the value of having full history somewhere locally.
[10:21] <AfC> So what you're asking about is really somewhat anathema. That Bazaar supports it all has always struck me as ... strange ... but hey.
[12:41] <jelmer> lifeless, ping?
[14:11] <Flimm> Hello, I'm using Launchpad to host my bazaar branch
[14:11] <Flimm> How can my friend download any commits I make to his computer?
[14:11] <Flimm> This is the method I'm using now:
[14:11] <Flimm> bzr branch lp:epidermis
[14:12] <Flimm> Then whenever I commit and push, my friend does
[14:12] <Flimm> bzr revert
[14:12] <Flimm> bzr pull lp:epidermis
[14:14] <beuno> Flimm, why does he revert?
[14:14] <beuno> he can emrge from your branch
[14:14] <beuno> *merge
[14:16] <Flimm> merge doesn't auto commit though
[14:16] <Flimm> and I don't want him to deal with any conflicts in case he has edited the files
[14:16] <beuno> no, you commit after you merge
[14:17] <beuno> I don't understand
[14:17] <Flimm> pull automatically commits the way I commited, which I like
[14:17] <beuno> well, he can pull to a separate branch
[14:18] <Flimm> By why should he make a separate branch every time I commit?
[14:20] <Flimm> he reverts in order to undo any changes he might have made
[14:23] <beuno> Flimm, he can keep a seperate branch with the mainline
[14:23] <beuno> and one he works on
[14:24] <beuno> why would he have to loose his changes every time you commit?
[14:24] <Flimm> He's not contributing any code at all, he's just testing the code
[14:25] <beuno> uhm
[14:25] <beuno> ok
[14:25] <beuno> so, what's the problem
[14:34] <Flimm> I just wondering if that was the recommended approach, beuno
[14:35] <beuno> Flimm, well, I suppose if someone doesn'really doesn't want to play with a branch in parallel, and really will never commit, etc etc etc, then reverting all the time sounds about right
[14:35] <beuno> you could potentially also use pull --overwrite
[14:35] <beuno> but this is a bit of an odd use case I think
[14:41] <nogden> hey people, does anyone else have a problem installing bzr-svn in kubuntu interpid?
[14:41] <nogden> using the launchpad ppa for stable releases at the moment
[14:43] <nogden> seems that bzr version installed is 1.8-1 and bzr-svn expects 1.8 any ideas of a workaround?
[14:47] <Peng_> Where are you installing bzr-svn from?
[14:48] <nogden> I'm assuming it comes from the same ppa does it not?
[14:49] <nogden> or is there a seperate one for the plugin?
[14:49] <Peng_> Oh, I didn't know it was in the PPA again.
[14:49] <Peng_> Sorry, I can't help then.
[14:49] <nogden> ah, my mistake.... it isn't
[14:49] <nogden> it's in universe/devel
[14:51] <Peng_> Oh.
[14:53] <nogden> hmmm, acording to launchpad bzr-svn 0.4.13-2 (the version in universe/devel) just required bzr >= 1.6
[14:54] <nogden> now I'm running bzr 1.8-1 from the launchpad ppa but there seems to be an issue
[14:55] <nogden> ah, apt reports that it depends on bzr < 1.8
[14:58] <nogden> hmmm, looks like a manual install... grrr
[14:59] <nogden> ah, packages available in deb http://samba.org/~jelmer/debian/ unstable/
[16:01] <abentley> jam:ping
[16:05] <asabil> could someone please update the bzr-svn in ppa ?
[16:05] <asabil> to disable the bzr (<1.8)
[16:36] <disturbedsaint> markh I've updated the wiki page about tbzr, hope it's OK
[17:18] <Kinnison> Anyone here know of an issue pushing to a knit repository over sftp with current bzr.dev ?
[17:20] <Kinnison> specifically something which looks a bit like this: http://rafb.net/p/Tbug8Y55.html
[17:39] <gour> nice, bzr-gtk-0.95 does not crash with bzr-trunk as 0.94
[18:20] <LeoNerd> Has anyone written a bzrfs fuse module yet?
[18:20] <james_w> LeoNerd: yeah, there's one around
[18:21] <james_w> don't know if it's been kept up to date
[18:22] <gour> oops, 1.10dev is crashing here - http://rafb.net/p/dm1VJO45.html
[18:28] <Peng_> gour: Eh? Was that a change you made?
[18:28] <Peng_> gour: You should use "hashlib.md5", not "hashlib.new".
[18:29] <james_w> Kinnison: I haven't, I think it's bug time for you.
[18:29] <gour> Peng_: hmm. maybe it's bette to rm search plugin, until it's ready
[18:32] <Peng_> gour: Actually, use bzrlib.osutils.md5().
[18:32] <gour> Peng_: what about this one - http://rafb.net/p/Tdc42F61.html bzr-gtk & bzr-dev ? (i fixed it by upgrade to 0.95)
[18:33] <gour> Peng_: it's better that i become more familiar with python's standard lib before 'fixing blindly'
[18:33] <Peng_> gour: That one I don't know.
[18:44] <Peng_> gour: Well, http://bzr.mattnordhoff.com/loggerhead/bzr-search/py2.6/ should fix the md5 issue, but there might be others.
[18:44] <Peng_> (I don't have Python 2.6 to test myself.)
[18:45] <Peng_> gour: (And it also ruins compatibility with older versions of bzr. :P )
[18:58] <Kinnison> james_w: *pout*
[19:01] <Kinnison> filed as https://bugs.launchpad.net/bzr/+bug/293746
[19:01] <james_w> thanks
[19:14] <gour> Peng_: yes...pkgs need to (slowly) migrate to 2.6...soon there will be even 3.0
[19:39] <mDuff> Does the 1.9rc1 standalone win32 installer include bzr-svn, or did I have an old copy of that hanging around from somewhere?
[19:50] <ja1> abentley: sorry about the delay, are you still around?
[19:50] <abentley> Yeah.
[19:51] <abentley> ja1: Are you okay with me merging the shelf ui with the changes I sent?
[19:51] <jam> yeah
[19:51] <jam> I thought that was clear enough in the last email. Plus I gave you "tweak" anyway.
[19:52] <jam> markh: I had a question about getting paramiko into the installers. Are you doing something special to have it happen?
[19:52] <abentley> jam: I still figure that "tweak" doesn't count if you don't make all the changes suggested, and I haven't changed the use of bzrtools yet.
[19:53] <jam> abentley: I said that was "weird" but that "we may not have anything better"
[19:53] <jam> I was more bringing up the discussion than asking for a change
[19:54] <abentley> jam: Okay, but I said "Is this something you want fixed before this lands?" and you didn't reply.
[19:55] <jam> I probably missed that part
[19:55] <jam> sorry
[19:55] <abentley> np
[19:55] <abentley> In terms of discussion, do you have an idea what we should do?
[19:56] <jam> luks: I had a question about qbzr, if you have time
[19:56] <luks> jam: sure
[19:56] <jam> I'm trying to make sure I bundled the right version
[19:56] <jam> but I didn't see an 0.9.5 tag in the trunk repo
[19:56] <jam> do you know if it was added?
[19:57] <luks> um, I don't know, alexander did the release, but I can check
[19:57] <luks> but it's probably always safest to grab the tarball
[19:58] <jam> luks: I just saw this:
[19:58] <jam>   521 Alexander Belchenko       2008-11-03 [merge]
[19:58] <jam>       merge 0.9.5 release
[19:58] <jam> And I'd rather not have to download tarballs for everything for every release
[19:58] <jam> it is easier to do a "bzr branch -r tag:..." when necessary
[19:58] <luks> yes, the tag seems to be in the m erged branch
[19:58] <luks> release-X.Y.Z as usual
[20:10] <abentley> thumper: How's it going?
[20:10] <thumper> morning abentley
[20:11] <thumper> still knackered
[20:11] <thumper> but not as bad as yesterday
[20:11] <abentley> thumper: Progress is progress, I guess.
[20:11] <thumper> abentley: do you know when 1.9 release is?
[20:12] <abentley> thumper: Bazaar 1.9?  No, not offhand.
[20:12] <abentley> thumper: Probably this week, though.
[20:12]  * thumper nods
[20:13] <jam> thumper: 1.9rc1 was 2008-10-31, so 1.9 would be expected on 2008-11-07
[20:13] <thumper> thanks jam
[21:02] <NfNitLoop> Hrmmm.
[21:03] <NfNitLoop> bzr-svn seems to *explode* in memory usage when I try to pull one particular revision in particular.
[21:03] <NfNitLoop> even though only a few lines were changed.
[21:03] <NfNitLoop> The only thing I can see is that the lines are really long?
[21:04] <lifeless> NfNitLoop: gigabytes long?
[21:04] <NfNitLoop> (811 characters)
[21:04] <NfNitLoop> no. :)
[21:04] <lifeless> how big are the files these lines are in?
[21:04] <NfNitLoop> hmm, not too big, I don't think, let me see...
[21:06] <NfNitLoop> heh.
[21:06] <NfNitLoop> 20k.
[21:06] <lifeless> no alarm bells so far
[21:07] <NfNitLoop> still, I can `bzr pull -r 510`, but `bzr pull -r 511`  nearly brings down my laptop.
[21:07] <NfNitLoop> Unfortunately this against our non-public repo... trying to figure out how to reproduce this.
[21:08] <NfNitLoop> Ooooh, wait.
[21:08] <ianm_> is it easy to step back in time through commits?
[21:08] <NfNitLoop> -r 511 might not necessarily be (svn)r511, eh?
[21:09] <NfNitLoop> since I'm only grabbing one of the sub-projects?
[21:09] <mDuff> ianm_, the short answer is "yes"; the long answer is "what, exactly, do you mean by that?"
[21:09] <ianm_> mDuff: I see this when I start my app: Gtk-CRITICAL **:gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
[21:10] <mDuff> ianm_, trying to figure out at what poit that issue was reproduced?
[21:10] <ianm_> mDuff: right
[21:10] <ianm_> it was recent
[21:10] <mDuff> ianm_, you might find the bzr-bisect plugin interesting.
[21:10] <NfNitLoop> aha, yes, it's a different revision in svn... which appears to be huge. :p   that makes more sense.
[21:11] <ianm_> is there anything like "bzr previous" that I can do repeatedly until the warning disappears?
[21:12] <NfNitLoop> ianm_: There's "uncommit"... but make sure you do it in a branch. :p  (it uncommits and discards your history one revision at a time)
[21:12] <NfNitLoop> ianm_: bisect may help you.
[21:12] <NfNitLoop> it does a binary search through your revisions. :)
[21:12] <NfNitLoop> maybe faster than doing it 1 at a time.
[21:13] <ianm_> it must be within the last 20 commits
[21:13] <ianm_> so I currently have a working directory where when I commit it also pushes to launchpad
[21:14] <mDuff> ianm_, bisect really is the right tool for the job; otherwise, you're just doing "bzr co -r [number]" or some variant thereof.
[21:14] <ianm_> can I "bzr branch /that/directory" then use bzr uncommit there?
[21:14] <mDuff> ianm_, checkout -r [number] is really more the right tool than branch+uncommit
[21:15] <ianm_> mDuff: hmm ok.  can I do that locally?  a launchpad checkout takes like 5 minutes
[21:15] <mDuff> ianm_, yes, that's a local operation
[21:15] <mDuff> ianm_, do it within your existing tree
[21:16] <ianm_> mDuff: all within my one working directory?
[21:16] <mDuff> ianm_, well, you can just do a lightweight checkout of a specific revision into a different directory... that'd probably be the fastest+safest approach
[21:17] <ianm_> mDuff: yeah that sounds good.  how do you do a lightweight?
[21:17] <NfNitLoop> branch --lightweight
[21:17] <NfNitLoop> uhrmm... but don't uncommit from there. :)
[21:17] <NfNitLoop> (does that work from a lightweight co, even?)
[21:19] <mDuff> ianm_, ie. bzr checkout --lightweight -r7 ~/myproject ~/myproject.r7
[21:19] <mDuff> ianm_, ...but really, bisect is The Right Tool.
[21:19] <ianm_> is bisect easy to setup?
[21:20] <mDuff> ianm_, you should be able to just check it out into your ~/.bazaar/plugins/ directory
[21:20] <NfNitLoop> lifeless: aha.  Yep, turns out that someone had checked in a 1G file.  Sooo, guess that repo's not a good use-case for bzr. :p
[21:20] <mDuff> ianm, bzr co http://bzr.licquia.org/bzr-bisect/trunk/ ~/.bazaar/plugins/bisect
[21:21] <mDuff> ianm_, then see "bzr bisect --help".
[21:23] <lifeless> NfNitLoop: we're working on that, but yeah, youll need a couple of gb to check it out today
[21:25] <NfNitLoop> I've got 2G RAM...
[21:25] <NfNitLoop> so it looks like I'll need more than a couple. :p
[21:25] <ianm_> mDuff: I found the commit, now I just have to figure out what's wrong about the glade file change, ugh ;)
[21:26] <ianm_> mDuff, ﻿NfNitLoop: thanks for your help!
[21:26] <mDuff> ianm_, cool. bisect is nifty, eh? :)
[21:27] <ianm_> I actually just did a bunch of local co -r but I imagine it is ;)
[22:10] <lifeless> spiv: so, I would guess a mis-selection on pushing (CHKRepository, RemoteRepository)
[22:11] <lifeless> spiv: which new repositories avoid because of sprout getting delegated to the FS level
[22:12] <poolie> lifeless: hi
[22:12] <poolie> my net access seems to be up but flaky
[22:12] <lifeless> poolie: cool; we did a standup
[22:12] <poolie> good for you
[22:12] <lifeless> poolie: I mailed the notes to the list
[22:13] <poolie> i would have said: i did everyone's reviews; today i'm going to fix the internet ;-) and then i think try inter-historic-tree diffs in CHK
[22:13] <poolie> also, that needs a better name
[22:13] <lifeless> true
[22:18] <jam> poolie: I built a new win32 installer today, learning from user feedback. I'm wondering if I should completely remove the old installer, or if just naming the new one "-2" is sufficient?
[22:18] <poolie> is there any benefit to keeping the old one?
[22:18] <poolie> i can't see any
[22:19] <poolie> unless someone wants to compare its bugs or something, and if we really want that you still have a copy
[22:19] <poolie> i would call the new one -2 or something though
[22:19] <poolie> to make it clear
[22:20] <poolie> how about that?
[22:21] <jam> yeah, I'm calling it -2, I just wondered about deleting the old download file
[22:21] <jam> probably best  to delete it so we don't have people wondering which one to grab
[22:22] <poolie> just delete it
[22:22] <jam> I just had LP timeout while trying to upload, which is the first time it happened for me
[22:22] <jam> but hopefully it will go through this time.
[22:22] <jam> poolie: btw, I think the reason that rebooting worked for you is because you have the regular "Subversion" binaries installed
[22:23] <jam> and it just got added to the path as part of the reboot
[22:23] <jam> can you check?
[22:30] <poolie> jam, i'm pretty sure i don't have svn on that machine
[22:31] <poolie> can check
[22:46] <poolie> jam, i don't have svn there
[22:46] <poolie> it's a nearly fresh vm
[22:51] <jam> interesting, considering I'm 90% sure that the dll isn't bundled in that installer.
[22:52] <poolie> what was the name, libsvn-1.dll
[22:52] <jam> libsvn_client-1.dll IIRC
[22:53] <poolie> maybe there is some kind of negative cache
[22:53] <poolie> if you see what i mean
[22:53] <poolie> that bzr-svn *shouldn't* work on this machine, but it's normally failing quietly
[22:53] <poolie> now i'm getting that message again
[22:54] <poolie> jam, if we're shipping the bzr-svn plugin but not the libraries it uses that seems potentially problematic
[22:55] <jam> poolie: yeah, I manually added the libs in the -2 installer
[22:55] <jam> I don't understand why they aren't coming in automatically like all the other ones
[22:55] <poolie> oh i see
[22:56] <jam> And now, I managed to install it, and I get the icon in the systray
[22:56] <jam> but when I run I get:
[22:56] <jam> "ImportError: DLL load failed with error code 193"
[22:56] <jam> not sure what that is yet
[22:56] <poolie> i would guess what we're seeing as a windows vista feature, that if loading a dll fails the user sees a dialog with no intervention from the application
[22:57] <lifeless> the windows runtime linker will show an error if a dll for an .exe can't be found
[22:57] <lifeless> dynamic loading doesn't do this
[22:57] <jam> well, running the 'bzr.exe' directly isn't complaining
[22:57] <jam> (weird network fault)
[22:58] <jam> anyway, bzr-svn seems good in the new install
[22:58] <poolie> well, that's not consistent with what we're seeing here
[22:58] <jam> I don't know why TortoiseBZR is failing to run the "settings" page
[22:58] <poolie> jam, i'll try it out
[22:58] <lifeless> jam: PATH may not match between the console and gui environments
[22:58] <lifeless> jam: try logging the user out and in?
[22:58] <jam> could be. I explicitly chose not to add 'Bazaar' to my path, because I wanted to unistall
[22:58] <poolie> jam, i could run the settings from the tray icon
[22:59] <poolie> i did add it to my path
[22:59] <jam> ok, so it might just be that
[23:02] <poolie> i'm waiting for more windows updates :/
[23:02] <poolie> after that i'll upgrade it
[23:09] <lifeless> garh, its summer
[23:09] <lifeless> I can tell because the noise pollution is insane
[23:09] <poolie> barely
[23:19] <disturbedsaint> markh, are you there?
[23:19] <markh> disturbedsaint: hi
[23:19] <disturbedsaint> hi
[23:20] <disturbedsaint> was wondering if the different menu's when clicking on the tray-icon work for you
[23:20] <disturbedsaint> seems like tbzr has to be in the global PYTHONPATH
[23:21] <markh> umm - that is possible for the tbzrcache process actually
[23:21] <markh> but just start it manually and you will be OK
[23:22] <poolie> so if you give a lp: url, it's the resolved form of that url that's remembered as the parent etc?
[23:22] <james_w> poolie: yeah
[23:22] <james_w> Aaron recently proposed to change that I believe
[23:22] <disturbedsaint> markh, when launching from the command prompt it does indeed work
[23:23] <disturbedsaint> just wanted to know if it's intentional the way it is
[23:23] <markh> it would be possible to hack the shell extnesion code to set PYTHONPATH before launching the tbzrcache process
[23:23] <markh> and its not a problem in a binary build
[23:23] <james_w> the only downside I can thing of is that you need whatever directory service plugin installed to be able to resolve the parent, but I don't think that's too onerous
[23:24] <markh> while I'm developing, I always run tbzrcache manually so I can see the output
[23:24] <james_w> poolie: I met with Mark, some of lp-code, and others last week. Something like Russell's issue came up, and Mark was talking about how we could try and improve this.
[23:25] <disturbedsaint> if it isnt a problem in the binary builds then it's fine :)
[23:25] <james_w> he suggested storing both what the user asked for, and what they got, which allows you to later make decisions about what you should do
[23:25] <poolie> james_w: the problem of people renaming branches?
[23:25] <james_w> not only when branches move, but when they diverge and the like
[23:26] <james_w> poolie: it was actually forks in development, but I think it still applies
[23:26] <james_w> the UI for presenting this to the user and finding out what action they wanted to take wasn't discussed, but it's an interesting idea
[23:26] <markh> disturbedsaint: have you ever seen a "would recurse to death" error?  If so, try updating the tbzr branch - I think I nailed that a couple of days ago.
[23:26] <james_w> and would probably help in some situations
[23:27] <markh> bb in 20
[23:27] <disturbedsaint> actually I haven't
[23:27] <disturbedsaint> though I do seem to lose the overlays on directories after a while
[23:27] <disturbedsaint> still trying to find out why that happens
[23:27] <james_w> poolie: thumper and jml were there, and they might have a different of how this was supposed to work, or what it was supposed to solve.
[23:27] <disturbedsaint> Like bug 284511 (https://bugs.launchpad.net/tortoisebzr/+bug/284511)
[23:28] <disturbedsaint> Thats the only real issue I'm having atm
[23:33] <thumper> james_w: what was the question?
[23:36] <poolie> hi thumper
[23:36] <poolie> we should talk sometime
[23:36] <thumper> hi poolie
[23:36]  * thumper needs coffee badly
[23:36] <poolie> :)
[23:36] <thumper> poolie: how about we talk this afternoon?
[23:36] <poolie> yay jetlag
[23:36] <poolie> sure
[23:36] <thumper> I'm about to go and get coffee
[23:36] <poolie> are you home now?
[23:36] <thumper> yes
[23:36] <thumper> it snowed here!
[23:42] <markh> disturbedsaint: when that happens check .bzr.log - you should find an error there - and most likely is the "would recurse to death" error.
[23:44] <disturbedsaint> markh: happened the last time 1,5hours ago
[23:45] <disturbedsaint> But I got the source (branch) about 7 hours ago, so maybe there's another reason for it happening
[23:45] <disturbedsaint> The error is "raise RuntimeError("Status of '%s' would recurse to death" % member)"
[23:49] <markh> disturbedsaint: I only pushed it minutes ago :)
[23:49] <markh> that is the error I think is now fixed
[23:50] <disturbedsaint> ah, I see :)
[23:59] <disturbedsaint> markh, I'll give it a try tomorrow