[00:03] <jam> spiv: Yeah, trying to clear out my inbox generally has good results for others :)
[00:13] <jam> abentley: BB doesn't seem to be noticing my reviews, nor is it giving me the automatic :approve for patches from me? Can you tell why?
[00:14] <abentley> jam: The mail queue is pretty deep: http://bundlebuggy.aaronbentley.com/mail
[00:14] <jam> ah, ok
[00:14] <jam> I guess me landing 5 patches in bzr.dev doesn't help
[00:14] <jam> According to your earlier comments
[00:14] <abentley> yeah.
[00:15] <jam> abentley: also, some of them are pretty old: Tue Jul 15 04:50:37 2008
[00:15] <jam> That is about 2 days?
[00:15] <jam> ah, maybe that is 'frozen'
[00:16] <abentley> The ones in the 'frozen' list will not be processed without my intervention.
[00:18] <colbrac> Jelmers bb:approve messages on the bzr-gtk list today are also not coming through
[00:30] <abentley> jam: I've tweaked the branch scanner to run set membership tests to find out whether a request was merged, as you suggested.  Much faster!
[00:43] <FallenPegasus> is there a way to configure bzr to say something like "warning: you are about to push with uncommitted changes"
[00:44] <jelmer> FallenPegasus, not at the moment afaik
[00:44] <jelmer> if you think that is a useful feature, please file a bug
[00:46] <colbrac> jelmer: Any idea how to fix that push PushResult problem?
[00:48] <jelmer> colbrac, this appears to be a bug in bzr itself
[00:48] <jelmer> colbrac, I see one implementation of pull() that doesn't return a PullResult
[00:48] <jelmer> while the API clearly states that it should
[00:49] <colbrac> doh..
[00:50] <jelmer> Sorry, my bad - it's actually inside of a try so I missed it
[00:51] <jelmer> I'm not quite sure what causes it then
[00:52] <jelmer> though it seems like a bad idea to work around unexpected behaviour while it's unknown what's causing that unexpected behaviour
[00:54] <colbrac> Which one of those BrzBranch#'s in bzrlib/branch.py is used you think?
[00:55] <colbrac> LP page of the branch says format 6.. so I'd assume BzrBranch6 :P
[00:57] <colbrac> hum.. I give up.. way too much abstractions for this time of night
[01:03] <jelmer> colbrac, shouldn't be too hard to figure out if you use pdb
[01:04] <colbrac> jelmer: you mean, after I learn to use pdb? :)
[01:04] <jelmer> (-:
[01:04] <colbrac> jelmer: That will be for another day. The dialogs took more time than I expected already.
[01:05] <jelmer> colbrac, k
[01:05] <jelmer> colbrac, thanks for those changes, btw. I'm really happy to see that happen
[01:05] <colbrac> jelmer: The main window GUI will be more like removing a bandaid though... :o)
[01:06] <colbrac> jelmer: One quick big pull
[01:06] <colbrac> changing way too many lines in __init__
[01:07] <colbrac> jelmer: But I'll wait till I have some comments on the changes I made to the locationbar location and the Bookmarks appearance
[01:08] <jelmer> ok
[01:12] <colbrac> jelmer: One more thing before I go: There were some approved merges on the vernstok BB that are not in the new BB. Will you merge them or must they first be resend to this BB?
[01:17] <jelmer> colbrac, please resend them
[01:18] <colbrac> jelmer: Tomorrow.. or like.. after some sleep :o) G'night all
[01:18] <jelmer> :-)
[01:18] <jelmer> weltrusten
[03:14] <Peng> Hmmm.
[03:15]  * igc lunch
[03:16] <Peng> On Ubuntu with the PPA 1.6b3, bzrbashprompt.sh is running and making my shell slow, even though I'm not using it.
[03:27] <jam> Peng: It seems the debian system auto installs everything in contrib/bash to /etc/bash....d/
[03:27] <jam> you can rm the one file
[03:27] <jam> and I think the packaging is going to be updated.
[03:27] <Peng> If I rm it, it will be reinstalled next time I upgrade bzr, right?
[03:28] <Peng> I replaced it with an empty file. All is right in the world now. :)
[03:38] <jam> Peng: well, the next bzr version should *not* install that file anymore.
[03:38] <jam> We didn't intend it to be installed, but didn't realize the installer said "install contrib/bash/*"
[03:38] <jam> which used to just install a path-completion stuff
[03:48] <Peng> jam: Ah.
[04:10] <Grantbow> I'm getting the feeling that instead of using the CVS $Id:$ trick I have to do something like bzr version-info --python and check it in - am I getting warm?
[04:10] <mwhudson> this doesn't look very happy: http://pastebin.ubuntu.com/28180/ :(
[04:12] <mwhudson> bzr log --short over the hpss is broken?
[04:28] <GaryvdM> Is it possible to add an option to a builtin command from a plugin?
[04:29] <GaryvdM> I want to fix Bug 241889
[04:29] <GaryvdM> bzr merge --qpreview
[04:31] <mwhudson> GaryvdM: yes
[04:31] <mwhudson> unfortunately i don't really know the best way how...
[04:32] <GaryvdM> Do you know of some where else that it has been done?
[04:34] <mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/249690
[04:34] <Verterok> GaryvdM: xmloutput (0.4 series) adds --xml option to status, etc. It's not the best way to do it, but it seems to work ok.
[04:35] <mwhudson> GaryvdM: i did this once: http://pastebin.ubuntu.com/28183/
[04:35] <GaryvdM> Ok - that would work
[05:01] <GaryvdM> Thanks mwhudson. I was able to do it.
[05:01] <mwhudson> GaryvdM: cool
[06:28] <jml> poolie: I've encountered an issue with the stacking stuff.
[06:28] <jml> poolie: can I call you about it?
[06:34]  * spiv ducks out for an hour
[06:39] <lifeless> poolie: ping
[06:49] <poolie> jml, sure
[06:49] <poolie> lifeless: pong
[06:51] <poolie> i fall off irc and everyone wants me :)
[06:51] <jml> we always want you poolie
[06:52] <igc> GrantBow: yes
[06:52] <jml> poolie: skype or pots?
[06:53] <lifeless> poolie: we have about 50 tshirts left; how do you feel about us giving them out at LRL
[06:53] <poolie> lifeless: go crazy
[06:53] <lifeless> thanks
[06:55] <lifeless> erm wtf http://bazaar-vcs.org/ZoomQuiet
[06:55] <lifeless> it doesn't seem quite spam
[06:55] <lifeless> but its surely not topical
[06:56] <lifeless> poolie: also, any feedback on the RFC: review support and partial commits would be nice
[06:56] <lifeless> (doesn't have to be deep feedback)
[06:57] <lifeless> ZoomQuiet is also doing japanese translations of bzr wiki pages. *blink*
[06:57] <poolie> jml, let me reply to vila first
[06:57] <jml> poolie: ok
[07:23] <poolie> jml, call me? pots?
[07:23] <jml> poolie: sure.
[07:30] <kiorky> jelmer (and others): hello, i have strange segfault error on bzr-svn and i cant figure out why it comes. (li. 675 in ra.c seems to be problematic for me (where the segfault seems to appen). But i run in a special env. (all underlying libraries are compiled with prefix) and i want t be sure that it is not the env rather than bzr which is in fault. How can i debug efficiently that ? With gdb (then how?)
[07:31] <kiorky> jelmer: what i want to do is just "import pdb;pdb.set_trace()", C way
[07:36] <kiorky> jelmer: http://www.friendpaste.com/xjJTVvNv i get that as a start, must go out to work, seeya.
[08:10] <lifeless> kiorky: hi, jelmer will be around in an hour or two; its early morning here in the UK
[08:22] <kiorky> lifeless: one hour less from me :p (france)
[08:49] <kiorky>    /B 29
[08:59] <poolie> lifeless: ping
[08:59] <poolie> lifeless: do stacking branches still actually require supports_external_lookups in the repository?
[08:59] <poolie> i'm guessing yes, so that check knows it's ok for them to have outward-pointing references?
[08:59] <lifeless> poolie: yes
[09:00] <poolie> so to make stacking a non-development feature, we need a non-development repository format too
[09:00] <poolie> with that set
[09:15] <lifeless> poolie: yes, branch and repo format both
[09:16] <lifeless> you can just take the development one and rename/tweak it if you want the shortest path. Ideally though you'd add another format, marked stable, and leave the devleopment one as is until 1.7 when it can be removed
[09:16] <lifeless> poolie: did you see the rfc on review support in bzr?
[09:16] <fullermd> Is there a reason not to pull the rich-root switch at the same time?  I thought that was targetted to 1.6 originally anyway...
[09:17] <lifeless> fullermd: aaron said to me last week there were about 2 bugs remaining
[09:17] <fullermd> Ah.  That's a good reason   :)
[09:18] <lifeless> -> checkout
[09:19] <poolie> lifeless: i did
[09:19] <poolie> when i read it last night i was a bit averse to putting it in the core
[09:20] <poolie> but, i guess it depends on whether you mean 'shipped with bzr' or 'getting its fingers in everywhere'
[09:20] <lifeless> well
[09:20] <lifeless> putting implementation aside
[09:20] <lifeless> did it sound nice, would you use it
[09:20] <poolie> it seems like it would integrate in an interesting way with content filtering, doesn't it?
[09:20] <lifeless> would it be easy to use
[09:21] <poolie> so 'the convenient form of this file has these extra hunks but pretend you can't see them'
[09:21] <poolie> it does sound pretty nice
[09:21] <poolie> i had a case for this just the other day with the pdb stuff in selftest
[09:21] <poolie> i guess i could have made it into a loom thread
[09:21] <poolie> i agree with you that the git index is interesting but the wrong way around imo
[09:22] <lifeless> back after I checkout
[09:44] <lifeless> back
[09:44] <lifeless> poolie: so I want to preserve the 'what diff shows you is what is committed' assertion
[09:45] <lifeless> I don't know that content transformation is a good fit with hunk marking
[09:53] <jelmer> 'morning
[09:54] <awilkins> Morning
[09:54] <awilkins> I see win32 became a first-class beta citizen
[09:55] <awilkins> A shame that configuring it to compile those extensions is such a PITA
[09:57] <jelmer> hi awilkins
[09:57] <awilkins> jelmer: So, bzr-svn ; my thoughts are that 1) Update is redundant, because switch also works within a branch as well as across branches ; 2) Replay is probably easier once you get the path remapping working
[09:57] <awilkins> BUt you've probably got my mail already :-)
[09:58] <jelmer> awilkins: replay can only be used if the server has svn >= 1.4
[09:59] <awilkins> jelmer: True, I wonder how many servers have not been upgraded. I think svn has been at 1.4 for some time.
[10:00] <awilkins> jelmer: I suppose getting switch to work well and then implementing replay stops you ignoring bugs in the switch implementation :-|
[10:03] <jelmer> awilkins: There's quite some out there
[10:03] <awilkins> I suppose the last 1.3 release was only last June
[10:04] <awilkins> I upgraded specifically for replay ; the bosses wanted a redundant backup server, so it mirrors to a second box using svnsync after every commit.
[10:05] <jelmer> yeah, that's not something we can rely on unfortunately
[10:05] <awilkins> Phhoey. Anyway, dis you test my patch? Does it produce a similar dramatic drop in bug count on Linux?
[10:05] <jelmer> awilkins: No, that patch isn't required on Linux
[10:05] <jelmer> I also couldn't find any indication that that was necessary in the Subversion headers
[10:05] <awilkins> jelmer: This svn 1.5 or 1.4.6?
[10:06] <jelmer> both
[10:06] <awilkins> Hmm.
[10:06] <jelmer> so I suspect there's something else going wrong
[10:07] <awilkins> Ok, I'll shelve it and maybe we'll find something else wrong.
[10:16] <uws> What is the fastest bzr repository format? rich-root-pack is deemed the smallest, but is it also the fastest?
[10:16] <lifeless> well, gc-plain is the smallest, but its alpha today
[10:17] <uws> Rebasing 3 revisions I have (3 minor patches) on top 4 newly added ones in the upstream tree takes like a few minutes
[10:17] <lifeless> it should end up being the fastest too ;)
[10:17] <lifeless> uws: please file bugs on performance things; generally you souldn't need to worry about formats.
[10:17] <uws> lifeless: I wouldn't know what to say
[10:17] <lifeless> uws: rich-root-pack is the best format to be using _today_ for bzr-svn branches
[10:17] <lifeless> uws: 'I rebased and it was slow'
[10:18] <lifeless> uws: :) - givint the branch url for what you rebased would help, and the command you ran
[10:18] <uws> lifeless: I'm using bzr-svn branches indeed. pulling from svn is quite slow as well, but rebasing is bzr only right?
[10:18] <lifeless> uws: I don't know if it is or isn't bzr only :)
[10:18] <uws> the bzr-svn branch I'm using is NOT online :(
[10:18] <uws> I've mirrored WebKit trunk
[10:18] <uws> and launchpad doesn't have it in the vcs-mirror
[10:19] <lifeless> uws: ah, thats ok. Just filing a bug is sufficient to start with
[10:19] <uws> it took me a few days to build this branch
[10:19] <lifeless> whee
[10:19] <uws> I'll happily share it with launchpad if they want to
[10:19] <uws> I can upload/bzr push, pas de probleme
[10:19] <lifeless> uws: you could just push it to the bzr playground, or launchpad or ..
[10:19] <uws> yeah, but having the "official" webkit mirror seems better
[10:20] <uws> but the conversion hasn't been trivial :)
[10:20] <lifeless> is webkit in gnome svn?
[10:20] <uws> lifeless: can I push my ~1GB .bzr to launchpad? :s
[10:20] <uws> lifeless: No, webkit svn
[10:20] <lifeless> uws: sure
[10:20]  * AfC recalls the 2 days it took to build the initial gtk+ branch...
[10:21] <lifeless> uws: what was the command you ran? 'bzr rebase ... ...' ?
[10:21] <uws> lifeless: "bzr rebase" ;)
[10:21] <proppy> Hi, is there a way to convert a mercurial repository to bzr
[10:21] <uws> lifeless: I'll explain my setup
[10:21] <uws> repo  in webkit/
[10:21] <proppy> (one way for importing the code to launchpad)
[10:21] <uws> the .bzr/ dir in there is ~1GB
[10:21] <lifeless> proppy: I think there is an hg fastexport frontend
[10:21] <uws> 2 branches:   webkit.trunk  (without tree, parent is upstream svn+http url, I use this to pull upstream)
[10:21] <lifeless> proppy: so the bzr fastimport plugin is the best way to do a one-shot conversion
[10:22] <uws> other branch is webkit.uws, which is branch of the webkit.trunk branch
[10:22] <uws> I have 3 small patches in webkit.uws. when I update webkit.trunk, I run "bzr rebase" in webkit.uws to stack my own patches on top of the upstream trunk version
[10:22] <proppy> lifeless: ho just noticed there is also an hg convert to GNU arch
[10:23] <uws> gnu arch is dead, proppy ;)
[10:23] <proppy> :)
[10:23] <proppy> googling for fastimport
[10:23] <AfC> For what it's worth: I ran some experiments with rebase a few weeks ago. While it "works", the form of the command line UI seems to be very different than the rest of the code bzr commands. I kept getting tripped up as to what would happen to which branch.
[10:24] <AfC> (and instead settled on good old `bzr merge -r X..Y` for cherry picks)
[10:24] <uws> AfC: I think of "rebase" as a "shelve away all my own commits, then pull the other branch, and unshelve all my own commits"
[10:24] <AfC> uws: yeah, I sorta got that at the end.
[10:25] <uws> I want my patches to be on top of upstream, so that I can keep then in sync (and attach to bugzilla blah blah)
[10:25] <AfC> uws: I think matters were complicated by the fact that I was also trying to cherry pick selected revisions at the same time. It made a loud splat noise.
[10:25] <lifeless> uws: so, leaving aside the philosophical 'why rebase at all' discussion :) -
[10:25] <uws> not sure what happens once they commit one of my patches upstream
[10:25] <AfC> lifeless: :)
[10:25] <lifeless> uws: all you run is 'bzr rebase', no arguments at all ?
[10:25] <uws> lifeless: (I rebase because my patches need to be on top of trunk to keep them clean for upstream submission)
[10:26] <lifeless> uws: you don't need to rebase to achieve that :)
[10:26] <lifeless> uws: is http://svn.webkit.org/repository/webkit/trunk the url you bzr-svn'd ?
[10:26] <AfC> Just merging trunk into your branch and then `bzr diff -r branch:../trunk` (?) should do it, no?
[10:27] <lifeless> AfC: its the loom use case really, one thread per patch, serial merges
[10:27] <lifeless> AfC: with a flatten operation at the final commit to trunk, for folk that want that
[10:27] <AfC> lifeless: you say so :)
[10:27] <uws> lifeless: Yes, that's the url.
[10:27] <lifeless> AfC: I do!
[10:28] <lifeless> uws: how many files do your patches change?
[10:28] <uws> lifeless: all three of them just touch 1 file (3 different files in total).
[10:28] <proppy> lifeless: what is bzr fastimport frontend for mercurial
[10:28] <uws> all <5 line changes
[10:28] <proppy> front-end | bzr fast-import -
[10:29] <lifeless> proppy: yes; http://modular.math.washington.edu/home/mhansen/fast-export/hg-fast-export.txt has some stuff about hg-fast-export
[10:29] <lifeless> proppy: fast-export is a standard for exporting and importing between many different VCS systems
[10:30] <proppy>  These front-ends are bundled in the exporters/ directory of bzr-fastimport.
[10:30] <proppy> :)
[10:32] <proppy> ../bzr-fastimport/exporters/hg-fast-export.py -r ../protobuf-test/ | bzr fast-import -
[10:32] <proppy> done thanks :)
[10:32] <AfC> There are two possibilities, then: either the one shipping with bzr-fastimport is tweaked and fixed, being specific to Bazaar, or the one available from [someone in the] Mercurial [community] is newer and better, being from the foreign system who perhaps know their own system better.
[10:35] <lifeless> uws: I have filed a bug
[10:36] <uws> lifeless: CC me please, uws+launchpad@xs4all.nl
[10:37] <uws> lifeless: I'm currently trying to push my webkit.trunk mirror to lp:~uws/webkit-open-source/webkit.trunk
[10:37] <uws> wonder whether it'll work, and how long it'll take ;)
[10:37] <lifeless> :>
[10:37] <uws> at least I'm on 100MBit for the rest of the day :)
[10:38] <uws> I created the branch in launchpad using the web page, and I had to supply --use-existing-dir to bzr push
[10:38] <lifeless> yes, I think this is ugly :)
[10:39] <uws> Hmmm. "copying inventory texts 2/5"
[10:49] <awilkins> jelmer: I might be prepared to disagree with you on this "set_path" thing ; can you show me where the API says you _don't_ have to describe the revisions of every path?
[10:49] <proppy> importing to lp done, thanks lifeless and AfC
[10:50] <awilkins> jelmer: Of course, if the tests work on Linux, it's clear that something is behvaing differently ; but still, I can't find anything that says "if you don't pass any paths, it assumes that everything is revision N"
[10:57] <lifeless> proppy: cool
[11:01] <lifeless> uws: you are copied now
[11:31] <uws> lifeless: Hm?
[11:31] <uws> lifeless: ah, cc on the bug
[11:31] <uws> lifeless: I'm at "copying content texts 3/5" for my webkit.trunk push ;)
[11:32] <uws> but the repo is ~1GB ;)
[11:37] <LeoNerd> It's likely been asked a hundred times before, but... Why-oh-why do I have to give a 'push' URL the first time I push a branch..? Can it not default to the parent, the place I branched it from..?
[11:38] <LeoNerd> Similar for missing/pull/update/etc...
[11:38] <luks> that's not always the place you want to push to
[11:39] <LeoNerd> Not always, no. I suppose I could consider various other use-cases. But every time I've ever done it, that's what I've done. I imagine that's the most likely place.
[11:39] <luks> I think in most open source projects people branch over http
[11:40] <LeoNerd> OK... So just apply the default to the missing/pull/update case then...
[11:40] <LeoNerd> bzr branch http://foo/bar. ... wait a few days... bzr missing => "bzr missing: no URL specified"
[11:40] <LeoNerd> It would be nice if it just filled that in by default... even if I had to do the push one myself
[11:41] <fullermd> Don't forget the location aliases abentley put in for 1.6...   very nice.  I just wish they were documented somewhere other than NEWS.
[11:41] <jelmer> beuno, ping
[11:57] <awilkins> jelmer: I'm trying to test bzr-svn on Linux and it just says "Aborted"
[11:58] <jelmer> awilkins, what version of python?
[11:58] <awilkins> 2.5.2
[11:58] <jelmer> hmm, not sure then
[11:58] <thumper> hi jelmer
[11:58] <jelmer> any chance you can run it inside a debugger to see what it is aborting on?
[11:58] <jelmer> thumper: Hi
[11:58] <thumper> can bzr-svn import subtrees as branches?
[11:58] <thumper> jelmer: I'm thinking of kde
[11:58] <jelmer> thumper: yeah
[11:58] <awilkins> jelmer: You'd have to give me a quick pointer as to how
[11:59] <jelmer> awilkins: "make gdb-check" should do that for you
[11:59] <thumper> jelmer: any idea on how it would perform with 750K revisions (kde has one big repo)
[11:59] <thumper> jelmer: any given subtree will only have a fraction of those
[12:00] <jelmer> thumper, apparently it does work - some people have used it, but the building of the cache takes a long time apparently
[12:00] <jelmer> there has been work on allowing bzr-svn to not even look at the rest of the repository
[12:00] <jelmer> but that's not finished yet
[12:00] <thumper> jelmer: how long will it take?
[12:00] <thumper> no pressure ;-)
[12:00] <awilkins> jelmer: My installed bzr is not compatible with bzr-svn now, should I edit the makefile to point at my bzr.dev?
[12:01] <jelmer> thumper, Not sure, it's not one of the highest things on the list
[12:01] <jelmer> awilkins: yeah
[12:01] <thumper> jelmer: where's the list?
[12:01]  * thumper waves the priority wand :)
[12:01] <jelmer> thumper, It's the bugs list in lp :-)
[12:01] <jelmer> awilkins: Or just export the BZR environment variable to point at your bzr.dev
[12:02] <thumper> jelmer: is the cache reusable across multiple subtree imports?
[12:02] <jelmer> yes
[12:02] <thumper> ok, not so bad then
[12:02] <jelmer> It's about 2 gig though, from what I've heard
[12:02] <thumper> memory or disk?
[12:03] <awilkins> jelmer: Yup, figured that ; I'm now at a (gdb) prompt
[12:03] <jelmer> awilkins, just run
[12:03] <thumper> jelmer: thanks, gotta go now
[12:04] <thumper> jelmer: I may well be in touch again later :)
[12:04]  * awilkins pines for GUI debuggers
[12:04] <jelmer> thumper: ok
[12:04] <awilkins> I think I may need to install some more symbols
[12:04] <jelmer> awilkins: There's a good GTK+ based one now I think
[12:04]  * jelmer tries to remember the name
[12:05] <awilkins> lots of "no debugging symbols"
[12:05] <lifeless> LeoNerd: push is normally *not the place you branched from; at least IME
[12:05] <awilkins> It's stopped in libc.so.6
[12:05] <lifeless> LeoNerd: its only the single-developer case that you *can* push back to the place you branch from
[12:06] <awilkins> Yes, doing these things "raw" makes you a real man... I'd rather be wimp with a cyborg exo-suit than a real man naked in the desert....
[12:06] <lifeless> ;)
[12:11] <awilkins> jelmer: Are you testing on x86_32 or x86_64 ?
[12:11] <jelmer> I'm on 32bit
[12:12] <awilkins> I'm on 64
[12:13] <awilkins> I'm also trying to find th right debug symbols
[12:14]  * awilkins installs the debug python interpreter
[12:16] <awilkins> Well, that seemed to remove all the "no symbols" errors
[12:16] <awilkins> Still about as clear as mud
[12:16]  * awilkins has been spoiled by working in environment where the debugger just shows you the code that's busted :-)
[12:21]  * awilkins installs insight and ddd
[12:29] <jelmer> bug 127945
[12:29] <jelmer> lifeless, ^
[12:47] <colbrac> jelmer: What are the chances of you merging the OliveGui? :)
[12:47] <jelmer> colbrac, I'd like to at least wait for phanatic to comment
[12:48] <colbrac> jelmer: Ok.. at least it stills merges without conflict to the new trunk
[12:49] <colbrac> colbrac: The pending 'status for folders' and 'fix for broken symlink' will cause conflicts me thinks
[12:50] <colbrac> jelmer: ^ (doh.. stop talking to myself :P)
[12:53]  * colbrac needs more coffee: 'fix for broken symlink' is already merged. 
[13:14] <colbrac> jelmer: Could the 'sort bookmarks by title bundle' be merged? I promise I will remove the code duplication (which is present already) after the merge of OliveGui.
[13:14] <jelmer> re
[13:14] <jelmer> colbrac: You're yourself also free to merge changes into trunk (if they have been approved)
[13:15] <colbrac> wow! Didn't know that about that. So you change your stance from resubmit to approve?
[13:18] <jelmer> colbrac: If I voted resubmit I'd like to see a new submission to the list :-)
[13:18] <jelmer> tweak means I'm fine to see the bundle go in iff the indicated changes in my review are made (without the need for further review)
[13:18] <jelmer> I think I would actually like to see that one resubmitted
[13:20] <colbrac> jelmer: Did you read my reply on the list about this? I still think adding another helper function now, while the whole duplication between _load_left / refresh_left will be removed soon is not really useful.
[13:27] <jelmer> colbrac: I guess I could live with it then
[13:28] <colbrac> k thx :)
[13:44] <jelmer> colbrac, any chance you can review http://bundlebuggy.aaronbentley.com/project/bzr-gtk/request/%3C20080717123155.GA14537@vernstok.nl%3E?
[13:46] <colbrac> jelmer: Will take a look at it, but it's unknown territory for me
[13:49] <jelmer> It's a relatively trivial change
[13:51] <colbrac> still.. I can't even figure out how to open that 'Search revisions' dialog :P
[13:51] <colbrac> or is it that list that opens on the history button in olive?
[13:55] <jelmer> colbrac, you need to have bzr-search installed
[13:55] <jelmer> and that, in turn, needs bzr.dev or one of the 1.6 betas
[14:13] <jelmer> mvo, hi
[14:35] <colbrac> jelmer: The dialog doesn't disappear for me :/
[14:37] <colbrac> jelmer: add .destroy() somewhere
[14:44] <matkor> Is any transport faster thatn sftp: ??
[14:46] <matkor> it takes minutes do update checkout with few lines changes ...
[14:48] <lifeless> matkor: what project?
[15:03] <matkor> lifeless: mine
[15:03] <matkor> just I have big lattency link (crowded vpn)
[15:03] <matkor> but it is still long time I think .. I wonder perhaps ssh+bzr: would be better choice ?
[15:12] <mvo> hey jelmer! you pinged me earlier?
[15:13] <jelmer> mvo: Yeah, I was trying to find some way to retrieve "Vcs-*" fields from the apt cache using python-apt
[15:14] <jelmer> mvo: Is it correct that that's not possible atm?
[15:14] <mvo> jelmer: give me a minute, I should be able to sent you a example
[15:15] <lifeless> matkor: should be about the same usually; however latency hurts :(
[15:21] <mvo> jelmer: you are right, its currently not accessable because there is no way to access the full record. let me add it to the python-apt source
[15:21] <jelmer> mvo, Cool
[15:25] <mvo> jelmer: I can put a new version into my ppa, do you need hardy or intrepid debs?
[15:25] <jelmer> mvo: I'm actually on sid but I guess hardy is most useful for me at this point :-)
[15:27] <jelmer> colbrac, are you sure you meant resubmit rather than tweak?
[15:28] <colbrac> :) hum, yeah you are right.. I trust you can handle this without further review :o)
[15:36] <jelmer> mvo, where is the main python-apt branch?
[15:37] <mvo> jelmer: my development tree is at http://people.ubuntu.com/~mvo/bzr/python-apt/mvo/
[15:37] <colbrac> I installed bzr 1.6b3 from the bzr-beta ppa but now I seem to have a bzr prompt as soon as I start a gnome-terminal for every folder I enter :/
[15:39] <colbrac> that's a nice *feature* people :P
[15:39] <Odd_Bloke> colbrac: I _believe_ that's an issue with the packaging.  Look in /etc/bash.d, perhaps.
[15:39] <mvo> jelmer: I have a pbuilder sid environemnet here, I can build you a package if that is more convenient
[15:40] <Odd_Bloke> ubottu: paste
[15:40] <mvo> jelmer: I added a "Record" attribute to the PkgSrcRecord that gives you the full record
[15:40] <colbrac> thanks to etckeeper I know it's done in /etc/bash_completion.d/bzrbashprompt.sh
[15:40] <jelmer> mvo: Thanks
[15:41] <Odd_Bloke> ja1: I'm getting http://paste.ubuntu.com/28287/ when I attempt to send you mail.
[15:41] <jelmer> mvo: A sid package would be quite nice if it's not too much trouble :-)
[15:42] <jam> Odd_Bloke: odd.. can you try sending directly to john@mail.arbash-meinel.com?
[15:42] <jam> Love to put that in traceback ... ugh
[15:42] <jam> anyway
[15:42] <jam> try it
[15:44] <jam> Odd_Bloke: I know I have a greylist which requires messages to be re-sent the first time they come through
[15:44] <jam> but 550 doesn't look like the right error for that.
[15:44] <jelmer> mvo: nevermind, bzr builddeb also seems happy with your branch
[15:44] <Odd_Bloke> jam: I got http://paste.ubuntu.com/28288/ in my logs when I sent the email to john@mail.arbash-meinel.com.
[15:46] <Odd_Bloke> jam: Though it's deferred (rather than bounced as previously) so I may have just hit the greylist for that.
[15:47] <jam> Odd_Bloke: sounds like.
[15:47] <jam> You can send again in a couple minutes
[15:47] <jam> or just wait for it to retransmit
[15:48] <Odd_Bloke> jam: I'll wait. :)  The initial error seems weird though.
[15:49] <jam> yeah the 550 you were getting seems bad
[15:49] <jam> I know I have a private mail server, and domainpeople just relay it to me
[15:49] <jam> as a backup
[15:54] <jelmer> mvo, The Vcs-Bzr fields still appears to be missing
[15:55] <jelmer> mvo:while it does contain other fields such as Maintainer and Homepage
[15:56] <jelmer> mvo, e.g. Cache()["bzr"].installedRecord["Maintainer"] works but Cache()["bzr"].installedRecord["Vcs-Bzr"] doesn't
[16:01] <TejasPP> hi, is there any tutorial on how to write a plugin/hook? both user reference and user guide doesn't contain many information. they both say "look at the builtins.py". having a tutorial would be great
[16:04] <NfNitLoop> TejasPP: I think you just volunteered to write one?  ;)
[16:04] <mvo> jelmer: right, the vcs-bzr information is only available in the source package record, that is slightly more work to extract
[16:04] <TejasPP> first I should figure it out! :D
[16:05] <colbrac> exactly! :) That's what I did before I added info about giving back for bzr-gtk on the bzr wiki
[16:06] <mvo> jelmer: http://paste.ubuntu.com/28291/ is a example, its rather primitive compared to the interface that works with binary packages
[16:11] <TejasPP> so, there is no documentation on this other than user guide/reference and writingplugins page
[16:11] <jelmer> mvo, Ah, my bad
[16:11] <colbrac> jelmer: If I was going to try to move some import statements to the top of files in bzr-gtk and I find licence-less py files (like window.py), should I add a licence?
[16:11] <jelmer> mvo, Thanks, that seems to work
[16:11] <jelmer> mvo, that returns the data from the latest known version?
[16:12] <jelmer> since Lookup() seems to return only a single object, rather than multiple
[16:13] <mvo> jelmer: its a bad interface, you can run Lookup() multiple times and it will return multiple records (it will return false when there are no records left)
[16:13] <mvo> jelmer: /usr/share/doc/python-apt/examples/sources.py is a example
[16:14] <mvo> jelmer: on how to use it (this code predates my involvement with the project :)
[16:14] <jelmer> mvo: Heh, ok
[16:14] <jelmer> mvo, Thanks
[16:15] <mvo> cheers! let me know if you need anything else
[16:16] <jelmer> I'm fine for now... "bzr branch deb:<package-name>" seems to work
[16:16] <lifeless> ooooooo
[16:17] <TejasPP> do you know any example plugin which is well commented and easy to understand? or which functions I should look in builtins.py
[16:19] <jelmer> TejasPP: any particular sort of plugin you're looking to implement
[16:19] <jelmer> ?
[16:20] <jelmer> TejasPP: New command, push hook, etc?
[16:20] <TejasPP> jelmer: actually I'm trying to write a hook to indent files before commit
[16:21] <TejasPP> but it would be good opportinuty for me to learn writing plugins
[16:23] <TejasPP> jelmer: I'm reading docs and codes since last night and all I can is that: http://pastebin.ubuntu.com/28293/
[16:25] <TejasPP> /all i can/all i can do
[16:26] <jelmer> TejasPP, If you would like to do it pre-commit, you may want to add a start-commit hook
[16:26] <jelmer> TejasPP, see http://pastebin.ubuntu.com/28294/
[16:29] <mvo> jelmer: oh? that bzr branch deb:stuff is a plugin that looks for the vcs- header?
[16:30] <mvo> jelmer: if so, where can I download the plugin :)
[16:30] <jelmer> mvo: yeah - it works in a similar fashion to lp:
[16:30] <mvo> (or bzr get it) :)
[16:30] <mvo> that sounds *very* cool!
[16:30] <jelmer> mvo: I've implemented it as patch to bzr-builddeb
[16:31] <jelmer> http://people.samba.org/bzr/jelmer/bzr-builddeb/directoryservice/
[16:31] <jelmer> mvo: ^
[16:31]  * mvo bzr gets
[16:37] <mvo> jelmer: works for me, that is hot stuff :)
[16:37] <jelmer> cool :-)
[16:41] <TejasPP> jelmer: I've wrote that: http://pastebin.ubuntu.com/28297/
[16:41] <TejasPP> I think I need a list of files which is modified
[16:53]  * lamont has a randomly-strange use case...  bzr update against a tree that has had an uncommit fails (for good reasons).  I want to force it to do the uncommit here as well.  is that doable short of rm -rf .bzr and re-branch?
[17:04] <awilkins> That fast-wak-win32 patch is awesome
[17:04] <awilkins> *walk
[17:04] <awilkins> Status on a 28,469 element tree - 2 seconds
[17:06] <lifeless> bit slow
[17:06] <awilkins> :-P
[17:07] <awilkins> Yeah, I'm doing this java thing that eats am XML model and spits ASP pages ... it's IO bound... well, it is on Windows
[17:07] <awilkins> On Linux it takes the same time whether you output to RAM disk or real disk
[17:07] <awilkins> And 1:35 instead of 2:30
[17:07] <lifeless> jelmer: ping
[17:09] <lifeless> jam: ping
[17:09] <awilkins> I don't think jam is even here
[17:09] <lifeless> lamont: for mirrors, don't use update; use a normal branch and pull --overwrite && bzr revert
[17:10] <lamont> lifeless: cool
[17:10] <lifeless> (I told Ng already)
[17:10] <lamont> yeah
[17:11] <lamont> fixing it is so much easier than teaching people to not use bzr uncommit on a published branch. :(
[17:11] <lamont> and do I really not have a way to have per-branch hook scripts?
[17:11] <liw> http://www.reddit.com/info/6sf0l/comments/
[17:12] <awilkins> lamont: You could do a hook script that examines the revid of the first revision in the branch
[17:12] <lamont> awilkins: I want diff hook scripts for diff repos, and don't want to have to change the hook script each time...
[17:13] <lamont> I'd be more inclined to have a hook script that examined .bzr/$MUMBLE and ran it if it was there.
[17:13] <lifeless> lamont: exactly
[17:13] <liw> (interesting question on that reddit page, nothing interesting in the answers yet)
[17:13] <lifeless> lamont: for instance, bzr-email checks for a email_to configuration item
[17:13] <lamont> because lack of per-branch hook scripts is something that even clearcase didn't do.
[17:13] <lamont> lifeless: that's a good place to start
[17:14] <lifeless> lamont: which will pickup from  branch.conf or locations.conf or bazaar.conf automatically
[17:14] <lifeless> la	don't conflate 'per branch' with 'code is instanlled locally'
[17:14] <lifeless> damn, I mean globally. damn australian saturated email link fuckage
[17:14] <lamont> lifeless: what I really want is something to bolt into uncommit that says 'no, you already published this, you ninny'
[17:15] <lamont> lifeless: one of these days I'll take the time and corner the right people/docs to figure out how to get my use model in bzr:  one directory, lots of branches and switch between them when I want.  this one directory-per-branch thing offends my sensibilities.  (while I recognize that many people prefer that)(
[17:15] <lamont> so yeah, what I really mean is "per repo" :-)
[17:16] <lamont> and _that_ is conflation at its finest
[17:16] <lifeless> lamont: so why should that *not* work on every branch? just check the public_ocation of the branch and if it is nothing cancel, otherwise try to connect and check
[17:16] <lifeless> lamont - or better yet, record the last revision pushed in a hook, and then you can check locally
[17:17] <awilkins> lamont: Make a no-trees repo, make a subfolder for the branches, put branches in it. Then make a checkout folder, and use `bzr switch` when you please
[17:17] <lamont> awilkins: concept understood.  about 20% of the words in that sentence obviously require recursion...  hence "sometime when I'm not at work" :)
[17:17] <lifeless> lamont: and yes, as awilkins says, we *totally* support lots of branches and switch
[17:18] <lifeless> lamont: it is :
[17:18] <lifeless> $bzr init-repo foo --no-trees
[17:18] <lifeless> bzr branch THING foo/branch1
[17:18] <lifeless> bzr branch foo/branch1 foo/branch2
[17:18] <lifeless> ...
[17:18] <lifeless> bzr checkout --lightweight foo/branch1 place-to-edit-source
[17:18] <lifeless> cd place-to-edit-source
[17:18] <lifeless> hack
[17:18] <lifeless> bzr commit
[17:18] <lifeless> bzr switch branch2
[17:18] <lifeless> etc
[17:18] <lamont> ah, and --no-trees means that it doesn't create a foo/branch1 directory mess under $CWD
[17:19] <lifeless> no-trees means that 'bzr branch' does not give you the source code to edit in the branch directoy
[17:19] <lamont> and can place-to-edit-source be "."?  (I expect not)
[17:19] <awilkins> You still have a branch1 directory but it has no sources in it
[17:19] <lifeless> lamont: yes it can be .
[17:19] <lamont> ah, ok
[17:20] <lamont> I'll play later, and hug my scrollback
[17:20] <lifeless> lamont: (but I would tend not to use . because you wouldoften want several working trees with different CFLAG options etc
[17:20] <lamont> those go in the exported source tree, which has .bzr nuked...
[17:20] <lamont> and then sbuild chroots into the right place and does the build for me
[17:21] <lifeless> right, well - give it a play
[17:21] <lifeless> file bugs as appropriate
[17:22] <lifeless> you'll prbably mneed to ignore foo if you have the checkout above it :)
[17:26] <VSpike> If I want to split a source file into two smaller parts, is there any way to tell bzr of this?
[17:30] <liw> that reddit thread makes it pretty clear already that people using cvs and svn really hate branching and merging
[17:30] <liw> (news at 11)
[17:31] <liw> VSpike, I was going to suggest "bzr copy" but it doesn't seem to exist, hmm
[17:32] <LarstiQ> lifeless: speaking about copy, how are path tokens or a replacement scheme doing?
[17:36] <VSpike> liw: I can't see any commands that apply, but yeah copy would make sense if it existed
[17:37] <Odd_Bloke> liw: :D
[17:37] <liw> VSpike, yeah, I'm thinking you should just start a new file and "bzr add" that as if it were completely new
[17:37] <liw> VSpike, but you may want to wait a bit in case one of the people who actually know bzr wake up
[17:40] <Odd_Bloke> AFAIK, it's not possible ATM.
[17:40] <Odd_Bloke> The things LarstiQ mentioned would be ways of making it possible.
[17:42] <LarstiQ> last time I paid attention there were concerns about troublesome copy semantics, but that was a while ago.
[17:44] <liw> Odd_Bloke, I see you on that thread!
[17:51] <pickscrape> Yesterday I accidentally upgraded to 1.6b3 because of it being accidentally uploaded to the wrong PPA, but now I can't get 1.5 to install again
[17:51] <pickscrape> I uninstalled bzr, but reinstalling it just brings in the hardy version (1.3.1)
[17:52] <pickscrape> I still have the PPA in my sources.list
[17:52] <pickscrape> Oh wait...
[17:52] <pickscrape> 1.5 isn't in the PPA for hardy
[17:53] <pickscrape> That explains it. :) Anyone know when 1.5 for hardy will be uploaded to the PPA again?
[17:53] <james_w> pickscrape: you could check /var/cache/apt/archives/ to see if it has the 1.5 version
[17:54] <james_w> Martin seemed to hint that he was going to re-upload 1.5 to ~bzr and put 1.6b3 in ~bzr-beta-ppa
[17:54] <pickscrape> james_w: unfortunately not :(
[17:55] <pickscrape> We're going to be migrating from svk to bzr within the next week. Scary.
[17:56] <awilkins> To be honest, I've used both and svk is much scarier than bzr
[17:56] <pickscrape> Oh, I don't mean that bzr is more scary than svk
[17:56] <awilkins> No, the conversion!
[17:56]  * awilkins fears
[17:57] <pickscrape> It's just a big change, and most of our developers really don't care about version control at all.
[17:57] <awilkins> I'm having to teach bzr to a team of business modellers who've only ever used MKS (which is a sort of eveil propritary hybrid CVS) but automated via a huge lump of Java
[17:58] <awilkins> Currently their tools sit still for 10 minutes every time you open them synching their files to MKS
[17:58] <awilkins> Contrast this to about 10 seconds doing a bzr pull and they start to care about version control
[18:00] <awilkins> I mean, the other team I work for had been contemplating for 2 years whether to use VSS or CVS, so I converted them to SVN in my first two weeks of employment and was accused of "having made the single greatest contribution to production quality on the project"
[18:01] <awilkins> TortoiseSVN taking most of the credit for making it understandable to mere mortals
[18:01] <pickscrape> nice
[18:01]  * awilkins is a bit of a VCS geek
[18:01] <pickscrape> Right now I'm struggling to get everyone to even have a play with bzr using the demo migration I've already performed for them.
[18:02] <pickscrape> no doubt when we actually bite the bullet they'll then complain that they don't know how to use it
[18:02] <awilkins> Any like-minded "pathfinders" in the group?
[18:02] <pickscrape> You mean people who actually care? :)
[18:03] <pickscrape> There are a few, yes
[18:03] <awilkins> It took me a few days to get my head round it, and I've been admin-ing SVN and VSS for years, but it was less painful than learning to merge in svk
[18:03] <awilkins> Concentrate on the few, not the many. A choir sings better than a soloist
[18:04] <awilkins> better/louder
[18:04] <pickscrape> svk has become unscalable for us. The depot size is now 12GB. pulling some branches is now impossible because it exhausts memory. Syncing some revisions also becomes a massive memory drain that people struggle to complete.
[18:04] <awilkins> svk was a major improvement for me because I could take work home in a version-controlled way
[18:04] <awilkins> Ouch
[18:04] <pickscrape> Our main draw to svk was for the merge tracking.
[18:05] <awilkins> Yes, I found that SVK really, really ate CPU for no discernible reason
[18:05] <pickscrape> I even contributed to the SVK book a few years back.
[18:05] <pickscrape> My name's still on it I think
[18:05] <pickscrape> It just seems to have died though
[18:05] <awilkins> I mean, it's pulling deltas from the server which it should be able to just shove back into your local depot raw ; why does it eat so much CPU?
[18:06] <pickscrape> Yes, that confuses me too. And it seems to have got much worse of late too, inexplicably.
[18:06] <awilkins> Esp. the Linux builds which actually work when using replay API
[18:06] <pickscrape> The best thing though is that when you add, say, an image to trunk, that image gets duplicated every time you pull trunk to a branch
[18:06] <awilkins> Replay doesn't save much though, it just means you don't have to report when you start a transaction
[18:06] <pickscrape> One of the reasons why our depot got to 12G :)
[18:07] <awilkins> That's... yuck
[18:07] <pickscrape> Can you imagine the fun we have setting up a new developer? :)
[18:07] <awilkins> How big is your converted bzr repo?
[18:08] <pickscrape> We haven't imported history: too much chaff. the shared repo of the import of HEAD takes up about 79M, spread over a few separate repositories
[18:08] <awilkins> I think my biggest repo is still under 2GB, but people are working on it, they keep checking in huge trees of XMLSpy documentation output and the like
[18:09] <awilkins> If I can get the tip of 0.4 working properly in windows, I'll convert it over using bzr-svn and see where it goes from there
[18:09] <pickscrape> following over 40k revisions of doing it wrong, we figured we'd start afresh and do it right :)
[18:10] <awilkins> Any ideas about why that problem is occurring, jelmer?
[18:10] <awilkins> pickscrape: Depends on how many branches you are supporting actively in the old depot I suppose
[18:11] <pickscrape> awilkins: I think I need to migrate about 20 at the moment.
[20:22] <Percept> Hi, can anyone direct me to some information how to use bzr (or any other CVS for that matter) with webprojects which have a database like MySQL?
[20:22] <Percept> since the database is always located at another place then the folder with my files
[20:22] <Percept> realises this is prolly a stupid question)
[20:23] <Odd_Bloke> Percept: Normally you would only keep your database schema in version control, with something else to take care of backing your database up.
[20:24] <Percept> Odd_Bloke: ah so it's not common practice to have the DB with content in version control then?
[20:25] <Percept> Odd_Bloke: doesn't sepperating the db-backup from vc make the whole thing less managable? I'm really new to VCS but I really need to learn
[20:27] <Percept> I read the user guide ... seems easy enough just didn't get how to deal with databases
[20:46] <Percept> getting your database under VCS http://www.codinghorror.com/blog/archives/000743.html and http://www.martinfowler.com/articles/evodb.html
[20:51] <jam> Percept: well, that also sounds like it is someone selling a product :)
[20:51] <jam> I would generally always keep the schema under VCS
[20:52] <jam> It sort of depends on how critical the *data* in the database is
[20:52] <Percept> jam: the ccomments are interesting :)
[20:52] <jam> Most DB's I've seen the database itself should be backed up, but the actual *data* wasn't something I would version
[20:52] <Percept> which referred me to the second lin
[20:52] <Percept> link*
[20:52] <jam> Just like I would version the program I'm writing
[20:52] <jam> but I wouldn't version the generated output
[20:53] <jam> Reading the comments, they seem to be saying approx the same thing
[20:53] <Percept> jam ok sounds logic (now ... was really lost on how people managed their DB's)
[20:53] <jam> that it is the *schema* that they care about
[20:54] <jam> The DBs I worked with had everything written in .sql files, and some python scripts to load that into the DB, and take care of stuff like upgrading.
[20:55] <jam> I know Launchpad even has stricter rules for versioning. In that patches that make changes to the schema can only be landed at certain times, etc.
[20:56] <Percept> I read something about luanchpad in the user docs but I don't really kno what it is yet
[20:56] <Percept> gotta start ith the basics first :)
[20:56] <Percept> with*
[23:41] <LaserJock> is there a way to branch a specific range of revisions?
[23:41] <LaserJock> I want to branch everything up to a certain revision
[23:42] <cody-somerville> LaserJock, -r
[23:42] <LaserJock> that only gets a specific revision
[23:43] <beuno> LaserJock, -r ..X?
[23:43] <LaserJock> wait no, cody was right
[23:44] <LaserJock> the documentation messed me up
[23:48] <TejasPP> jelmer, recently I saw your shell-hooks plugin and it's great