[01:34] <flutherben> Hi all. Hope someone can help me here. I upgraded my box, and now I'm having trouble deploying. When I run "bzr revno http://mydomain/myrepos" I get a transport error
[01:34] <flutherben> specifically: bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden)
[01:38] <flutherben> nevermind--this is a capistrano error
[03:04] <lifeless> spiv: hai
[03:07] <mkanat> Okay, if a merged merge proposal didn't fix an issue, do I submit a new one or just update the existing merge proposal?
[03:07] <lifeless> new one
[03:07] <lifeless> reference the old if discussion in it is still relevant
[03:08] <mkanat> lifeless: Okay, thanks.
[03:10] <awmcclain> I have a pending merge; I've bzr reverted a file because i needed to temporarily get rid of it. Is there a way to now fetch that file again from the other branch without checking in beforehand?
[03:11] <lifeless> awmcclain: yesish
[03:11] <awmcclain> oh, i like ish.
[03:11] <lifeless> awmcclain: first, a note - if you want to temporarily get rid of things like that, use 'shelve'
[03:11] <spiv> lifeless: hey
[03:11] <lifeless> e.g. bzr shelve filename --all
[03:11] <awmcclain> lifeless: Interesting. Even on a pending merge?
[03:11] <lifeless> awmcclain: if the file on the other branch wasn't changed in your current branch, you can do 'bzr revert -r branch:pathtootherbranch filename'
[03:12] <awmcclain> lifeless: That's correct. The file is a new file.
[03:12] <awmcclain> Introduced by the merge
[03:12] <lifeless> awmcclain: if it *was* changed in your branch, you can't trivially get the merge back, but donig the revert above and then looking at the diff would let you figure things out
[03:12] <awmcclain> No, it wasn't changed. Just added. Ok. Great! Thanks
[03:12] <lifeless> awmcclain: yes; shelve filename == revert filename, except you can get it back more easily.
[03:13] <awmcclain>  good to know!
[03:13] <lifeless> awmcclain: where shelve != revert, is when you just do 'bzr revert', because that discards the pendnig merge.
[03:13] <awmcclain> Didn't shelve use to be a plugin?
[03:13] <lifeless> awmcclain: yes
[03:13] <awmcclain> And now is part of bzr?
[03:13] <lifeless> yes
[03:13] <awmcclain> Wonderful. Thank you!
[03:14] <lifeless> spiv: fud ? early avo perhaps ?
[03:15] <spiv> Hmm, could work.  Here or there?
[03:15] <awmcclain> lifeless: That revert command worked perfectly. Thank you
[03:15] <lifeless> spiv: sure
[03:16] <lifeless> spiv: mt colah's food facilities are, uhm, limited ;)
[03:16] <lifeless> awmcclain: my pleasure
[03:17] <spiv> lifeless: ok, so Hornsby somewhere.  Maybe name a time to meet at the fountain?
[03:18] <lifeless> spiv: looking @ train timetables
[03:19] <lifeless> dear chityrail, your website is terrible
[03:20] <lifeless> 1:30 ?
[03:20] <spiv> Sounds good!
[03:59] <lifeless> james_w: patch done
[04:09] <lifeless> spiv: omw
[04:09] <lifeless> be there in 10-15
[04:10] <mkanat> mwhudson: https://code.edge.launchpad.net/~mkanat/loggerhead/synchronize-lru_cache/+merge/24651
[06:44] <lifeless> spiv: do you need a review on that patch?
[06:45] <spiv> Oh yeah.  Just a sec.
[06:46] <spiv> lifeless: <https://code.edge.launchpad.net/~spiv/bzr/repo-refresh-data-574236/+merge/24653>
[06:52] <lifeless> speaking of cameras
[06:52] <lifeless> http://gizmodo.com/5529710/59-fiercely-focus-stacked-photos
[06:56] <spiv> Cute!
[06:59] <lifeless> spiv: reviewed.
[06:59] <lifeless> I wants tweak.
[07:03] <spiv> lifeless: ok
[07:05] <lifeless> you may find (I hope not) that when you add the all_revision_ids call (and presumably one after or something :P) that it breaks.
[07:05] <lifeless> spiv: I didn't say this in the review, but hopefully its obvious, that you'll want a commit already present, so actual data merging happens.
[07:06] <spiv> Fair enough.
[07:07] <spiv> I did consider constructing a more evil test where I make stream sink and source, and then arrange for refresh_data (and the concurrent fetch) to be done part-way through inserting the stream.
[07:08] <spiv> But the effort involved didn't seem justified.
[07:08] <lifeless> I don't expect that to be interesting
[07:08] <lifeless> because the disk atomicity is well established
[07:09] <lifeless> and the various bits are pretty well established
[07:09] <lifeless> but still - nice thinking ;)
[07:10] <spiv> Right :)
[07:37] <vila> hi all
[07:43] <spm> yo vila!
[07:47] <kizzo> I get an error when trying to use bzr-git to branch the git repository found on here: http://sourceforge.net/projects/unison/develop
[07:47] <kizzo> On that page, the git repo url is "git://unison.git.sourceforge.net/gitroot/unison/unison"
[07:47] <kizzo> The command I try is "bzr branch git://unison.git.sourceforge.net/gitroot/unison/unison"
[07:48] <kizzo> The error I get is "bzr: ERROR: exceptions.TypeError: expected string or buffer"
[07:48] <lifeless> kizzo: file a bug at bugs.launchpad.net/bzr-git
[07:48] <jelmer> kizzo: you need a newer version of bzr-git
[07:48] <kizzo> [ there is more to the error message, but it just explains that it's an internal error, and how to file a bug.
[07:48] <jelmer> kizzo: urllib's behaviour changed in a minor python release and broke bzr-git
[07:49] <kizzo> Alrighty, I'll try and update things.
[07:53] <kizzo> Hmm, I don't know how I would update that though - I ran aptitude update and aptitude safe-upgrade on my Ubuntu Lucid, but I'm already up to date.
[07:58] <kizzo> I guess I'm going to have to grab the latest tarball from the main bzr-git site.
[07:58] <lifeless> jelmer: what version fixes it ?
[07:59] <jelmer> IIRC 0.5.0
[07:59] <kizzo> I'm not sure - the latest is 0.5.0, and the one installed on my system is 0.4.3
[08:00] <lifeless> jelmer: I suggest you put a SRU for bzr-git together _asap_ then.
[08:00] <kizzo> Should I uninstall my version first, before doing "python setup.py install" for the new version?
[08:00] <lifeless> kizzo: grab the deb package for bzr-git from debian
[08:03] <kizzo> lifeless: I double-clicked the deb file to install it, but it says error: Error: Dependency is not satisfiable: python-dulwich (>= 0.5.0~)
[08:03] <kizzo> Boo.
[08:04] <lifeless> kizzo: that one too :P
[08:04] <kizzo> Yeah I started figuring - dang.
[08:09] <kizzo> Things are working now, thanks.
[08:09] <kizzo> The command works now.
[08:09] <jelmer> lifeless: I won't have time for that before UDS unfortunately.
[08:10] <lifeless> jelmer: its actually pretty straight forward to start one - are you positive you don't have time ?
[08:11] <lifeless> jelmer: how big is 0.4.3->0.5.0; is grabbing all of it feasible ?
[08:13] <jelmer> lifeless: it's probably too big for a SRU
[08:13] <lifeless> jelmer: is a backport of that fix feasible ?
[08:14] <jelmer> lifeless: it's feasible, but nontrivial. The last SRU I did took me an hour or two that I don't have right now (on leave during the last days of the week).
[08:14] <lifeless> sure
[08:14] <lifeless> do you remember the bug number of the original report ? or a good search string ?
[08:15] <lifeless> actually, bug 556968 is it
[08:19] <kizzo> Should I post my solution there?
[08:20] <lifeless> no, I'll note that down.
[08:20] <kizzo> Just to mention what I did to fix it.
[08:20] <kizzo> Alrighty.
[08:21] <lifeless> spiv: nb: bzr-git(ubuntu) bugs may not be visible to jelmer - you probably want to 'affects project' on them
[08:21] <lifeless> spiv: I refer to https://bugs.edge.launchpad.net/ubuntu/+source/bzr-git/+bug/532192
[08:22] <spiv> lifeless: ah right.
[08:22] <lifeless> (which I've just done)
[08:22] <spiv> I don't tend to look to closely at if a bug is filed on distro. vs. upstream
[08:22] <lifeless> indeed
[08:22] <lifeless> [me neither, not explicitly anyhow]
[08:45] <spiv> Hmm, it's unfortunate that a test that does "tree = self.make_branch_and_tree('foo'); tree.commit('blah')" can't simply have self.make_branch_and_memory_tree substituted without adding a few lines of boilerplate.
[08:46] <lifeless> spiv: agreed
[09:26] <mtaylor> lifeless: can you think of any decent reason why I can't use bzrlib from jython?
[09:27] <mtaylor> import bzrlib just worked
[09:27] <lifeless> mtaylor: someone is working on it.
[09:28] <lifeless> mtaylor: file bugs.
[09:28] <mtaylor> lifeless: oh neat
[09:28] <bialix> heya
[09:28] <mtaylor> lifeless: as in "just try to use it normally and file bugs" or - go find the jython-bzr project and file bugs there?
[09:28] <lifeless> mtaylor: file them on bzr itself
[09:28] <mtaylor> cool
[09:29] <mtaylor> now - to solve jython maven integration...
[09:30] <lifeless> hi bialix
[09:34] <bialix> vila: ping
[09:34] <vila> bialix: pong
[09:34] <bialix> bonjour vila
[09:34] <bialix> I'm not quite understand your review
[09:34] <vila> bialix: which part ?
[09:34] <bialix> For all *files* you check that the *directory* is not a branch. <-- what do you mean?
[09:35] <bialix> and I don't understand this: The correct way to do this would be to prune the directory and *all* of its content when it's first processed.
[09:35] <bialix> at all
[09:35] <vila> bialix: if you have a nested branch with thousands of files, they are all included in the list you're processing
[09:35] <bialix> vila: no
[09:35] <bialix> this is not correct
[09:36] <vila> bialix: you rely on tree.extras() right ?
[09:36] <bialix> only the directory with the branch will be in the list
[09:36] <vila> bialix: no
[09:36] <vila> at least I don't think so reading the code
[09:36] <bialix> vila: I'm relying on what clean-tree do before
[09:37] <vila> tree.extras() filters out all the files present in the inventory but walks the whole tree
[09:37] <vila> bialix: I didn't say you didn't :)
[09:38] <bialix> vila: http://pastebin.com/WHDxuCc9
[09:38] <bialix> there is no entries from nested branch
[09:39] <vila> bialix: re-read my review, I'm not saying your code is incorrect,
[09:39] <bialix> vila: I don't see any reliable way to filter out files, other than using isdir() check
[09:39] <vila> I say it will process too much
[09:39] <bialix> it will process the list twice
[09:39] <vila> bialix: once you know a dir is a branch, you don't need to even look at the dir content
[09:40] <bialix> because actual delete code also checks for file/dir
[09:40] <bialix> vila: there is no dir content in the deletables list
[09:40] <bialix> only dir itself
[09:41] <vila> bialix: ??? you mean if you have '.' you don't have './foo' ?
[09:41] <bialix> http://pastebin.com/1SHdFxaW
[09:41] <bialix> I mean if I have foo, I won't have foo/bar
[09:43] <vila> bialix: even in deletables ?
[09:46] <bialix> in my understanding bzr won't recurse into ignored/unknown
[09:47] <vila> bialix: !
[09:47] <bialix> ?
[09:47] <vila> bialix: you're right !
[09:48] <bialix> ok
[09:49] <vila> bialix: sorry for the noise :)
[09:49] <vila> bialix: may be worth a comment :)
[09:50] <vila> bialix: ' bzr won't recurse into ignored/unknown' captures this right
[09:51] <bialix> okay, will do
[09:52]  * bialix updating the patch based on the review of vila and partm
[09:52] <bialix> vila: what should I do for backporting the patch to 2.1 once it will be approved?
[09:52] <bialix> who is in charge?
[09:53] <spiv> bialix: there's no-one specifically in charge
[09:53] <spiv> bialix: simplest is probably for you to make the backport and propose it for merging.
[09:53] <bialix> so I just will need to file a mp against 2.1, that's all?
[09:53] <bialix> ok
[09:53] <spiv> Right.
[09:54] <bialix> vila: ok, so there is still a problem
[09:55] <bialix> if foo is unversioned, and foo/bzr is a branch then we happily remove it
[09:55] <bialix> foo/bar
[09:55] <bialix> (something strange in the fact that both a and z are so close on the keyboard)
[09:56] <bialix> but I don't think we want to handle this due the performance as you say
[09:56] <vila> bialix: it would have been better to start by targeting 2.1, releases branches are regularly (handwaving) merged into trunk
[09:57] <bialix> I can rebase, perhaps
[09:57] <vila> bialix: urgh :)
[09:57] <bialix> :-)
[09:57] <vila> bialix: kidding, yes, now, rebase is probably the easiest
[09:58] <bialix> but I don't mind just cherrypick patch to 2.1
[09:58] <spiv> I just cherrypick in that situation.
[09:59] <vila> bialix: regarding branches 'hidden' below ignored or unversioned, a FIXME would be welcomed as well
[09:59] <bialix> vila: http://pastebin.com/rg9h5F1k
[10:00] <bialix> ?
[10:00] <vila> bialix: won't skip is unclear, 'we will delete the nested branch' is more explicit
[10:01] <bialix> http://pastebin.com/B3RhHxgh
[10:02] <bialix> vila: should I add note about skipped bzrdirs as partm suggested?
[10:02] <bialix> sorry, parthm
[10:05] <vila> bialix: well, the second reviewer may have a different opinion but I'll land this proposal and make a new one for that instead...
[10:06] <vila> bialix: except if it's really trivial to add
[10:06] <GaryvdM> Hi all
[10:06] <vila> hey GaryvdM !
[10:06] <GaryvdM> I'm looking at https://code.edge.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537
[10:06] <vila> GaryvdM: great
[10:06] <bialix> vila: the problem in the correct wording
[10:07] <GaryvdM> Is there a guide anywhere to runing the test suit under wine?
[10:07] <bialix> *is
[10:07] <bialix> GaryvdM: heya!
[10:07] <GaryvdM> Hi bialix
[10:07] <GaryvdM> Hi vila
[10:07] <vila> bialix: start with Martin's suggestion (was it bzr control component ?), that can be refined later or even tweaked based on the second review
[10:18] <bialix> I've tested it manuall and I don't like how it mingle with the list of paths to delete
[10:20] <bialix> lp is rwad-only, does it means I can't push my branch?
[10:20] <bialix> lp is read-only, does it means I can't push my branch?
[10:23] <GaryvdM> bialix: yes
[10:26] <GaryvdM> Seem like we can't pull either
[10:29]  * GaryvdM is running "wine c:\\python26\\python bzr selftest" :-)
[10:30]  * bialix hopse GaryvdM has very fast hardware, otherwise he can go for lunch and maybe dinner
[10:30] <GaryvdM> ah - with -s bzrlib.tests.test_diff
[10:34] <funkyweasel> Good morning.  I recently upgraded to Ubuntu Karmic and bzr 2.0.2.  Unfortunately our repository server is stuck on Hardy / bzr 1.3.1.  I know find branching and status hellaciously slow.
[10:34] <bialix> apt-get?
[10:36] <GaryvdM> funkyweasel:  Are you running a bzr smart server on the Hardy server?
[10:36] <funkyweasel> We're not able to upgrade the repo server at this time.  Is it a known issue that newer versions of bzr have difficulty with branches generated by older versions of bzr?
[10:37] <funkyweasel> GaryvdM: No.  But it sounds like a good idea when we move the repo server to the new Ubuntu LTS.
[10:38] <GaryvdM> funkyweasel:  Please tell us what repo formats the branch on the server is, and the branch on your pc is.
[10:39] <GaryvdM> funkyweasel:  bzr info -v
[10:41] <funkyweasel> GaryvdM: repo: Packs containing knits without subtree support, local: Knit repository format 1.  Noted that it took about a minute to count the revisions on local.
[10:42] <bialix> funkyweasel: you have old format in local tree
[10:42] <bialix> `bzr upgrade --pack-0.92` on local
[10:42] <funkyweasel> bialax: Yes, I thought that too.  But if I upgrade using 2.0.2 it becomes incompatible with the repo server.  I can no longer commit.
[10:43] <bialix> funkyweasel: I've wrote format1 plugin that force pack-0.92 as default
[10:43] <funkyweasel> Now that I have not tried.
[10:43] <bialix> funkyweasel:  upgrade --pack-0.92
[10:43] <bialix> there is explicitly defined the format
[10:43] <bialix> you have to avoid upgrade to anything newer than --pack-0.92
[10:44] <bialix> or --rich-root-pack
[10:45] <GaryvdM> funkyweasel:  -bialix: Please will you do me a favor:  Please run bzr selftest -s bzrlib.tests.test_diff.TestEncodedDiffFromTool in this branch: lp:~vila/bzr/523746-difftool-file-names
[10:45] <GaryvdM> funkyweasel:  Sorry last msg not for you
[10:45] <GaryvdM> bialix:  I get this error in wine: http://paste.ubuntu.com/427530/
[10:46] <bialix> GaryvdM: codehosting is offline
[10:46] <GaryvdM> bialix: oh forgot that.
[10:46] <bialix> bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; (10061, 'Connection refused')
[10:47] <GaryvdM> bialix: I'm not sure if it's wine specific
[10:47] <bialix> once lp going back online, ping me
[10:47] <GaryvdM> bialix:  thanks.
[10:48] <GaryvdM> vila: any idea how to fik http://paste.ubuntu.com/427530/ ?
[10:48] <GaryvdM> *fix
[10:48] <vila> GaryvdM: let me check, but from memory the last commit in my branch was trying a different approach and didn't pass tests as I wanted some feedback first
[10:49] <GaryvdM> vila: Tests work in ubuntu, but not wine.
[10:50] <vila> oh, failure while *reporting* the failure, different bug, not sure this branch includes the related fix
[10:52] <vila> GaryvdM: Hmm, I was thinking about reno 5163 on bzr.dev but the fix seems to be present :-/
[10:53] <GaryvdM> vila: Ok - If don't know - let me debug a little
[10:59] <GaryvdM> launchpad code hosting back up
[11:06] <anddam> hello
[11:08] <parthm> anddam: hi
[11:08] <anddam> I'm trying to figure out the difference between checkout and branch
[11:08] <anddam> I read "Core concepts"
[11:10] <anddam> http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html#centralized says "They run bzr update to get their checkout up-to-date, then bzr commit" but step 1 is checkout
[11:10] <anddam> is it done only once?
[11:10] <parthm> anddam: checkout are similar to traditional svn checkout
[11:10] <anddam> ok I'm fine with that
[11:11] <anddam> a branch is a "ordered series of revisions", how does that make any difference?
[11:11] <parthm> anddam: when you commit to a checkout, it is committed to the place from where you checked out. branch commit is local.
[11:11] <anddam> so "branch" is like "my own branch"
[11:12] <parthm> yes. branch is your own. checkout is more like central ... with the place from which you checkout being the center.
[11:12] <anddam> while a commit to a checked out working dir would write on main development repository (or wherever the working dir has been checked out from)
[11:12] <anddam> thanks
[11:12] <parthm> yes.
[11:13] <parthm> with checkout you also have the --lightweight option which is very close to svn/cvs
[11:13] <parthm> with a branch you will need to either push, or merge into trunk/mainline. checkout commit goes to mainline by default.
[11:14] <parthm> "bzr help checkouts"
[11:17] <bialix> GaryvdM: I've ran the test; he same error here
[11:17] <bialix> GaryvdM: I've ran the test; the same error here
 lifeless: can you think of any decent reason why I can't use bzrlib from jython? <- see https://lists.ubuntu.com/archives/bazaar/2009q4/063999.html
