[00:00] <kfogel> lifeless: so reading Martin's mail, I think error code 2 makes more sense here.
[00:00] <thumper> mlh_: I think we've lost the context to the question
[00:02] <kfogel> Urgk.  What's the way to make a command throw a specific error code?  Do I raise() something (such as BzrCommandError)?
[00:04] <mlh_> thumper: yeah sorry I didn't want to distract people from the current one.
[00:04] <mlh_> 10:30 < mlh_> a bit OT but do any DVCs support having the repo on one disk and the checkout/tree on another?
[00:04] <mlh_> 10:30 < lifeless> mlh_: bzr does
[00:04] <mlh_> 10:30 < lifeless> mlh_: bzr does
[00:04] <mlh_> oops
[00:07] <thumper> mlh_: I use lightweight checkouts for this
[00:21] <lifeless> kfogel: see e.g. cmd_diff
[00:21] <lifeless> kfogel: I have replied to the original thread btw
[00:21] <lifeless> I think that its ok to do this
[00:21] <lifeless> but commit needs attention
[00:22] <lifeless> and it needs to be more visible; this is an exceptional case
[00:22] <lifeless> As stephen said, its nonsense to argue that this matters for vc-el
[00:22] <kfogel> lifeless: reading your reply
[00:22] <lifeless> from the user perspective I grant the argument about just-another-status
[00:24] <lifeless> yay, I finally have a scrubbed repo
[00:24] <lifeless> weirdness from 2005 eliminated :P
[00:32] <kfogel> lifeless: dang it, I hate how mail archives are always a bit behind.  I'd like to refer to lifeless's mail in a commit message right now, but I don't have the archive URL yet.
[00:32] <lifeless> kfogel: in an implementation sense, do the status operation, then raise an error
[00:32] <kfogel> lifeless: already done :-)
[00:32] <kfogel> just writing the log message now
[00:32] <kfogel> I went with code 3.  Still need to make sure that commit also behaves that way, but I think it does.
[00:34] <lifeless> kfogel: oh, have I introduced you to bzr-search?
[00:35] <kfogel> lifeless: ?
[00:35] <kfogel> https://edge.launchpad.net/bzr-search
[00:35] <kfogel> oh, nice!
[00:35] <kfogel> SVN has needed that for years, and no production-ready solution exists still.
[00:36] <lifeless> :)
[00:36] <kfogel> lifeless: be interesting to have it index the diffs of the commits too, as in "Show me changes containing string S"
[00:36] <lifeless> it indexes the diffs
[00:36] <kfogel> lifeless: !
[00:36] <kfogel> lifeless: home page doesn't say that
[00:36] <lifeless> unique text of merges too
[00:37] <lifeless> content of files ;P
[00:37] <lifeless> I can tweak it
[00:37] <kfogel> lifeless: "content of files" means something different :-)
[00:37] <lifeless> well you get the content by starting with nothing and patching :)
[00:37] <lifeless> I started with whole text every time, it was useless
[00:37] <lifeless> I'm not sure I even committed that version :P
[00:39] <lifeless> anyhow, give it a spin
[00:40] <lifeless> if you have bzr-search present, loggerhead will do ajax search completion stuff
[00:51] <lifeless> wishlist item, tab completion of deleted files
[00:58] <davidstrauss> lifeless: is there a way to automate bzr-search reindexing/
[00:59] <lifeless> davidstrauss: how do you mean?
[00:59] <davidstrauss> lifeless: I have Loggerhead showing some server-side branches, but nothing handles reindexing them automatically, it seems.
[00:59] <lifeless> davidstrauss: what bzr version are the clients?
[01:00] <lifeless> davidstrauss: its meant to index new revisions automatically
[01:00] <lifeless> I presume thats what you mean, rather than delete the index and start over
[01:00] <davidstrauss> lifeless: yes
[01:00] <lifeless> are you pushing/committing with bzr+ssh?
[01:00] <davidstrauss> lifeless: does the smart server automatically handle that?
[01:01] <lifeless> theres a post branch tip change hook
[01:03] <onox> I get Errno 13 when doing bzr update
[01:03] <onox> how do I know which file is permission denied?
[01:04] <lifeless> onox: bzr doesn't tell you? Hm, please file a bug.
[01:04] <lifeless> onox: and I'll give you a workaround -
[01:04] <onox> bzr: ERROR: [Errno 13] Permission denied
[01:04] <lifeless> run with
[01:04] <lifeless> BZR_PDB=1 bzr .....
[01:04] <lifeless> then you will be dropped into pdb
[01:04] <lifeless> you can use that to find the filename and print it, probably
[01:04] <onox> and a lot of -D <file> and M <file>
[01:04] <onox> pdb?
[01:04] <lifeless> python debugger
[01:05] <lifeless> this clearly isn't user friendly, but it will help get you going again :)
[01:05] <lifeless> the bug report will help us fix the root cause
[01:06] <onox> lifeless: http://dpaste.com/115462/
[01:06] <onox> how to proceed? :)
[01:07] <lifeless> type in
[01:07] <lifeless> bt
[01:08] <lifeless> and
[01:08] <lifeless> list
[01:09] <onox> lifeless: http://dpaste.com/115463/
[01:09] <spiv> onox: pp from_, to
[01:10] <onox> (u'/home/mark/workspaces/python/awn-extras/src/tomboy-applet/icons/Makefile.am', u'/home/mark/workspaces/python/awn-extras/.bzr/checkout/pending-deletion/new-85')
[01:10] <igc> morning all
[01:11] <spiv> The permission denied happened while renaming that Makefile.am to that second filename.
[01:11] <spiv> Possibly you lack write permission in either the source or destination directory?
[01:12] <onox> pending-deletion/ doesn't exist
[01:13] <spiv> onox: that's weird!  That directory is created by the TreeTransform constructor.
[01:13] <onox> ah, lol
[01:13] <onox> found it
[01:13] <onox> src/tomboy-applet/icons/tomboy.png was root:root
[01:14] <onox> but has nothing to do with the revisions I tried to fetch
[01:14] <onox> :S
[01:15] <onox> so, bzr tried to delete src/tomboy-applet/icons/Makefile.am (among other files), but it failed because icons/tomboy.png was root:root
[01:17] <lifeless> onox: please do file a bug
[01:17] <onox> bugtracker at LP?
[01:17] <spiv> onox: right
[01:28] <onox> spiv: bug report filed
[02:10] <lifeless> trying for zen-hacking mode, will poll back here hourly or so
[02:15] <lifeless> memo to self, tell vila 13:08 < cortana> however it uses M2Crypto.HTTPSConnection which can possibly be used as a replacement for the default HTTPSConnection class
[02:29] <fullermd> igc: ping
[02:29] <igc> hi fullermd
[02:29] <fullermd> Hey.  You did some log change recently that sped it up with a specified revision range, right?
[02:30] <igc> I did but it's not yet landed
[02:30] <igc> jam voted tweak and I'm yet to do the tweaks
[02:30] <igc> today possibly
[02:30] <fullermd> Hm.  Ok.  I came across a really weird performance thing, thought it might be related.
[02:31] <igc> namely?
[02:31] <fullermd> (flog = log --forward --short)
[02:31] <fullermd> On bzr.dev, bzr flog -r-16.. takes 2.88 seconds.
[02:31] <fullermd> -r-16..-1 takes .55.
[02:31] <igc> my patch fixes that
[02:31] <lifeless> so they both take 2.88 seconds?
[02:31] <lifeless> :P
[02:31] <igc> :-)
[02:32] <fullermd> Maybe they take 1.44 each  ;)
[02:32] <igc> sorry to surprse but they both take .55 now :-)
[02:32] <fullermd> Sweet.
[02:33] <fullermd> igc++
[02:33] <igc> fullermd: in case your curious, bzr.dev loads all of mainline history for -10.. but not for -10..-1 :-(
[02:34] <thumper> igc: why?
[02:34] <igc> kind of sucks on an emacs repo with 93K revisions on the mainline
[02:34] <fullermd> Leprechauns.
[02:34] <igc> thumper: a bug
[02:35] <igc> well, a bug in that it search all of history to find '' instead of realising that it's the tip when at the end of a revisionspec
[03:01] <thumper> :)
[03:01] <thumper> igc: at least that sounds simple
[03:18]  * igc lunch
[03:56] <thumper> is there a way with bzr to grab a tarball of a remote branch (for buildout) ?
[03:57] <lifeless> bzr export ?
[03:58] <spiv> thumper: bzr export foo.tar.gz lp:foo, iirc
[03:58] <thumper> ta
[04:24] <thumper> is there any way to set the parent branch for a light weight checkout?
[04:25] <thumper> we have a utility that uses sed to check for the parent branch in `bzr info`
[04:25] <thumper> my branch doesn't have a parent set
[04:27] <spiv> bzr pull --remember
[04:28] <spiv> You could probably even abuse -r to avoid actually pulling anything, e.g. "bzr pull -r revid:FAKE --remember $parent_url"...
[04:46] <lifeless> thumper: parent branch is in the branch, not the tree
[06:18] <lifeless> night all
[06:19] <kfogel> night, lifeless
[07:18] <vila> hi all
[07:30] <lifeless> vila: urllib2 https possible hint: 13:08 < cortana> however it uses M2Crypto.HTTPSConnection which can possibly be used as a replacement for the default HTTPSConnection class
[07:32] <vila> lifeless: I looked into M2Crypto long ago, except if some serious upgrade has been made, I'll prefer to use the ssl module introduced by python-2.6, for which 2.5 and 2.4 support exists via dedicated module, but thanks for the hint
[07:32] <vila> lifeless: and hi ! Always a pleasure to cross you here ;)
[07:32] <spiv> I wouldn't cross lifeless if I could help it ;)
[07:33] <vila> damn... cross doesn't carry the idea of meeting briefly ?
[07:34] <spiv> vila: it does somewhat, but it also carries the meaning of "To run counter to; to thwart; to obstruct; to hinder; to clash or interfere with." :)
[07:35] <vila> Ouch :-)
[07:35] <lifeless> its ok, I took your meaning as intended
[07:35] <vila> What  common verb or expression should I use then ? (In case I came across less tolerant people :)
[07:35] <spiv> vila: "overlap" is probably more unambiguous, unless someone wants to be interpret it in a physical rather than temporal sense ;)
[07:36] <spiv> Cross is fine, I was just being silly.
[07:36] <vila> more unambiguous... you try to lose me again :)
[07:36] <spiv> Well, nothing's *totally* unambiguous in English.
[07:37] <lifeless> meet
[07:37] <lifeless> encounter
[07:37] <spiv> intersect if you're feeling geeky.
[07:38]  * davidstrauss also has an English degree. Is this a debate about diction?
[07:38] <vila> Yeah, I think intersect carries the time scale I wanted to point to :-)
[07:38] <spiv> Basically the problem isn't English, it's my enthusiasm for creative misinterpretation...
[07:40] <vila> spiv: Oh, I see, strangely enough fullermd haven't intersect with the discussion yet.... :)
[07:40] <davidstrauss> Oh, I see now that nothing of substance is being debated. Carry on. ;-)
[07:40] <spiv> Heh.
[08:32] <fullermd> Hmmwhat?  Did I miss a chance to screw English around?
[08:33]  * fullermd gets rather cross.
[08:38]  * igc dinner
[09:00] <jelmer> lifeless, yeah
[09:06] <LarstiQ> jelmer: moin
[09:06] <LarstiQ> jelmer: I'm back at dizzy, want me to do anything?
[09:08] <jelmer> LarstiQ, see privmsg
[10:24]  * AfC wonders what we'd have to do to get ohloh to support bzr
[10:25] <luks> given it's open source now and already supports hg, it shouldn't be that hard
[10:28] <LarstiQ> is it open source now?
[10:28] <LarstiQ> AfC: the +1s from users have been ignored so far
[10:29] <LarstiQ> AfC: jelmer (iirc) and myself offering to help implementing notwithstanding
[10:29] <LarstiQ> apparently not the right avenue to get things done
[10:30] <luks> http://thechaw.com/ohloh_scm/
[10:41] <AfC> LarstiQ: I know. Lots of us have offered
[10:52] <jelmer> the source code for Ohloh has been published
[10:52] <jelmer> at least the SCM-related bit
[10:53] <jelmer> so somebody *could* contribute bzr support
[10:53] <Pieter> how about you just create a patch, send it in and see what the feedback is?
[10:53] <jelmer> unfortunately it's all ruby :-(
[10:53] <jelmer> AfC: do you know any ruby ?
[10:57] <LarstiQ> Pieter: that is now indeed possible, it wasn't before.
[11:07] <AfC1> jelmer: not a line
[11:19] <LarstiQ> jelmer: I have the pickaxe book, does that count? ;)
[12:14] <lifeless> night all
[13:21] <jam> vila: just wondering if you had a chance to play with my updated fix277537, and see how it worked for you
[13:21] <jam> I'm going to be offline in about 10 min
[13:23] <jam> I guesss a bit earlier, as my machine wants to reboot. hopefully bbiab
[13:23] <vila> jam: rats, too late
[15:28] <santagada> is there a bzr-html plugin, like the qt one?
[16:02] <yml> is there a way to include in a file the rev and the date each time I commit a change on that particular file?
[16:03] <Kinnison> There's a keywords plugin IIRC
[16:03] <Kinnison> But that kind of thing is kinda nasty IMO
[16:03] <yml> The context is that I would like to update this piece of information on the documentation store in the bzr branch.
[16:04] <Kinnison> As I said, I think there's a plugin which may help you
[17:04] <Tak> will bzr-git work with bzr 1.5?
[17:04] <Lo-lan-do> I think it requires a newer version.
[17:05] <Lo-lan-do> Hm, actually I'm not so sure.  The code doesn't seem to check.
[17:09] <Tak> I tried doing a branch with 1.5, and got an error message saying bzr couldn't load the git plugin, but I didn't know if I'd done something wrong, or if the version was incompatible
[17:12] <Lo-lan-do> What was the error message?
[17:21] <Tak> oh, sorry: "Unable to load plugin 'git' from '/home/lbar4/.bazaar/plugins'"
[17:22] <Lo-lan-do> Nothing else?
[17:23] <Tak> nope
[17:25] <jelmer> Tak, anything in ~/.bzr.log ?
[17:25] <Lo-lan-do> jelmer: He uses bzr 1.5, but I didn't see any requirement for a greater version in git/__init__.py
[17:25] <jelmer> Lo-lan-do, oh, you need bzr 1.12
[17:25] <jelmer> or perhaps 1.11
[17:26] <jelmer> the bzr API call to check the bzrlib version probably isn't in 1.5
[17:26] <Tak> ok
[17:26] <Tak> I guess I'll just use git for now then
[17:26] <jelmer> hi btw :-)
[17:26]  * Tak cry
[17:28] <Tak> jelmer: have you looked at/tried my md-bzr branch recently?
[17:29] <jelmer> Tak: Yeah, but I haven't managed to build it yet
[17:29] <jelmer> dinner time, back in ~an hour
[17:29] <Lo-lan-do> Uh, that time already?
[17:30] <Lo-lan-do> Damn, the day went past without me noticing.
[17:30]  * Tak nods
[17:30] <jelmer> Lo-lan-do, well, Dutch traditionally eat at 18:00, I think it's more like 20:00 for the French?
[17:31] <Tak> or later
[17:31] <Lo-lan-do> I'm usually hungyr (and tired of work ;-) at around 19:00, but I was just generally wondering how it was already half past six and I thought I still had some time to do stuff.
[17:37] <ronny> hmm
[17:37] <ronny> argh dammit
[17:38] <ronny> jelmer: how fast can you guys get rid of the single head branch thing - its the main gipe i always run into over and over
[17:38] <Lo-lan-do> Is that the "colocated branches" thing?
[17:41] <ronny> not exactly
[17:41] <ronny> i dont care if they are named, but i want more than one head on the same branch
[17:48] <ronny> well, not exactly branch - i just want multiple heads accessible from the same workingtree as easy as possible
[17:56] <nDuff> ronny, ...referring to a git-like workflow?
[17:58] <nDuff> ronny, "bzr switch foo" strikes me as pretty similar in effect, even if the implementation is different.
[17:58] <ronny> nDuff: mostly monotone and hg alike
[17:58] <ronny> bzr switch is a lot more for me to do
[17:59] <nDuff> ronny, how so? if only providing the last element (not the full path), it reuses the location of your existing branch except for the last element, so it really does only need the branch name as the argument, not the URL.
[18:01] <ronny> doesnt fit my workflow
[18:02] <beuno> santagada, loggerhead
[18:02] <nDuff> ronny, ...hmm; I haven't worked with monotone at all, and hg fairly little, so I'm not entirely sure what you're looking for... would it be similar to looms?
[18:03] <ronny> no
[18:05] <nDuff> ...hmm; as I don't grok the workflow distinction between using switch within a shared repo and multiple heads within a branch, I don't think I can help.
[18:09] <ronny> nDuff: i mainly want to have a as simple structure in the fs as possible
[18:10] <ronny> i dont care how exactly management works - but it should stay the hell outa my fs
[18:11] <nDuff> ronny, ...oh, so it's not a workflow issue, but an aesthetics issue.
[18:12] <ronny> i did set up my whole env to deal with the projects being in their place
[18:13] <ronny> if they are suddenly in another place, its fucked
[18:14] <jelmer> ronny, I need to get comments on my proposal for colocated branches first
[18:14] <ronny> hmm
[18:14] <ronny> jelmer: whats the url again
[18:14] <jelmer> for the spec? It was posted to the mailing list?
[18:16] <ronny> jelmer: i dont follow the ml and google didnt find it
[18:16] <jelmer> ronny, one sec
[18:16] <ronny> oh yikes
[18:16] <ronny> i just noticed how broken the new bzr support for anyvc is
[18:17] <jelmer> ronny, https://lists.ubuntu.com/archives/bazaar/2009q1/051320.html
[18:21] <ronny> jelmer: as for collated branches in url's - how about a http get param?
[18:23] <ronny> jelmer: alternatively collated branches can just be mapped to a directory containing multiple branches on a remote
[18:23] <ronny> magic chatacters wont be nice
[18:24] <jelmer> ronny: yes, but what if there is a on-disk branch with the same name?
[18:24] <jelmer> ronny, this has already been discussed separately on the list, in a different thread
[18:24] <jelmer> there wasn't a conclusive outcome
[18:26] <ronny> jelmer: repo/branchname vs repo/collation/branchname or repo/collation?branch=branchname
[18:27] <ronny> since collated branches wont have a physical path i think a get param maps the intend better, but a path maps it more restfull
[18:27] <jelmer> ronny, GET-style parameters is more typing
[18:28] <jelmer> ronny, martin has suggested using regular path separators and using GET-style parameters in case there is ambiguity
[18:28] <ronny> but if one uses collated branches for git-alikeness wont he actually sync with the main url of the collation
[18:29] <jelmer> ronny: ?
[18:29] <CaMason> Hi guys. I'm getting "bzr_log.random-" files appearing in my working copy after commits (all successful). Any ideas how to prevent that?
[18:29] <ronny> jelmer: as far as i understand git users usualy deal with paths to repos, not paths to branches
[18:30] <CaMason> the contents of the files are the prefilled commit templates
[18:30] <ronny> so they would deal with repo/collation instead of repo/collation/branch
[18:31] <ronny> jelmer: also would there be an issue in just adding an extra path element to let the whole collation have a name?
[18:31] <jelmer> ronny, yes, ambiguity with any actually existing branches on disk
[18:31] <MvG> Hi! Can I push a bzr branch into a subdirectory of a svn repository using bzr-svn, even though the two are unrelated at first? How would I specify a merge base revision, as the error message "Branches have no common ancestor, and no merge base revision was specified." indicates?
[18:32] <ronny> jelmer: can people do things like get a collation a repo/foo and a branch at repo/foo/bar
[18:32] <jelmer> ronny: bzr's UI is very much oriented towards branches, git only uses URLs for repositories
[18:32] <jelmer> ronny: yes, there can be a (nested) branch or regular branch at repo/foo/bar
[18:32] <jelmer> MvG, you can merge in that case using -r0..-1
[18:33] <jelmer> MvG, I mean "bzr merge -r0..-1 <url>"
[18:33] <MvG> jelmer: But I want to push, not merge. I can't merge from a nonexistant directory, can I?
[18:33] <jelmer> MvG, are you using "bzr svn-push" ?
[18:33] <MvG> jelmer: No. Should I?
[18:34] <jelmer> MvG, yes - see the bzr-svn FAQ
[18:34] <ronny> jelmer: oh :/ then it needs an url param
[18:35] <MvG> OK, will do. Once I've reestablished my bzr-svn setup, which I've just nuked by pulling and deleting subvertpy...
[18:35] <jelmer> ronny, See my lines earlier - Martin suggested using path separators but falling back to GET-style parameters to deal with ambiguity
[18:36] <ronny> jelmer: there is a major issue - how does a user decide if he needs to fall back
[18:36] <ronny> hmm
[18:37] <ronny> now i need  the docs for workingtree - is there anything beside source/pydoc?
[18:37] <asabil> jelmer: what about adding a -b option flag ?
[18:37] <jelmer> ronny, pydoc should be pretty comprehensive
[18:38] <asabil> or would that break a lot of things UI wise ?
[18:38] <jelmer> asabil, impractical and that would mean adding a branch parameter in the API everywhere as well
[18:39] <asabil> yes I see
[18:48] <MvG> jelmer: Is there an easy way to install bzr-svn + subvertpy as user - preferably with unmodified branches symlinked to dirs like ~/.bazaar/plugins? Used to work before subvertpy got factored out, but I can't seem to get it working now.
[18:49] <jelmer> MvG, you can install subvertpy into the system or set PYTHONPATH appropriately
[18:50] <MvG> Both feel ugly, but I'll use this for now I think.
[19:02] <jelmer> ronny, also feel free to ask questions here if you have them, of course
[19:05] <ronny> jelmer: just started fixing stuff, seems like the bzr stuff someone else added to anyvc is highly bugged
[19:05] <santagada> beuno: sorry, what was it
[19:05] <santagada> ?
[19:08] <beuno> santagada, if you want a web UI for bzr, you can use loggerhead
[19:09] <ronny> hmm
[19:09] <santagada> beuno: no I wanted something like a plugin that output html
[19:09] <ronny> god i wish anyvc was already usable for web ui's
[19:10] <santagada> so I could use the result of bzr blame inside some other tool (in my case textmate)
[19:10] <beuno> santagada, you can use bzr-xmloutput
[19:10] <santagada> beuno: then use a xslt transform to transform it to xhtml?
[19:11] <beuno> santagada, maybe, yes  :)
[19:12] <jelmer> beuno: Hi Martin :-)
[19:12] <santagada> beuno: not a big fan of xslt... maybe I will use the bzr api and generate html using something like jinja templates
[19:12] <santagada> beuno: thanks
[19:13] <ronny> what package defines the NotBranchError?
[19:13] <jelmer> ronny, bzrlib.errors
[19:13] <nDuff> santagada, as an aside, if you're trying to generate xhtml, I'd consider using Genshi as a way to be certain that your output is always well-formed.
[19:14] <santagada> nDuff: I don't care much about well formed, and it will be any html that webkit can grok
[19:14] <santagada> and I don't like genshi
[19:14] <santagada> it's better than xslt
[19:18] <kfogel> I've done 'bzr init-repo .; bzr branch lp:bkrpr bkrpr-trunk; <<bind bkrpr-trunk to lp:bkrpr so it's a mirror, using instructions from http://bazaar-vcs.org/Scenarios/RepeatedContributions>>; bzr branch bkrpr-trunk bkrpr-task-branch-foo; cd bkrpr-task-branch-foo; <<edit some files>>; bzr commit -m 'Finish my task.' "
[19:19] <kfogel> Is 'bzr push lp:bkrpr' the right way to send my change to the upstream?
[19:20] <kfogel> I'm reading '6.2.5   Merging a feature into the trunk' in the User's Guide, but I'm not 100% sure 'bzr push' is the right thing...
[19:28] <bialix> CaMason: ping
[19:29] <bialix> CaMason: you has asked your question about bzr_log files
[19:30] <CaMason> bialix: yes :)
[19:30] <bialix> CaMason: these files have created by your editor when you type the commit message. I suppose it's auto-backup. What is your editor?
[19:30] <CaMason> I'm actually wondering if it is anything to do with vim... I did vimtutor the other day (which helped set up a .vimrc)
[19:31] <bialix> I recall this question has raised in the past
[19:31] <bialix> IMO you can delete these files safely. I don
[19:31] <CaMason> I do delete them.. it's just messy having them in my wc :)
[19:32] <CaMason> must be a setting within this .vimrc then
[19:32] <bialix> I don't use vim, so I can't help and suggest how to prevent them
[19:32] <rblasch> jelmer: Hi, can I ask you a bzr-svn question?
[19:32] <jelmer> rblasch, yeah, np
[19:32] <bialix> CaMason: something like :w!-+?@ combinaion needed. more or less
[19:32] <CaMason> bialix: no worries, thanks either way.. it's help me pinpoint my thoughts :)
[19:33] <rblasch> Great!  I've set up thing to work with the latest 0.5 version.
[19:33] <rblasch> When doing a branch, bzr suddenly hangs.
[19:33] <bialix> CaMason: It's just silly to see how you ask this question several days in row and nobody answer
[19:33] <rblasch> The last message I get is "determining revisions to fetch 11111/36167", without any further progress.
[19:34] <rblasch> CPU load stays high, though.
[19:34] <CaMason> bialix: I was thinking.. if this was an editor issue, somebody would have seen it before :s
[19:34] <rblasch> Same thing with 0.4 works fine.
[19:34] <bialix> yep
[19:34] <bialix> CaMason: that's all I know. good luck
[19:35] <rblasch> Is there any diagnostics I can enable to track this down?
[19:35] <Lo-lan-do> rblasch: Could it be the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513412 ?
[19:35] <CaMason> bialix: aha, I think i've spotted the line. An if statement was overriding my set nobackup :)
[19:35] <jelmer> rblasch: you can run with -Dtransport -Dcache and see what it is doing
[19:35] <Lo-lan-do> rblasch: Try with -Dtransport -Dcacne
[19:35] <jelmer> rblasch, also, you can try with bzr.dev, that will have better progress indication
[19:35] <bialix> :-)
[19:36] <CaMason> bialix: ahh I've seen what confused me now. I'm used to vim making backup files with a tilde. However, for some reason my terminal is showing tilde more like a dash
[19:36] <CaMason> so the 'backup' files didn't look like normal vim backups to me
[19:36] <rblasch> jelmer: Will do.  Actually I'm using bzr.dev.
[19:36] <bialix> CaMason: so now you know kung-fu ;-)
[19:36] <CaMason> bialix: oh yes >:)
[19:37] <bialix> great
[19:37] <jelmer> rblasch, it will write status messages to ~/.bzr.log
[19:40] <rblasch> jelmer: Yes, it looks like the same issue.  "revprop list" counting down.
[19:41] <rblasch> jelmer: It's just that I got 36k+ revisions, that's why it feels like it's taking forever.
[19:42] <jelmer> rblasch, ah, k
[19:45] <rblasch> jelmer: So it's already a known issue.  Thanks for your time, and a whole lot more thanks for this brilliant plugin!
[19:45] <jelmer> rblasch, np!
[19:45] <jelmer> rblasch, Hopefully this will be fixed in 0.5.1
[19:46] <Lo-lan-do> \o/
[19:46] <Lo-lan-do> (One more beer for jelmer on Friday night :-)
[19:48] <ronny> jelmer: whats the correct way to get a diff of the workingtree?
[19:49] <Lo-lan-do> "Lightweight checkout (format: 1.6 or 1.6.1-rich-root or 1.9 or 1.9-rich-root or dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)"
[19:49] <ronny> http://paste.pocoo.org/show/102476/ <- see the diff method in line 148 for the current broken way :(
[19:49] <Lo-lan-do> Wow, that's incredibly useful :-)
[19:50] <jelmer> ronny, yikes, that *is* broken
[19:50] <jelmer> ronny, you're trying to get the changes against the last committed revision here right?
[19:50] <ronny> jelmer: yeah
[19:50] <ronny> jelmer: im fixing javiers stuff :(
[19:51] <jelmer> ronny, call show_diff_trees(self.wt.basis_tree(), self.wt, strdiff, specific_files=relpaths)
[19:51] <jelmer> ronny: new_tree.branch.revision_history()[-2] will always be wrong, the last committed revision is (obviously) [-1]
[19:52] <ronny> jelmer: i noticed by accident that the diff was bewen tip and tip-1
[19:53] <jelmer> ronny, also, some other notes (while I'm looking at this code anyway):
[19:53] <jelmer> ronny, wt.remove() can take a list of files, there's no need to iterate over all files
[19:53] <jelmer> ronny, revert() seems right only in the case paths=None
[19:54] <beuno> ronny, is this for pida?
[19:54] <kfogel> I've done 'bzr init-repo .; bzr branch lp:bkrpr bkrpr-trunk; <<bind bkrpr-trunk to lp:bkrpr so it's a mirror, using instructions from http://bazaar-vcs.org/Scenarios/RepeatedContributions>>; bzr branch bkrpr-trunk bkrpr-task-branch-foo; cd bkrpr-task-branch-foo; <<edit some files>>; bzr commit -m 'Finish my task.' "
[19:54] <kfogel> Is 'bzr push lp:bkrpr' the right way to send my change to the upstream?
[19:54] <kfogel> I'm reading '6.2.5   Merging a feature into the trunk' in the User's Guide, but I'm not 100% sure 'bzr push' is the right thing...
[19:54] <ronny> beuno: yeah
[19:54] <beuno> ronny, many bugs in the bzr integration?
[19:55] <ronny> it was less when i used subprocess
[19:55] <ronny> then i merged the work of someone else
[19:55] <ronny> now i do myself
[19:55] <ronny> and of course i lack unittests :(
[19:55] <jelmer> ronny, I also don't think the converting to relative paths is necessary
[19:56] <ronny> jelmer: absolute paths is necessary, since i pass paths relative to the repo base, i have to reiterate a few time till its more nice
[19:56] <jelmer> ronny, but there's no need to convert *back* to relative paths afaik, as is done in a few places
[19:57] <ronny> k
[19:57] <beuno> ronny, this is Javier Derderian's work?  is it not good quality?
[19:58] <ronny> unfortunately it seems like this part of his work isnt good
[20:00] <beuno> ronny, I'm sorry to hear that  :(
[20:02] <ronny> jelmer: hmm, is there a tool to do globing?
[20:02] <ronny> i think i could use that
[20:03] <jelmer> ronny, not that I'm aware of, the shell takes care of that for us I think. There may be something in the win32-specific code
[20:03] <ronny> hmk
[20:04] <jelmer> ronny, what would you need globbing for anyway, it seems like a bad thing to be part of a UI..
[20:04] <jelmer> eeuhm, API
[20:05] <ronny> jelmer: probably right, shell mindset sometimes is nasty
[20:09] <ronny> hmm
[20:22] <ronny> jelmer: for some reason my current usage of diff causes a traceback, please take a look at the current code + trace on http://paste.pocoo.org/show/102490/
[20:23] <jelmer> ronny, one of paths is not known by bzr?
[20:24] <ronny> jelmer: thats the base path of the repo
[20:24] <ronny> hmm, let me dig if i find where it comes in
[20:24] <jelmer> ronny, perhaps try ["."]
[20:25] <ronny> seems like it doesnt like an abspath
[20:29] <bialix> LarstiQ around?
[20:29] <ronny> jelmer: i intend to make the shell command vc diff work in bzr repos
[20:29] <ronny> (anyvc ships a executable called vc)
[20:30] <bialix> LarstiQ: ping
[20:34] <LarstiQ> bialix: yeah
[20:34] <LarstiQ> bialix: pong :)
[20:35] <bialix> LarstiQ: I've finished new format of project.cfg
[20:35] <LarstiQ> bialix: cool
[20:35] <LarstiQ> bialix: is it in trunk, or in a seperate branch?
[20:35] <bialix> I've implemented some of your notes as well
[20:36] <bialix> it's separate branch
[20:36] <ronny> jelmer: diff seems to work fine as soon as i use a relative paths
[20:36] <jelmer> ronny, hmmok
[20:36] <LarstiQ> bialix: ok
[20:36] <bialix> LarstiQ: so if/when you will be curious you can play with lp:~bialix/bzr-scmproj/format-change
[20:37] <LarstiQ> bialix: noted
[20:37] <bialix> LarstiQ: you have to upgrade your .scmproj by hands. Or may be recreate it
[20:37] <bialix> sorry for inconvenience
[20:37] <LarstiQ> bialix: that's ok
[20:37] <bialix> there is doc for early adopters
[20:37] <bialix> at least it says what should be changed
[20:38]  * LarstiQ is very tolerant of this sort of inconvenience.
[20:38] <LarstiQ> JSF t:updateActionListener not working, not so much
[20:38]  * LarstiQ had a long day at work
[20:38] <bialix> yeah, it's still alpha. so I have a poor excuse
[20:38] <LarstiQ> :)
[20:38]  * LarstiQ branches the format-change branch
[20:38] <bialix> LarstiQ: I understand. It's just head u
[20:38] <bialix> head up
[20:39] <bialix> you seem to be interested
[20:39]  * LarstiQ nods
[20:39] <LarstiQ> bialix: I am.
[20:39]  * LarstiQ just needs to blow off steam re work
[20:40] <bialix> I saw good news about nested trees here, abentley will continue this work
[20:40] <bialix> this is great
[20:40] <bialix> but in the meantime I'll continue my work too
[20:41] <bialix> in some sense I feel they are orthogonal
[20:41] <bialix> LarstiQ: rest well! I'm going to rest too.
[20:41] <LarstiQ> bialix: hey, part of my rest is reading irc (backlog) ;)
[20:42] <bialix> :-D
[20:42] <LarstiQ> bialix: yeah, I'm happy that Aaron is coming back to them.
[20:42] <bialix> I understand
[20:42] <LarstiQ> bialix: and I'll certainly keep you posted of the progress
[20:42] <ronny> hmm
[20:42] <ronny> now i have to figure iter_changes
[20:42] <bialix> LarstiQ: it's great
[20:42] <bialix> woohoo!
[20:43] <LarstiQ> :)
[20:43]  * bialix disappears
[20:47] <lifeless> moin
[20:47] <mwhudson> hi lifeless
[20:52] <jelmer> kfogel, still there?
[20:53] <jelmer> kfogel, In that particular workflow, pushing to trunk would be appropriate I think
[20:57] <ronny> jelmer: is there any description on how to interpret the items that wt.iter_changes yields?
[20:58] <ronny> an 8 tuples with some items + nested 2 tuples is pretty confusing at first sight
[20:59] <jelmer> ronny, see the docstring for bzrlib.tree.InterTree.iter_changes
[20:59] <LarstiQ> ronny: bzrlib.tree.InterTree.iter_changes docstring
[21:02] <ronny> nice
[21:03] <LarstiQ> ronny: you might also want to look at bzrlib.delta
[21:04] <LarstiQ> ronny: and bzrlib.dirstate for more gory details
[21:07] <ronny> iter_changes seems to be the right way to get what i need
[21:09] <ronny> nice full detail level and easy to translate to the terms of anyvc
[21:09] <beuno> ronny, maybe loggerhead's code can help you as well: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/head%3A/loggerhead/history.py
[21:09] <beuno> we generate diffs
[21:10] <beuno> maybe this is better: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/head%3A/loggerhead/controllers/diff_ui.py
[21:10] <ronny> hmm
[21:10] <ronny> beuno: at some point i'll have to add a web ui for anyvc
[21:11] <ronny> remote branch/repo management + smart servers for hg/bzr
[21:24] <lifeless> here we compressbench again
[21:24] <lifeless> jelmer: did you use the compressbench results at all ?
[21:24] <lifeless> Jc2k: ping
[21:24] <jelmer> lifeless, not yet
[21:24] <jelmer> lifeless, I'm going to this week
[21:24] <jelmer> lifeless, dpush is almost working for bzr-git
[21:24] <jelmer> that was the main thing I worked on
[21:25] <lifeless> cool
[21:27] <Lo-lan-do> Look, at some point it will cease to be reasonable for me to buy you drinks, you know.
[21:27] <jelmer> Lo-lan-do, at some point I assume it will also start affecting the quality of my code ;-)
[21:31]  * Lo-lan-do tries to think of a way to hack a two-way bzr/git gateway for several branches without colocated branches
[21:31] <lifeless> looms
[21:34] <mwhudson> do the error reports in https://answers.edge.launchpad.net/launchpad/+question/59649 ring bells with anyone here?
[21:34] <mwhudson> he's using an ancient bzr, but still
[21:34] <lifeless> I'm down to console only while profiling
[21:34] <lifeless> if you need me don't email :) and I can't read pastebin easily
[21:35] <lifeless> mwhudson: what is he seeing?
[21:35] <mwhudson> weird-ass errors from pushing over sftp mostly
[21:36] <mwhudson> the other stuff i think i can explain
[21:36] <mwhudson> but really, 0.11.0
[21:36] <lifeless> uhm
[21:36] <lifeless> thats pre-packs
[21:36] <lifeless> iz bad
[21:36] <mwhudson> yar
[21:37] <Lo-lan-do> i can haz pakz?
[21:53] <ronny> jelmer: btw, are there any plans for a bzr-hg when bzr-git is done?
[21:53] <jelmer> ronny, there is a bzr-hg already, https://launchpad.net/bzr-hg
[21:53] <jelmer> it already allows you to browse logs, etc
[21:53] <ronny> oh, i missed that
[21:53] <jelmer> though not much more beyond that
[21:53] <santagada> jelmer: so you also have a time machine?
[21:54] <santagada> I tought only guido could go back in time
[21:54] <lifeless> santagada: we're quite fond of 'heres one I prepared earlier' here :)
[21:55] <santagada> :)
[21:58] <ronny> jelmer: im mainly asking cause hg wont grow a hg-bzr anytime soon and i prefer to use hg
[21:59] <LarstiQ> ronny: it needs more love to be useful
[22:01] <ronny> im pretty busy with exams + moinmoin + anyvc + pida + vellum atm
[22:01] <ronny> hmm
[22:01] <ronny> ok, mapping stuff from iter_changes to my personal anyvc status info is more tricky than i tought
[22:02] <ronny> time to wire up a plan
[22:05] <LarstiQ> ronny: Jelmer is doing a vcs tour, I'm sure he'll make a bridge for everything eventually ;)
[22:06] <jelmer> LarstiQ, I think the key is convincing the other Samba developers to switch to hg
[22:06] <ronny> oO
[22:06] <lifeless> jelmer: ?
[22:06] <Lo-lan-do> Sounds like a plan :-)
[22:06] <ronny> samba developers to hg ?
[22:06] <ronny> whats up with that?
[22:06] <jelmer> lifeless, that way I'll end up working on bzr-hg to make sure I can still work on Samba with bzr
[22:06] <lifeless> indeed
[22:06] <Lo-lan-do> Samba switches to X → jelmer does bzr-X
[22:06] <lifeless> ronny: he's trolling/being humuour
[22:08] <jelmer> ronny, I started working on bzr-svn because Samba was using that at the time, I started working on bzr-git when Samba switched to Git
[22:10] <ronny> ah i see
[22:11] <LarstiQ> and started looking at bzr because tridge had mentioned that as a possible succesor to svn?
[22:12] <ronny> hmm
[22:13] <jelmer> LarstiQ: no, I looked at it before that
[22:13] <LarstiQ> jelmer: ah ok
[22:13] <jelmer> LarstiQ, I started looking into early versions after seeing Martin's talk at LCA 2005
[22:13]  * LarstiQ started because uws was using it, and he wanted to try a dvcs other than (l)arch
[22:13] <Lo-lan-do> Ugh, arch.
[22:14] <LarstiQ> Lo-lan-do: when it was all still shell scripts
[22:14] <Jc2k> lifeless: pong
[22:14] <Lo-lan-do> I used tla and baz, but that didn't make it much better.
[22:15] <Lo-lan-do> I still resent (a bit) the annexion of the Bazaar name by bzr, but I have to concede it's *vastly* superior :-)
[22:15] <lifeless> Jc2k: I want to eliminate fork() from my compressbench; that means calling into libgit directly etc
[22:15] <lifeless> Jc2k: if this is hard I will skip it in the interests of time
[22:15] <lifeless> Jc2k: I hear you've done some stuff in this area
[22:17] <Jc2k> lifeless: probably nothing thats suitable for what you need right now
[22:18] <Jc2k> lifeless: i dont think there is a c-lib for packing stuff, unless libgit2 has advanced *a lot* from last time i heard about it
[22:18] <lifeless> Jc2k: I don't care about time-to-pack at this point, rather reliable comparisons for time-to-unpack
[22:18] <lifeless> I want to know precisely how long git takes to extract the same corpus knits do
[22:19] <lifeless> it would be stupid to go to a slower disk level format, for instance, if the performance win is purely that 'its C'
[22:19] <lifeless> and right now we're still largely flying blind
[22:19] <Jc2k> *nod*
[22:20] <Jc2k> so aside from dulwich and calling git binaries the only other options are:
[22:20] <lifeless> all I know for sure is that dulwich is something like 200 times slower at extracting texts from packs than bzr is from its packs
[22:20] <Jc2k> libgitcore. unfinished refactor of git into a library
[22:21] <Jc2k> libgit2. ground up rewrite of git as a library. might not have any pack foo.
[22:22] <lifeless> ok, thanks
[22:22] <Jc2k> im pretty sure libgitcore would need non-trivial hacking on before you could use it
[22:22] <Jc2k> we gave up on it post-guadec
[22:22] <lifeless> so groupcompress
[22:22] <lifeless> avg 0.0836303479982
[22:22] <lifeless> knit
[22:23] <lifeless> avg 0.0119135125978
[22:23] <lifeless> I'm going to determine an answer as to 'why' today
[22:23] <lifeless> I hope
[22:23] <lifeless> if its design, I'll be shelving it, for now.
[22:24] <lifeless> One candidate reason is space-time tradeoff, the knits corpus is 25.4M, the gc corpus is 3.5M
[22:24] <Jc2k> http://repo.or.cz/w/libgit2.git
[22:24] <Jc2k> doesnt have any pack stuff by the looks of things
[22:25] <lifeless> in such a scenario, a group cache would win
[22:25] <lifeless> so thats a knob I'm tinkering with now
[22:26] <lifeless> as basic profiling has simply told me 'zlib is much of it'
[22:26] <lifeless> do you know, does git use any buffers
[22:26] <lifeless> or caches
[22:26] <lifeless> e.g., if it reconstructs texts X, Y, Z
[22:26] <lifeless> and X was compressed against Y, and Y against Z
[22:27] <lifeless> so getting X out first means getting Y and Z, but the command then wants Y, will it start over, or have it ready to use?
[22:28] <Jc2k> there is a delta_base_cache
[22:28] <lifeless> great
[22:28] <lifeless> do you recall how big it is ?
[22:29] <Jc2k> its an LRU of 256 objects
[22:29] <lifeless> cool
[22:30] <lifeless> so the pattern of recent-at-front, compression will tend to get a good hit rate
[22:30] <lifeless> as well as making the first objects asked for rapidly available
[22:30] <lifeless> it would be interesting to find history patterns that make the cache thrash
[23:03] <lifeless> vila: ping
[23:10] <igc> morning
[23:12] <mwhudson> hi igc
[23:13] <mwhudson> igc: i need to look at bzr-revnocache sooner or later but i should read the source first :)
[23:21] <jelmer> down to only 26 bzr-svn bugs, a lot of which wishlist items (-:
[23:21] <igc> hi mwhuson
[23:22] <igc> bzr-revnocache still needs a lot of work but ...
[23:22] <igc> that can come after the 1.12rc ships
[23:23] <tro> bzrtools 1.11 isn't present in the hardy ppa :(
[23:23] <igc> in particular, it currently stores the full sorted history for every branch
[23:24] <igc> when there's a local mirror + feature branches, I want it to store just the new history for feature branches and delegate back to the mirror for the rest
[23:24] <igc> mwhudson:^^
[23:25] <mwhudson> igc: do you just dump it and recalc when the tip changes?
[23:25] <mwhudson> it sounds a little bit like having .bzr/branch/revision-history back
[23:26] <igc> that's before my bzr time :-)
[23:26] <lifeless> igc: revision-history stored the full left hand history
[23:27] <lifeless> igc: its an O(history) operation to update
[23:27] <igc> right
[23:27] <lifeless> igc: and it dominated push and pull
[23:27] <igc> my caching doesn't slow down either or those
[23:27] <igc> when the tip moves, it removes the cache ...
[23:27] <mwhudson> i have this feeling that i'm going to end up working on O(new-stuff) updates to merge-sorted revision graph
[23:27] <mwhudson> for loggerhead
[23:28] <igc> and it gets saved the next time it's calculated
[23:28] <mwhudson> unless i can trick someone else into doing it :)
[23:28] <lifeless> igc: my point is that updating it over the wire is a huge amount of work
[23:28] <Lo-lan-do> jelmer: Would a "AttributeError: 'SvnRepository' object has no attribute '_iter_revmeta_ancestry'" count? :-)
[23:28] <igc> right - I only support local caches
[23:28] <lifeless> igc: I think a plugin is the right place to work on this problem
[23:28] <lifeless> igc: and I think its good you are doing it
[23:29] <igc> thanks
[23:29] <jelmer> Lo-lan-do, which branch are you using?
[23:29] <Lo-lan-do> http://bazaar.launchpad.net/~jelmer/bzr-svn/0.5/
[23:29] <Lo-lan-do> r2500
[23:29] <jelmer> Lo-lan-do, ah, the main branch is on http://people.samba.org/bzr/jelmer/bzr-svn/0.5
[23:29] <jelmer> launchpad mirrors it, but it seems to take up to half a day for it to do so
[23:30] <Lo-lan-do> Okay, I'll rerun my checkout then, but I'll let it run during the night since it takes forever and I really should be in bed by now.
[23:31] <lifeless> jelmer: you can tell lp to do it faster
[23:32] <lifeless> jelmer: e.g. on push
[23:32] <jelmer> lifeless, how?
[23:32] <spiv> lifeless: oh, that plugin exists now?
[23:32] <lifeless> I filed a bug asking for this capability
[23:32]  * Lo-lan-do → sleep
[23:32] <lifeless> it has been closed with info that its somewhere in lp-api
[23:32] <jelmer> Lo-lan-do, g'night
[23:32] <jelmer> lifeless, I don
[23:32] <jelmer> 't have launchpadlib here, I'm on Debian :-)
[23:33] <lifeless> jelmer: I don't see why that precludes launchpadlib
[23:35] <jelmer> lifeless: being on Debian, you mean?
[23:35] <lifeless> right
[23:35] <lifeless> install the dependencies, install the jaunty package
[23:35] <jelmer> lifeless, launchpadlib, wadlib and httplib2 aren't packaged there
[23:36] <jelmer> Anyway, I don't care enough about launchpad to do so
[23:37] <lifeless> subvertpy - new dependency? Didn't it use to be bundled?
[23:37] <jelmer> lifeless: yes, it's now developed and distributed separately
[23:37]  * lifeless removes bzr-svn again
[23:38] <lifeless> its too muc futzing around to keep it going when I'm not actively hacking on it or using it
[23:39] <jelmer> it's in the PPA these days, fwiw
[23:39] <lifeless> in particular, I run all my dev plugins from source
[23:39] <lifeless> so a dependency that has to be installed to be used is a real nuisance
[23:39] <lifeless> (I run them all from source to allow version switching trivially)
[23:43] <jelmer> lifeless, it's just a python module like any other, the API is stable, no ties to bzr
[23:43] <lifeless> I know, but its namespaced outside
[23:44] <lifeless> so rather than rm foo; ln -s /other foo
[23:44] <lifeless> I have to do a dance
[23:44] <spiv> I have a one-line hack in my bzr-svn checkout to add my subvertpy checkout to sys.path...
[23:47] <lifeless> jelmer: don't get me wrong, I think its great to promote reuse like you are
[23:47] <lifeless> but it has a cost
[23:47] <lifeless> which I'm not willing to pay until I need to do something with bzr-svn again
[23:47] <lifeless> e.g. loggerhead tweaks or whatever
[23:50] <lifeless> ok, group cache working, lets give it a spin
[23:50]  * lifeless wait()s
[23:50] <jelmer> lifeless, sure, I understand. Similar to what I have with launchpadlib...
[23:51] <lifeless> I wish lplib didn't use httplib2
[23:51] <lifeless> that thing is terrible
[23:51] <lifeless> I looked, went blind, walked away
[23:51] <jelmer> (which is one of the reasons why I pinged James about uploading to Debian as well)
[23:53] <lifeless> breakfast while this runs
[23:53] <furicle> Warning - RCS newbie - I've taken a tarball, did a bzr init - bzr add - hacked, commited - now I want to export only my changes back upstream as patches - but  bzr diff is putting out binary crud because I removed some pdfs.  What do I do?
[23:57] <lifeless> furicle: bzr normally detects binary files;
[23:58] <lifeless> furicle: what command are you running to get this export ?