[11:23] <a212901390231901> now I'm off out.
[11:25] <GaryvdM> bialix:  thanks.
[11:26] <bialix> hi a212901390231901 Ж-)
[11:26] <bialix> hi a212901390231901 :-)
[11:27] <a212901390231901> that makes a pretty good monster smilie
[11:28] <bialix> I'd say it was insects smilie
[11:28] <bialix> in russian
[11:28] <funkyweasel> bialax: This upgrade is taking an extremely long time.
[11:29] <bialix> poor lp, it seems to be very heavy loaded
[11:29] <bialix> funkyweasel: maybe you have a very big history?
[11:29] <funkyweasel> bialax: I do.  But bzr 1.3.1 seemed to cope with it much better.
[11:29] <a212901390231901> it's caught up with bzr.dev but not my branch for review yet
[11:30] <bialix> sometimes it's much easier just to get the new branch from the server, because it seems you have it in decent format there?
[11:30] <funkyweasel> Oh.
[11:31] <funkyweasel> It's spent a while 'checking repository format'
[11:31] <bialix> what?
[11:31] <funkyweasel> That's the stage the upgrade is on.
[11:31] <bialix> do you have local branch, not a checkout?
[11:32] <a212901390231901> bialix, just to clarify on your ctypes-users question, cdll['foo'] code calls getattr which forwards to the same method that cdll.foo uses
[11:32] <a212901390231901> and now I really have to go.
[11:32] <bialix> ok
[11:33] <funkyweasel> bialix: I branched from the local copy and set it upgrading to --pack-0.92 with the intention of then pushing it to the repo server, and binding to that version on the repo server.
[11:33] <bialix> funkyweasel: how many revisions/files in the branch?
[11:33] <funkyweasel> In the vague hope I'll get back the old performance I had a week ago on my hardy/bzr1.3.1 box
[11:34] <funkyweasel> Sadly it's 3976 revisions.  It's an old tree.
[11:34] <bialix> it's not very big, I think
[11:35] <bialix> can you look into .bzr.log and see what it doing actually?
[11:35] <funkyweasel> I'm quite frustrated at how the performance has plumeted since upgrade.
[11:35] <bialix> vila: ^
[11:36] <bialix> any hints?
[11:37] <funkyweasel> bialax: Ah,  xxxx.yyy opening working tree '{branch path}'
[11:38] <funkyweasel> xxxx is 3058, yyy is 536, both increasing rapidly.
[11:38] <funkyweasel> I noticed that it seems to go really quick except for the last 900 or so revisions.
[11:38] <bialix> xxxx.yyy is the timestamp
[11:39] <funkyweasel> Not revision number?
[11:39] <bialix> it seems there is multiple opening of working tree. strange. bug?
[11:39] <funkyweasel> bialix: I don't know.  Is 2.0.2 buggy then?
[11:40] <funkyweasel> Saddening.
[11:40] <bialix> bzr has revno either NNN or NN.B.K
[11:40] <bialix> there is 2.0.5 released
[11:40] <funkyweasel> It's really impacting my work flow.
[11:40] <bialix> can you upgrade from bzr PPA?
[11:40] <funkyweasel> I don't know.  Can I?
[11:41] <bialix> http://wiki.bazaar.canonical.com/DistroDownloads#Ubuntu
[11:41] <funkyweasel> At the risk of sounding horribly plaintive - I'd rather like it to work like it used to please.  But progress, I imagine...
[11:41] <funkyweasel> I'm on the latest for Karmic, my current distro on local box.
[11:42]  * bialix is not Ubuntu expert, sorry
[11:42] <funkyweasel> It's taken me nearly all morning to try and get a new branch.  This is highly inefficient.
[11:43] <funkyweasel> And this checking process is consuming 100%.  Which is also nice.
[11:43] <bialix> upgrade is one time operation
[11:44] <funkyweasel> bialax: True.  And it's typically worth it.
[11:44] <funkyweasel> It's odd how repo versions have broken between 1.3.1 and 2.0.2 though.
[11:45] <bialix> I can't comment this
[11:45] <bialix> 1.9 format is very nice
[11:46] <funkyweasel> The latest one is that?
[11:47] <jelmer> the latest format is 2a
[11:48] <GaryvdM> No - 2a is the latest format, but it is a rich root format, and so you wont be able to push from a 2a format to the format on your server
[11:48] <funkyweasel> Nice one.
[11:49] <funkyweasel> I think a lot of our problems will be solved once we push our repo server up to the latest Ubuntu LTS and upgrading the branches there.  Trick is 1. waiting for the LTS to be post-launch stable and 2. finding time to upgrade our repo server.
[11:51] <bialix> funkyweasel: are you upgrading standalone branch or branch in the sahred repo?
[11:52] <funkyweasel> bialix: Made a local dev branch from the local trunk branch.  Upgrading the local dev branch.  Which is why I am surprised it's taking so long.
[12:00] <funkyweasel> It's now taken over an hour on this upgrade.  Is this normal?
[12:05] <GaryvdM> funkyweasel:  Are doing "bzr upgrade --pack-0.92" - Is this normal > think so. It's a one time operation. Go get lunch :-)
[12:07] <funkyweasel> GaryvdM: Cheers man, and that's an excellent plan.  Unfortunately I have a script that does a mailout that needs to go out as soon as possible - it was due first thing this morning but the format was broken so we've delayed it til it can be fixed.  So... spending all morning trying to make bzr work at the speeds it used to has consumed the morning, pretty much.
[12:09] <GaryvdM> funkyweasel:  Sorry man
[12:10] <funkyweasel> No worries.  I should have known this would take a while and put up with the now-ball-crunching slowness of bzr2.0.2 on pre-RichRoot repos.
[12:10] <GaryvdM> funkyweasel: If you want to stop it, it upgrade creates a backup which you can restor.
[12:10] <GaryvdM> *restore
[12:11] <GaryvdM> The outer thing you can try:
[12:11] <funkyweasel> GaryvdM: True, but it's been going for so long that I don't want to quit it.  I've started working on the local copy of thetrunk so I can actually get something out soon.
[12:11] <GaryvdM> mkdir temp
[12:11]  * GaryvdM rather puts this into paste bin
[12:11] <bialix> funkyweasel: may I ask to send your notes to bzr ML about your experience when it finished?
[12:12] <bialix> feedback ftw
[12:13] <GaryvdM> funkyweasel:  You can try this: http://paste.ubuntu.com/
[12:14] <GaryvdM> bialix: Please check that for me ^
[12:14] <bialix> GaryvdM: do you want me to pasteyou what?
[12:15] <GaryvdM> Oh - sorry. This: http://paste.ubuntu.com/427580/
[12:15] <GaryvdM> This will, rather than upgrade the local copy, just refetch from the server, in the same format as the server.
[12:16] <GaryvdM> funkyweasel: ^
[12:16] <funkyweasel> bialix: Sure thing.  Will filter out lightly-stressed incuded btching on my part. :)
[12:16] <bialix> that's correct
[12:17] <funkyweasel> GarvydM: That looks promising.
[12:54] <GaryvdM> vila: could you please do a second review on https://code.edge.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/24483
[12:56] <parthm> GaryvdM: thanks for the review.
[12:57] <parthm> vila: just wanted to point out that line 64-65: unused "from bzrlib import tests" is now gone. i am waiting for branch refresh.
[12:58] <vila> parthm: just for context, is there some progress bar shown in that case ?
[12:59] <GaryvdM> vila: Yes, the progress bar shows bellow the message.
[12:59] <parthm> vila: the message (may take time) is shown. and in the next line the usual progress bar 'fetching revisions' etc. is shown.
[13:00] <vila> parthm: then I think the 'may take some time' is superfluous, do we use this elsewhere ?
[13:01] <parthm> vila: i think the intent is that for the user "checkout" indicates a fast operation (unlike, branch). however as checkouts are heavyweight by default they take the same amount of time.
[13:01] <parthm> vila: hence the message.
[13:02] <GaryvdM> parthm: Maybe: 'Copying history to "test". To checkout with out copying history, use --lightweight'
[13:02] <GaryvdM> *without
[13:03] <vila> parthm: I like Gary's suggestion. My point was that the progress bar *should* tell the user that it will take some time, and after a few seconds he should even feel how much (better than "some")
[13:04] <parthm> yes. thats fine by me. i will update and push.
[13:05] <vila> parthm: you have pqm rights now, right ?
[13:05] <vila> or did I goofed again ? :-D
[13:06] <parthm> vila: yes. thats working fine :)
[13:06] <GaryvdM> vila: :-)
[13:06] <parthm> vila: thanks.
[13:06] <vila> parthm: cool, so feel free to land
[13:06] <vila> parthm: I've approved
[13:06] <parthm> vila: sounds fine. i will update the user message and land it.
[13:07] <parthm> vila, GaryvdM: thanks guys.
[13:23] <sangi> when i try to do bzr push, getting an error like bzr: ERROR:parent directory of bzr+ssh:/the/path/of/remote/server/ does not exist
[13:23] <sangi> can anyone give solution for this error
[13:24] <GaryvdM> vila: Should I be going through the "Other reviews I am not actively reviewing" section of activereviews, or should I leave that?
[13:25] <GaryvdM> sangi:  Create the parent dir manually.
[13:25] <vila> sangi: --create-prefix
[13:25] <sangi> GaryvdM, how to create parent dir
[13:26] <vila> sangi: bzr help push, look for --create-prefix
[13:26] <vila> GaryvdM: that would be nice
[13:26] <sangi> vila, ok
[13:26] <GaryvdM> vila: oh - I didnot know about --create-prefix
[13:27] <vila> GaryvdM: haaa, too clikety-click GUI only guys :-P
[13:29] <GaryvdM> vila: all of the mp's that I have looked in that section have a review request to a specific person (typically lifeless.)
[13:29] <vila> GaryvdM: you're done then :-/ Or you can nudge lifeless  :-P
[13:30] <GaryvdM> vila: Ah - found one that needs a second review
[13:31] <vila> GaryvdM: don't forget to set the status to 'Approved' when you find (or make) one with 2 approved reviews
[13:31] <GaryvdM> vila: Or just submit to pqm ?
[13:31] <vila> GaryvdM: both :)
[13:31] <GaryvdM> ok
[13:35] <GaryvdM> vila: Don't you have a all hands this week?
[13:35] <vila> GaryvdM: no
[13:36] <vila> GaryvdM: there may be a some hands though :)
[13:52] <sangi> after pushing the edited source to the remote server using bzr push, the changes are not getting effected in the source which is there in the remote server
[13:54] <vila> sangi: yes, only the branch is updated, not the remote working tree, you want the push_and_update plugin
[13:56] <sangi> vila, how can i install it
[13:57] <GaryvdM> sangi: First, do you have ssh access to the remote server?
[13:57] <vila> sangi: like all other plugins ?? No wait, what OS are you on, what bzr version are you using ?
[13:57] <GaryvdM> push_and_update requires
[13:57] <GaryvdM> push_and_update requires that..
[13:58] <vila> sangi: and yes, Gary is right, do you have ssh access ?
[13:59] <sangi> vila, yes i have ssh access
[13:59] <sangi> bzr version is 1.1
[14:00] <sangi> vila, using debian
[14:01] <vila> sangi: 1.1 ??? wow, that's more than old, can't you find a more recent one ?
[14:02] <GaryvdM> sangi: I dont think that there is a debian package, so the easiest way to install it is:
[14:02] <sangi> vila ok i will install the latest
[14:02] <GaryvdM> cd ~/.bazaar/plugins
[14:02] <GaryvdM> bzr branch lp:bzr-push-and-update push-and-update
[14:02] <vila> sangi: anyway, it's a unix, so :  bzr lp:bzr-push-and-update  ~/.bazaar/plugins/push_and_update
[14:03] <vila> ghaaa, bzr *branch* of course
[14:03] <sangi> GaryvdM, ok
[14:03] <sangi> vila, ok
[14:04] <vila> hmm, may be not the best time to use lp :-/
[14:04] <vila> sangi: note the - and _
[14:05] <sangi> vila, ok
[14:05] <GaryvdM> ah - mine is wrong...
[14:08] <vila> sangi: so, quickly reading the code, 1.1 may be supported, give it a try, you get a new push-and-update command, the regular push receives hook (*this* may require a newer bzr) that will trigger the update if a remote working tree exists
[14:09] <vila> sangi: if all else fails, what this plugin does is: bzr push ; ssh <host> ; cd <right_place> ; bzr udpate
[14:10] <bialix> vila: do I need second vote on clean-tree patch?
[14:10] <bialix> thanks btw
[14:10] <vila> sangi: and the reason we don't update remote working trees is that... you generally have no working trees there and performance will be bad for most protocols
[14:10] <vila> bialix: ha, AFAIR you're still a core committer, based on that, no :-P
[14:10] <sangi> vila, ok
[14:11] <bialix> vila: yes, my retirement plan has failed.
[14:11]  * vila evil laugh
[14:12] <bialix> I hope you helps me to push it into pqm?
[14:12] <bialix> *help
[14:12] <GaryvdM> bialix: It's not to hard to setup pqm-submit
[14:13] <GaryvdM> bialix: it is worth it to.
[14:14] <GaryvdM> bialix: I can't see that it would be more difficult on windows.
[14:14] <bialix> GaryvdM: when I was core committer I've sent pqm mails manually
[14:14] <bialix> I'll delay installing pqm plugin till UDS
[14:15] <bialix> so smart people will helps me with word and deed
[14:15] <bialix> never mind my english
[14:16] <GaryvdM> bialix: I guess you will be able to do submit through launchpad web interface soon...
[14:16] <bialix> so I can procrastinate more ;-)
[14:16] <funkyweasel> Goodness me.  That upgrade is *still* going, nearly 3 hours later.
[14:16] <bialix> funkyweasel: it hurts to hear this
[14:17] <funkyweasel> I *do* think there's something seriously wrong with this version of bzr and my set up.  There's no way even a point-version should break things this badly.
[14:17] <a212901390231901> upgrade does take ages, when I upped bzr.dev it was a multi-hour thing
[14:18] <funkyweasel> This is less than 4000 revisions.  And it did not take this long under 1.3.1.
[14:18] <funkyweasel> Which, after all this, I am tempted to downgrade back to.
[14:19] <bialix> funkyweasel: I'd recommend 1.9 at least
[14:20] <bialix> but it doesnot matter much
[14:21] <funkyweasel> I think this upgrade has failed.  Nothing is appearing in .bzr.log now, and it keeps spinning on 'checking repository format'.
[14:21] <bialix> vila: I've set commit message: ``bzr clean-tree`` should not delete nested bzrdirs. (bialix, #572098)
[14:22] <bialix> is it what you asking me?
[14:22] <funkyweasel> Oh, but bzr is still consuming 100% cpu.  Which is nice.
[14:23] <vila> bialix: exactly
[14:25] <vila> funkyweasel: weird, what was the last thing mentioned in .bzr.log ?
[14:25] <a212901390231901> I've not been setting commit messages 'cos I don't know if they get the (person) annotation added automatically or not
[14:25] <a212901390231901> or if I should be adding them manually
[14:25] <vila> a212901390231901: they do
[14:26] <a212901390231901> but say, r5200 doesn't have any
[14:26] <GaryvdM> Hmm - wonder why pqm does not set --author
[14:26] <vila> a212901390231901: submitted by mail most probably, i.e. not using this field
[14:27] <funkyweasel> vila: 13231.056  opening working tree '{branch location}', but that's in .bzr.log.old now.  No mention of the operation in the branch on .bzr.log which is as of 1200BST
[14:28] <vila> >-/
[14:28] <funkyweasel> {branch location} is actual location of branch, not literal.
[14:28] <vila> funkyweasel: standalone branch ?
[14:29] <vila> oh, 1.3.1... geee, what were the progress reporting then...
[14:29] <funkyweasel> vila: Locally branched from a checkout from a repo running bzr 1.3.1
[14:29] <vila> meh was
[14:29] <funkyweasel> 2.0.2 locally.
[14:29] <vila> and the repository is local or remote ?
[14:29] <funkyweasel> remote server.
[14:29] <vila> ouch
[14:30] <GaryvdM> funkyweasel:  But arent' you upgradeing your local branch?
[14:30] <vila> what protocol are you using to reach the server ?
[14:30] <funkyweasel> GaryvdM:  Yes.
[14:30] <funkyweasel> vila: upgrading locally.
[14:31] <funkyweasel> to pack-0.92
[14:31] <vila> hmm, are you sure you're not upgrading both locally and remotely ?
[14:31] <funkyweasel> Pretty sure, yes.
[14:32] <funkyweasel> I *think* I understand the problem.  bzr 2.0.2 is optimised for a different type of repo to 1.3.1 and performs inefficiently on the old version.  At least I hope that's what's happening.
[14:32] <vila> nah, even tht should produce some meaningful output in .bzr.log
[14:33] <vila> can you do a 'bzr info -v' in this branch and paste the output
[14:34] <GaryvdM> vila: even while bzr upgrade is running?
[14:34] <vila> GaryvdM: at worst we'll get a bzr locked error
[14:37] <bialix> vila: oh, it was my mistake to merge from bzr.dev before doing cherrypick :-(
[14:38] <bialix> backporting to 2.1
[14:38] <vila> bialix: told you, should have targeted 2.1 from the start :-O
[14:38] <vila> bialix: sorry to hear that :-/
[14:39] <bialix> DaggyFixes, yeah
[14:39] <bialix> bzr diff -rsubmit: <-- this produce the same patch as mp>?
[14:39] <vila> bialix: indeed, we still need a good solution for the NEWS entries though
[14:39] <vila> bialix: if your branch.conf is correct, yes
[14:40] <bialix> aha, NEWS needs manual editing anyway
[14:41] <vila> hmm, and will need editing again if you land in trunk, then in 2.1 and finally merge 2.1 in trunk
[14:41] <vila> if you land 2.1 first, you're done
[14:41] <vila> well, you have to wait for someone to merge 2.1 into trunk, but NEWS doesn't need to be edited in this case
[14:46] <vila> funkyweasel: what OS are you on and how did you upgrade to bzr-2.0.2 ? Could that be an extension not compiled related slowness ?
[14:47] <funkyweasel> ~bin
[14:47] <funkyweasel> ~paste
[14:47] <funkyweasel> Tch.
[14:48] <bialix> !pastebin
[14:48] <funkyweasel> Station.
[14:49] <vila> Station ? Is that an OS ? Nobody never tell me nothing !
[14:49] <funkyweasel> Sorry, watched Bill & Ted's Bogus Journey again lately.
[14:49] <funkyweasel> http://paste.ubuntu.com/427662/
[14:50] <funkyweasel> I'm on Ubuntu Karmic, the distro prior to the recently released LTS version.
[14:50] <vila> ok
[14:52] <funkyweasel> Clean install.  using branches checked out from the repo server that's on bzr 1.3.1 results in branches which take an order of magnitude longer to complete basic tasks - diff, status.  Commit isn't noticeably worse, but trying upgrade operations takes longer than three hours.
[14:52] <vila> hmm, weird, I wonder if the update is really still proceeding or has already complete... 'Packs containing knits without subtree support' *is* pack-0.92
[14:53] <GaryvdM> vila: note that that pastebin shows new repo version. old repo version was...
[14:54] <vila> funkyweasel: are the numbers of revisions (branch/repo) the ones you're expecting ?
[14:54] <GaryvdM> vila: old repo version was Knit repository format 1
[14:54] <vila> GaryvdM: yeah, so 'bzr info' finds the upgraded stuff apparently, which is why I'm wondering if the upgrade is already complete or not
[14:55] <vila> I don't remember the upgrade to be that long for packs, I know why it takes longer for 2a but for packs...
[14:56] <funkyweasel> vila: Sounds about right number of versions.  the upgrade completed, but spent a lot of time 'checking the repository'
[14:56] <vila> funkyweasel: without displaying a progress bar ?
[14:57] <funkyweasel> Yup.  Little spinning chap and everything.
[14:57] <funkyweasel> I'm trying a bzr status on the branch.  Looks like it's still measured in minutes to complete.
[14:58] <GaryvdM> funkyweasel:  That probably because you still have bzr upgrade running.
[14:59] <funkyweasel> GaryvdM: Not that I can see in the process list.
[15:00] <funkyweasel> I killed it after hour 3.
[15:00] <GaryvdM> funkyweasel:  Oh
[15:00] <vila> oh
[15:01] <funkyweasel> But this is the problem.  Branches generated in 1.3.1 and checked out from a 1.3.1 server to local where I am using 2.0.2 seem to perform history-based operations *really* slowly.
[15:01] <vila> funkyweasel: this 'bzr status' taking minutes, is it for the run after the upgrade or for any run ?
[15:01] <funkyweasel> Any run.
[15:01] <GaryvdM> funkyweasel:  Try run bzr status again
[15:01] <funkyweasel> Same with diff.
[15:02] <vila> funkyweasel: and what was it before the upgrade ?
[15:02] <GaryvdM> vila: pack-0.92 did have dirstate right
[15:03] <funkyweasel> Quickly now.
[15:03] <vila> GaryvdM: wt6 yes
[15:03] <funkyweasel> Did it need to generate some cache.
[15:04] <funkyweasel> Aha.  So let it upgrade, then kill when it's completed but still "checking the repo"?
[15:04] <vila> funkyweasel: yes, it's .bzr/checkout/dirstate
[15:04] <GaryvdM> funkyweasel: Yes, thats why I want you to run bzr status again :-)
[15:04] <funkyweasel> Now it is fast.
[15:04] <funkyweasel> That is excellent.
[15:05] <vila> funkyweasel: something happened that I can't explain, I'm tempted to suspect some weird stuff that may not be reproducible, so if it was me, I'll try to redo the upgrade in some scratch dir and see
[15:05] <funkyweasel> This is most handy.
[15:06] <funkyweasel> Now I need to see if I can push this *slightly* upgraded branch to the repo server, bind to the repo server and all will be well.
[15:08] <vila> funkyweasel: packs-0.92 was introduced in... 0.92 so a 1.3.1 server ought to handle it fine
[15:10] <funkyweasel> It works.  And it is once again the swiftness.  Outstanding!
[15:12] <funkyweasel> Cheers folks!
[15:16] <bialix> bzr miss
[15:19] <bialix> vila: I've got error for https://code.launchpad.net/~bialix/bzr/2.1-clean-tree-bzrdir/+merge/24669
[15:19] <bialix> Launchpad encountered an error during the following operation: generating the diff for a merge proposal.  The source branch has no revisions.
[15:19] <bialix> what I'm doing wrong?
[15:20] <bialix> does lp:bzr/2.1 is wrong branch?
[15:27] <GaryvdM> bialix:  It's maybe a launchpad issue. Maybe try resubmit.
[15:29] <bialix> ah, my branch is not scanned yet: https://code.launchpad.net/~bialix/bzr/2.1-clean-tree-bzrdir
[15:29] <bialix> I'm not sure what I can do about this
[15:30] <bialix> it's stacked on lp:bzr
[15:30] <bialix> maybe there is problem?
[15:30] <GaryvdM> bialix: I think just wait
[15:30] <bialix> I should manually stack on lp:bzr/2.1?
[15:31] <GaryvdM> I think thay are still creating lots of new branchs for ubuntu m
[15:40] <GaryvdM> bialix: I would like to talk to you about something.
[15:40] <bialix> sounds scary
[15:40] <GaryvdM> bialix:  qlog search is broken in lucid
[15:40] <bialix> indeed, scary
[15:40] <bialix> what is qlog search
[15:41] <GaryvdM> open qlog. type in search box?
[15:42] <GaryvdM> bialix: It is due to a change in behaviour in fnmatch.translate
[15:42] <bialix> hmm?
[15:42] <bialix> python?
[15:42] <GaryvdM> before fnmatch.translate('abc') = 'abc$'
[15:43] <GaryvdM> now fnmatch.translate('abc') = 'abc\\Z(?ms)'
[15:43] <bialix> wow
[15:43] <bialix> what's it?
[15:44] <GaryvdM> bialix:  Should we implement our own function
[15:44] <bialix> that's my first thoughts
[15:44] <GaryvdM> \Z = end of string
[15:44] <bialix> (?ms)
[15:45] <bialix> ?
[15:45] <a212901390231901> sets flags I think.
[15:45] <GaryvdM> I'm not sure why it's \\Z
[15:45] <a212901390231901> because it's not a r"" string.
[15:45] <GaryvdM> a212901390231901: Ah
[15:45] <bialix> return fnmatch.translate(wildcard).rstrip('$')
[15:46] <bialix> we can delete just \\Z(?ms)
[15:46] <a212901390231901> yeah, re.M (multi-line), re.S (dot matches all)
[15:46] <GaryvdM> a212901390231901: Do you know what the (?ms) is for?
[15:46] <a212901390231901> they changed it so you can match newlines in the pattern I guess
[15:47] <GaryvdM> a212901390231901: Thanks
[15:48] <bialix> so, our search patterns are never multiline
[15:48] <bialix> we can add workaround and remove either $ or \\Z(?ms)
[15:48] <bialix> if this does not sound very ugly for you
[15:48] <GaryvdM> or just \\Z
[15:48] <a212901390231901> or add ".*" to the end before translate
[15:49] <bialix> writing our own parser/translator is not fun, I guess. but we can just copy-paste old code from py2.5 libs
[15:49] <a212901390231901> blah.*$ or blah.*\\Z will both work
[15:49] <bialix> now I don't follow
[15:49] <bialix> why there is required .*
[15:51] <GaryvdM> a212901390231901:  fnmatch.translate('abc.*') == 'abc\\..*\\Z(?ms)'
[15:51] <GaryvdM> :-(
[15:51] <a212901390231901> okay, scratch that idea then.
[15:52] <a212901390231901> just star? it's turning a glob-looking thing into a re-pattern?
[15:52] <GaryvdM> ah yes
[15:53] <bialix> just asterisk
[15:54] <a212901390231901> bit confusing that it's using search() rather than match() so doesn't need a leading one
[15:56] <GaryvdM> a212901390231901: We only use fnmatch.translate, and then call .search ourselves.
[15:57] <a212901390231901> ah, well, if you use match instead, you'd need another star :)
[15:57] <GaryvdM> yes
[15:58] <vila> sorry was afk
[15:58] <vila> bialix: probably lp being a bit slow, just wait
[16:04] <bialix> okay
[16:17] <GaryvdM> Is there a way to get public_branch from .bzr/branch/branch.conf to override public_branch from ~/.bazaar/locations.conf
[16:17] <GaryvdM> ?
[16:18] <jelmer> GaryvdM: not atm, lifeless was looking into that IIRC
[16:19] <GaryvdM> jelmer: Ok
[16:19] <GaryvdM> thanks
[16:19] <GaryvdM> Will just comment locations.conf for now
[16:24] <bialix> GaryvdM: so, what's the resolution for a problem with qlog?
[16:25] <Peng_> jam: ping?
[16:25] <jam> morning Peng_
[16:25] <Peng_> Oh hi. :D I didn't really expect you to respond. :P
[16:25] <Peng_> Wanted to ask about history_db.
[16:26] <Peng_> Does it handle ghosts and stuff as well as the old code did?
[16:26] <Peng_> I noticed KeyErrors in two branches, but one of them is most likely corrupt (old bzr-svn) and one of them is an old Arch import, so it's probably a bit funny too, though not corrupt.
[16:27] <jam> Peng_: I've tested it against bzr itself, which has ghosts.
[16:27] <jam> So I won't guarantee I've handled all the edge cases, but I should have handled most
[16:27] <jam> if you have tracebacks, point them my way
[16:28] <Peng_> The tracebacks are recorded in my gigantic log file; the trick is digging them out. :P
[16:29] <Peng_> Here's one: http://paste.ubuntu.com/427731/
[16:29] <jam>  /KeyError<enter>^b ^b ^b V kkkkkkkkk "+y :)
[16:30] <GaryvdM> bialix: I think I'm going to add on * to the end  of everything.
[16:30] <jam> ah, the old code just set revno = None for ghosts
[16:30] <jam> the new one probably gets a KeyError.
[16:30] <jam> Shouldn't be hard to fix
[16:30] <Peng_> Oh oh, one of them is in bzr.dev too (one of your revisions, in fact :D ).
[16:31] <Peng_> This one's caused by annotate_ui, but it's the same line of history.py.
[16:31] <GaryvdM> Hi jam
[16:32] <bialix> heya jam
[16:32] <jam> morning all
[16:32] <jam> Peng_: yeah, I have 2 revs in bzr.dev that are ghosts
[16:32] <jam> it was before merge did fetch
[16:35] <Peng_> Heh, nice.
[16:35] <Peng_> jam: http://paste.ubuntu.com/427734/ too. KeyError in get_revno on Loggerhead's history.
[16:37] <jam> Peng_: care to try updating to rev 420?
[16:38] <jam> or you want the integration branch, just a sec
[16:38] <jam> k, rev 419 of integration, or 420 of history_db
[16:39] <jam> hmm.. seems to still be a problem
[16:39] <jam> checking
[16:40] <jam> yeah, silly typo
[16:40] <GaryvdM> vila: would it be ok for me to set https://code.edge.launchpad.net/~spiv/bzr/repo-refresh-data-574236/+merge/24653 to Approved
[16:40] <Peng_> Ah? Tell me when you've fixed the typo.
[16:41] <jam> Peng_: 421 of history-d
[16:41] <jam> pushing now
[16:41] <Peng_> Got it.
[16:42] <vila> GaryvdM: I think it's even Merged
[16:42] <vila> GaryvdM: but yes, it's ok
[16:43] <vila> GaryvdM: lp is slow these days but it should do this (set to Merged)
[16:44] <Peng_> jam: Yup, all fixed. <3
[16:48] <GaryvdM> Vila: I check - it is merged, so I have set it as such :-)
[16:48] <vila> GaryvdM: thnks
[16:50] <Peng_> jam: Oh, if you didn't see the email yet, I noticed another traceback too (History._rev_info AttributeError): https://code.edge.launchpad.net/~jameinel/loggerhead/history_db/+merge/24637/comments/61315
[16:53] <Peng_> jam: Not to rush you or anything. Just sayin'.
[16:57] <jam> Peng_: thanks for the heads up, always nice to have code poking at other code's private vars :)
[17:10] <bialix> ~~~
[17:10] <cobalt_mike> Good morning... has anyone gotten bzrlib to work under Jython? I worked around the requirement for tty/termios but now it needs fcntl or ctypes...
[17:10] <jelmer> cobalt_mike: afaik we don't use ctypes anywhere...
[17:11] <cobalt_mike> bzrlib/lock.py
[17:11] <cobalt_mike> ... requires one of { fnctl, pywin32 or ctypes } for file locking, it seems
[17:12] <a212901390231901> you need my branch
[17:13] <a212901390231901> and it still doesn't work very well, partly java's fault, partly bazaar's
[17:13] <Peng_> cobalt_mike: People occasionally work on making bzrlib fail less on alternate Python implementations. Not sure if they ever fully succeed, though.
[17:13] <a212901390231901> https://code.launchpad.net/~gz/bzr/noncpython
[17:14] <a212901390231901> also read this: https://lists.ubuntu.com/archives/bazaar/2009q4/063999.html
[17:17] <cobalt_mike> thanks, reading
[17:17] <a212901390231901> took me something like 5 months to get a one line fix in jython trunk, so I didn't see much chance of getting quick resolution to the various issues
[17:17] <cobalt_mike> also, it is possible to build bzrlib such that it has no native os components? (eg., shared libraries)?
[17:19] <cobalt_mike> wondering if it might be easier to just shell out to the bzr cmdline, now =/
[17:20] <a212901390231901> for the moment, yes unfortunately.
[17:20] <cobalt_mike> ugh
[17:21] <cbz> is there anything that will pack and get rid of obsolete packs?
[17:22] <a212901390231901> noting on the jython list that you want to use bazaar with it might still be useful though, there have been several people in the past week interested
[17:22] <a212901390231901> and it might mean they'll actually look at it.
[17:23] <jam> cbz: in the 2.2 series there is "bzr pack --clean-obsolete-packs"
[17:23] <a212901390231901> (IronPython started worse off, but have been much more responsive to reported issues, despite not even taking patches)
[17:23] <jam> but you can also do "bzr pack && rm .bzr/repository/obsolote_packs/*"
[17:27] <cobalt_mike> a212901390231901: thanks for all the pointers, need to make some decisions now... sigh
[17:28] <a212901390231901> what bits of bzrlib do you need exactly?
[17:29] <a212901390231901> if you can skirt past bzrlib.chunk_writer and some other problem areas, I might be able to help
[17:30] <cobalt_mike> right now, I need basic things: checkout, commit
[17:30] <cobalt_mike> doing some examination of the working tree
[17:32] <a212901390231901> well, could try my branch and see how far you get
[17:33] <a212901390231901> I've got it merged up to trunk locally but haven't updated on lp as there's upstream mess
[17:33] <cobalt_mike> alright, I'll give it a shot
[17:34] <a212901390231901> I'm around so yell if you run into any problems
[17:34] <cobalt_mike> cool, will do
[17:54] <cobalt_mike> a212901390231901: well, compiled your branch and I've gotten farther than I did with the vanilla bzrlib.. I think I have a bug in my code now. Thanks!!
[18:34] <cobalt_mike> has anyone used bzrlib with jepp instead of jython?
[19:43] <kfogel> jam: ayt?
[20:05] <jam> kfogel: yeah, just saw your message
[20:06] <kfogel> jam: you mean my email?
[20:10] <GaryvdM> Hi amanica
[20:14] <jam> kfogel: yeah, your email
[20:14] <jam> I responded
[20:16] <kfogel> jam: cool, that's what I was pinging about.  Thanks.
[20:23] <amanica> hi GarryvdM
[22:55] <jam> Peng_: the last traceback you sent me has been fixed, but requires updating both loggerhead and bzr-history-db.
[22:58] <mkanat> jam: Oh, so bzr-history-db is coming along now? :-)
[22:59] <jam> mkanat: well, I've specifically integrated it into loggerhead, and I'm responding to fix requests
[23:00] <mkanat> jam: Ah, okay. :-)
[23:00] <mkanat> jam: As a loggerhead plugin?
[23:00] <jam> mkanat: as changing the History class to use it for storage rather than the current sqlite backend
[23:00] <mkanat> jam: Ahh, okay.
[23:04] <mkanat> jam: Any reason you didn't use some sort of NoSQL DB instead of sqlite?
[23:04] <dash> mkanat: that sounds like extra work for no benefit :)
[23:05] <mkanat> dash: Well, I was mostly just thinking about the fact that the required WHERE conditions aren't that complex, and that it would get us distributed caching if we wanted it.
[23:05] <mkanat> dash: Which would be useful for scaling loggerhead across several machines simply.
[23:06] <mkanat> dash: Perhaps it would be simpler to make the loggerhead cache itself into a NoSQL DB or something, since it just has a get() and add() interface currently.
[23:07] <Peng_> jam: Alright, thanks for the fixes.
[23:12] <Peng_> jam: I can confirm it's fixed. :)
[23:12] <jam> mkanat: well, sqlite3 is bundled with python 2.5+
[23:13] <jam> I don't know of any NoSQL that can make that claim
[23:13] <Peng_> ........bdb? :D
[23:13] <jam> so the "no overhead to get loggerhead running on your trivial installation" checkbox is a lot easier to fill with sqlite
[23:13] <Peng_> Or, no, um, gdbm or whatever the heck it's called.
[23:14] <jam> Peng_: bsddb ? it is certainly NoSQL, but certainly not something I'd want to use :)
[23:14] <Peng_> I still think it's interesting that bzr-svn supports tdb now.
[23:14] <Peng_> Serializing complex things into a string key is almost as ugly as using SQL queries, though. :D
[23:14] <jam> mkanat: Also, w/ sql it would be trivial to put it into postgres, or probably any other db back-end. Querier is meant to be the public bzr-history-db api
[23:15] <jam> though I violate that in one place for expediency
[23:15] <jam> I'll probably fix that eventually
[23:16] <Kilroo> ...Huh.
[23:16] <Peng_> Huh?
[23:16] <Kilroo> Sweet, I just confused myself.
[23:18] <Kilroo> I think I had some sort of harebrained idea of combining bzr-svn, bzr-hg, hg's convert extension, and...um...possibly some really stupid hooks somewhere to make an alternative to hgsubversion that would get the advantages in communicating with svn that bzr-svn provides with its custom metadata dooflotchies
[23:19] <Kilroo> Then I tried to figure out what the heck I was smoking and lost my train of thought four times in a row.
[23:20] <Peng_> Sorry, what'd you say? My brain shuts down when I hear multiple VCSes in the same sentence. ;-)
[23:21] <Kilroo> Heh.
[23:22] <Kilroo> Yeah, it drives me crazy too, especially given how we're using svn at work.
[23:22] <Kilroo> At this point I think my best case scenario is convince them to switch from svn to hg.
[23:23] <Kilroo> ...hg being chosen over bzr because the eclipse plugin may be critical in getting my boss to consider a change.
[23:47] <lifeless> Peng_: so bzr-svn shuts you down immediately ?
[23:47] <lifeless> Peng_: or do you have some actual tollerance :P
[23:48] <Peng_> Does what shut me down?
[23:48] <Peng_> :D
[23:48] <lifeless> multiple vcs's in one sentence