[00:00] <jelmer> yep
[00:00] <lifeless> jelmer: can you document what you need from the hook? I can likely do the bzr side trivially
[00:01] <jelmer> https://bugs.launchpad.net/bzr/+bug/186422
[00:01] <ubotu> Launchpad bug 186422 in bzr "Ability to modify the tree from a pre-commit hook" [Wishlist,Triaged]
[00:02] <lifeless> is in-python sufficient
[00:02] <jelmer> the summary should probably be changed to "Add a start-commit hook"
[00:02] <jelmer> lifeless: yes
[00:03] <lifeless> k
[00:10] <lucasvo> hi
[00:10] <lucasvo> I'm having issues with bzr. It doesn't want to work if locales isn't set correctly...
[00:10] <lucasvo> see: http://paste.ubuntu-nl.org/57277/
[00:10] <lifeless> thats correct; you can set LANG=C etc if you have really broken locales on your machine
[00:11] <lifeless> but to get the correct i18n filename we need locale information
[00:11] <jelmer> shouldn't it be "locale en_US.UTF-8" rather than "locale enUS.UTF-8" ?
[00:11] <lucasvo> lifeless: I am using gnome terminal with an ssh session
[00:12] <lucasvo> if I set  encoding to western in gnome terminal it works
[00:12] <lucasvo> I usually have it on utf-8
[00:12] <lifeless> jelmer: yeah, I think so
[00:12] <lifeless> lucasvo: as long as its set to a valid locale bzr will work fine
[00:12] <lucasvo> so that is not a bug.
[00:13] <lifeless> lucasvo: we have to recreate the files you commit, with their names, on different operating systems
[00:13] <lifeless> lucasvo: some (mac os X) require unicode paths.
[00:13] <lifeless> lucasvo: so we have to know the actual unicode path of each file we read from disk
[00:14] <lucasvo> ok
[00:14] <LaserJock> would it be possible to get bzr-svn in the bzr LP PPA?
[00:14] <lifeless> lucasvo: and to do that we need to know if you are using 8859-{1,3,...} or utf8 or utf16 or utf7 or whatever
[00:14] <jelmer> LaserJock: it's already there
[00:15] <lifeless> lucasvo: so yes, it is a _requirement_ that your locale be set up accurately for bzr to work. if its complaining, you have a bug in your locale setup.
[00:15] <LaserJock> jelmer: you sure? I don't have it here
[00:15] <jelmer> a traceback shouldn't be necessary for this error though
[00:16] <LaserJock> jelmer: ah, I see the problem, there is a version in -backports that overrides the one in the PPA
[00:16] <jelmer> LaserJock: Yes, it's only in feistry, gutsy and hardy though
[00:16] <lifeless> jelmer: its being thrown from python's core
[00:17] <lifeless> jelmer: we could catch and pretty it up I guess
[00:17] <LaserJock> jelmer: gutsy-packports has 0.4.7-1~gutsy1 and the PPA has 0.4.6-1~bazaar1~gutsy1
[00:17] <lucasvo> ok, well, I gotta move over to the ubuntu channel and try my luck there. Thanks for the help guys.
[00:18] <LaserJock> dang, even if you put in 0.4.7 it'd be a lower version than -backports :/
[00:20] <jelmer> LaserJock: what exactly is so problematic about that? in the end, you have the latest version
[00:20] <jelmer> lifeless: yeah, that would make sen
[00:20] <jelmer> se
[00:20] <LaserJock> umm, because I either can't upgrade bzr or I have to remove bzr-svn
[00:21] <LaserJock> not sure why bzr-svn has such a tight dependency, but I'm assuming the maintainer knew what they were doing
[00:21] <jelmer> LaserJock: bzr-svn gets very easily broken by bzr API changes
[00:21] <LaserJock> fun
[00:21] <LaserJock> so right now I'm not updating bzr/bzr-tools so I don't remove bzr-svn
[00:22] <jelmer> LaserJock: ah, that bit is unrelated to the packaging
[00:22] <jelmer> I simply haven't released bzr-svn 0.4.8 compatible with bzr 1.2 yet
[00:22] <lifeless> tsk tsk
[00:22] <lifeless> :)
[00:22] <LaserJock> ah
[00:23]  * LaserJock tries to resist a "that's why git is nice" comment ;-)
[00:23] <LaserJock> but instead I'll wait patiently
[00:29] <LaserJock> although, I'm using bzr-svn because it seems a lot better than git-svn
[00:30] <LaserJock> so I should just hold my tongue
[00:38] <jelmer> Sorry for not being quicker with this
[00:38] <jelmer> Although I don't see why it would be an immediate problem
[00:40] <jelmer> LaserJock: git-svn doesn't have the same level of integration that bzr-svn has so it doesn't use the same range of the API
[00:41] <jelmer> LaserJock: if we would make the dependencies of bzr-svn less tight bzr-svn would probably break every other upgrade of bzr
[00:42] <LaserJock> jelmer: right, I figured it must be something similar
[00:42] <LaserJock> I just wondered if it was a known thing as I've been unable to upgrade bzr for something like a week or so
[00:42] <LaserJock> but it seems that really gutsy-backports is more to blame
[00:43] <jelmer> LaserJock: why?
[00:44] <LaserJock> because -backports has 0.4.7
[00:44] <LaserJock> I was thinking that the bzr PPA didn't have bzr-svn in it
[00:44] <jelmer> yes, but what's problematic about backports having 0.4.7?
[00:44] <lifeless> is 0.4.7 released ?
[00:45] <jelmer> yes
[00:45] <jelmer> 0.4.7 is compatible with bzr 1.1
[00:45] <lifeless> LaserJock: actually I think aptitude is to blame; if bzr's ppa has a matching bzr-svn, aptitude should be able to resolve to install that over backports; unless you've got pinning set
[00:45] <jelmer> lifeless: ppa doesn't have a more recent version than backports
[00:45] <lifeless> jelmer: I know that
[00:45] <LaserJock> jelmer: it's just that it means I'm getting bzr from bzr PPA but not bzr-svn
[00:46] <lifeless> jelmer: I didn't say more recent; I said matching.
[00:46] <jelmer> lifeless: There is no matching bzr-svn for the latest bzr in PPA
[00:46] <lifeless> jelmer: there we go :)
[00:46] <lifeless> LaserJock: so its really just that bzr-svn has not recently this week yet
[00:47] <jelmer> lifeless: Right, but I fail to see how LaserJock is blaming that on backports rather than on me :-)
[00:47] <LaserJock> well, I'm just saying it's nice to get the whole set from the same repo
[00:47] <LaserJock> rather than bits from one and bits from another
[00:48] <LaserJock> but of course, in this case, I guess I'd be in the same situation even if I didn't have -backports
[00:51] <jelmer> the version of bzr-svn in backports is newer
[00:51] <jelmer> ~bzr comes after ~backports
[00:52] <jelmer> hmm, no that's not right..
[00:52]  * jelmer gets some sleep before he says more stupid things
[00:52] <LaserJock> -backports uses ~gutsy
[00:52] <LaserJock> wasn't stupid
[00:52] <LaserJock> versioning sucks ;-)
[01:03]  * lifeless waits for 11K unit tests.
[01:03] <lifeless> poolie: if you are touching logging again; I would like to remove logging to disk entirely for tests. Its pointless to write a log when we can introspect it in python; less disk io is good.
[02:10] <ubotu> New bug: #195282 in bzr-loom "new revision spec needed - below:" [High,Triaged] https://launchpad.net/bugs/195282
[02:13] <lifeless> bob2: ping
[02:14] <bob2> hi
[02:15] <lifeless> hows your nicer-error patch coming? I just got forcibly reminded of it :)
[02:26] <poolie> lifeless: i'm not at present but will try to remember that
[02:31] <poolie> lifeless: quick call sometime
[02:31]  * igc food
[02:31] <lifeless> poolie: sure; now ?
[02:31] <poolie> sure
[02:32] <lifeless> please find my house phone for me
[02:32] <poolie> lol
[02:33] <lifeless> damn charge
[02:35] <fullermd> Holy crud.
[02:35] <fullermd> I just watched that talk Bryan Cantrill did at Google about dtrace.  That's insane how deep it gets its fingers into python.
[02:43] <keir> so, is loom headed for core? seems like incredibly useful functionality, and is something the other systems don't do as well.
[03:12] <lifeless> keir: well, I think it will get smoothly integrated; I don't know that it belongs in core
[03:12] <lifeless> bob2: hows your nicer-error patch coming? I just got forcibly reminded of it :)
[03:12] <poolie> thumper: hi?
[03:16] <bob2> lifeless: updating tests.blackbox atm
[03:17] <lifeless> bob2: cool
[03:18] <bob2> lifeless: ooi, is the arg ordering of assertEqual('literal', var) deliberate?
[03:18] <lifeless> bob2: our convention is expected, actual
[03:18] <lifeless> so 'literal' is what we want.
[03:18] <bob2> lifeless: right
[03:35] <thumper> poolie: hi
[05:17] <lifeless> bbiab, late lunch time
[06:59] <lifeless> spiv: ping
[07:00] <lifeless> spiv: is urlutils.escape(user_supplied_url) the right way to get a ascii url ?
[07:09] <jml> did 1.2 change things about when Branches let go of http connections?
[07:11] <lifeless> it shouldn't have; why ?
[07:11] <lifeless> you may be seeing pycurl vs non pycurl ?
[07:13] <jml> maybe
[07:13] <jml> there's no pycurl in the stack
[07:13] <lifeless> what are you seeing happen ?
[07:14] <jml> lifeless: the test suite is complaining about how there are sockets in the garbage after certain of our tests that do stuff with http
[07:14] <lifeless> interesting
[07:14] <lifeless> you may have found a bug I guess?
[07:14] <jml> specifically, a socket._fileobject
[07:14] <lifeless> I'd need to look closely in the log; you can do that:O - look for stuff from vila
[07:22] <jml> it's possible that we're holding on to a reference too long or that the gc is doing something stupid
[07:22] <lifeless> try a gc collect?
[07:23] <jml> or both
[07:23] <jml> my money's on both
[07:23] <jml> s/the gc/the calls to the gc/
[07:23] <lifeless> one thing that is likely is that persistent connections are better
[07:23] <lifeless> that is, that we won't drop them after every call, I'm sure vila was working on that
[07:28] <lifeless> yay:
[07:28] <lifeless>  du -sh ../thallow/
[07:28] <lifeless> 72K     ../thallow/
[07:30] <lifeless> thats a shallow branch
[07:40] <lifeless> wow slow though
[07:40] <lifeless> 1m24 to create over sftp
[08:31]  * igc dinner
[08:33] <lifeless> ok, bzr push is whackily slow ; that or too much data.
[08:46] <lifeless> ah link fuggage
[09:01] <ubotu> New bug: #195360 in bzr "bzrtools 1.2 in feisty ppa: broken depends on bzr" [Undecided,New] https://launchpad.net/bugs/195360
[09:26] <lifeless> muhahaha it works: ~/source/baz/shallow-branch/bzr log -r -1 http://people.ubuntu.com/~robertc/test-shallow/3
[09:26] <lifeless> using http://people.ubuntu.com/~robertc/baz2.0/shallow-branch
[09:29]  * bob2 branches
[09:39] <bob2> oh that's what all the stackable thing was about
[09:39] <jrydberg_> hi guys
[09:49] <lifeless> bob2: extremely small branches
[09:54] <lifeless> http://people.ubuntu.com/~robertc/test-shallow/4 has a commit in it
[09:54] <lifeless> total repo size - 56K
[09:54] <lifeless>  du -sh public_html/test-shallow/4/.bzr/repository
[09:54] <lifeless> 56K     public_html/test-shallow/4/.bzr/repository
[09:55] <lifeless> bob2: ^
[10:18] <bob2> that's quite cool
[10:18] <Prodoc> Good mornin'
[10:19] <Prodoc> I'm trying to install the Bazaar Eclipse plugin using the following instructions: http://bazaar-vcs.org/BzrEclipse/Installation
[10:21] <Prodoc> After selecting the latest version it will try to download the plugin but I get an error that an exception occurred downloading the .jar file
[10:21] <bob2> lifeless: is that bluesky or 1.3 material?
[10:21] <Prodoc> it's only after a couple of retry's that it appears to work
[10:21] <Prodoc> is this a known issue?
[10:23] <lifeless> bob2: 1.3 I hope
[10:36] <mrflip> Hello, I am just moving over to bzr.  Here is my question.  I'm working on a website, and the project is the main dir site/ with subdirectories srcassets/ (original copies of graphics, etc), meta/ (design notes), utils/ (tools), web/ (the actual site).
[10:36] <mrflip> When I deploy, I want to only push site/web/ to the server, which was easy with svn
[10:36] <mrflip> how do I do this with bzr?
[10:40] <bob2> bzr split would let you split that dir into it's own branch
[10:40] <bob2> or you could just not import the others into bzr
[10:40] <bob2> but bzr doesn't generally work like svn, where each dir is a nested checkout
[10:43] <mrflip> (reading about bzr split now)...  I definitely need all of those dirs versioned... and I need to have (somehow or another) site/* on my dev machine and only web/ on the server.
[10:57] <mrflip> so I think I have to move web/ into its own repos, which I can live with... it's tiny compared to srcassets, which I can't afford to pull each time I deploy.
[10:57] <mrflip> Thanks for the help bob2
[10:58] <bob2> doesn't have to be it's own repository, just branch
[10:58] <bob2> well, depending on how you do it I guess
[11:25] <ubotu> New bug: #195397 in bzr "Bazaar does not follow the Freedesktop XDG Base Directory Specification" [Undecided,New] https://launchpad.net/bugs/195397
[13:59] <adwi2> jelmer: Could the ability of bzr to use a SVN repository be used to create a branch that used a SVN repository that one could push back into another SVN repository with bzr-svn?
[14:04] <jelmer> awilkins: Yes
[14:04] <jelmer> it wouldn't create a copy of the original svn branch in the other svn repository though
[14:05] <jelmer> at least, it won't look like a copy to svn
[14:05] <jelmer> it will look like one to bzr
[14:05] <awilkins> jelmer: What I essentially want is what SVK does but using bzr, I suppose
[14:06] <awilkins> I have an Eclipse ticket plugin that syncs to SVN
[14:06] <awilkins> But I'm rapidly leaning toward BZR for the other version control aspects of this project because the branch / merge requirements are rigourous and I'm probably going to end up re-inventing merge tracking if I stick to SVN
[14:07] <awilkins> Alas, the ticket plugin is closed-source (what a dumbass I was to recommend that one...)_
[14:07] <awilkins> And doesn't use the geenric Eclipse team sync, as far as I can tell.
[14:08] <awilkins> Ah, I shall just have to experiment.
[14:08] <awilkins> I shall be using BZR for dev and testing just because it's so much faster than SVN :-)
[14:08] <awilkins> It'll save me more time tha it'll take to re-roll things in SVN if I have to.
[14:43] <jelmer> re
[14:43] <jelmer> awilkins: yes, bzr-svn is usable in a svk-like style
[14:44] <jelmer> that's what it was originally designed for
[14:49] <xif> is branching and merging with Bazaar less of a headache than it is with Subversion?
[14:50] <edreamleo> Hello All, this is Edward Ream from the Leo editor
[14:51] <Peng> xif: Yes.
[14:52] <Peng> xif: Any modern VCS, including bzr, tracks which revisions have already been merged.
[14:52] <Peng> xif: Of course, that makes cherrypicking a pain in most of them...
[14:53] <edreamleo> Is this the place to ask total newbie questions?
[14:53] <jdong> edreamleo: any bzr related question :)
[14:53] <Peng> edreamleo: Sure.
[14:53] <jdong> or any question you'd want a bzr related answer to :D
[14:53] <edreamleo> ;-)
[14:53] <edreamleo> First, let me say I'm excited about moving Leo to bzr.
[14:54] <edreamleo> It will enable much closer cooperation between Leo and IPython.
[14:54] <edreamleo> I have been able to get bzr working on XP...
[14:54] <edreamleo> But am having trouble connecting on Linux
[14:54] <xif> Peng: if I plan to do lots of branching and merging, would you recommend Bazaar or anything else?
[14:55] <edreamleo> I suspect the problem is easily fixed, but I have no idea how to fix it.
[14:55] <jdong> xif: I'd definitely recommend some distributed VCS with a 3-way merge algorithm. bzr's defnitely nice for it but it's not the only one
[14:55] <jdong> edreamleo: can you describe more what kind of trouble you're having when connecting?
[14:55] <edreamleo> Sure.
[14:56] <Peng> xif: Sure, I'd recommend bzr or anything else that's not cvs or svn. :P
[14:56] <edreamleo> I have pull defined as a bzr alias. One moment while I look it up...
[14:56] <xif> jdong: yeah, I'm still contemplating whether I want hg, darcs, or bzr
[14:57] <jdong> xif: well I think between those 3, the answer all of us in #bzr will give you is obvious ;-)
[14:57] <xif> from what I've seen, hg has better performance, bzr has more features
[14:57] <jdong> xif: I don't think that's entirely true anymore
[14:57] <xif> ("seen" = "read in online reviews" :-)
[14:57] <jdong> xif: recent versions of bzr come quite close in performance, storage size, etc
[14:57] <jdong> xif: it is true that older versions of bzr have horrendous performance compared to hg
[14:58] <xif> right, before you rewrote some of the Python modules in Pyrex
[14:58] <xif> yeah, I think I'll check bzr out first
[14:58] <Peng> And made other improvements.
[14:58] <xif> Peng: such as?
[14:58] <jdong> xif: and changed on-disk storage format, etc
[14:58] <xif> oh, right.
[14:58] <Peng> xif: General improvement of the code?
[14:58] <xif> now your storage format is git-like I hear.
[14:58] <Peng> Sorta, yeah.
[14:59] <jdong> xif: there's far too many performance tweaks for us to list one by one short of reproducing the changelogs
[14:59] <Peng> For me, it's really a toss-up between bzr and hg, but I haven't used anything else (other than svn).
[14:59] <xif> not sure how darcs fits in the comparison, doesn't look like it can compete with hg or bzr on either performance or features.
[15:00] <jdong> yeah, my unbiased toss-up would be between bzr, hg, and git
[15:00] <Peng> I haven't looked into git much.
[15:00] <xif> Peng: aren't there features you miss on hg vs. bzr or vice-versa?
[15:00] <edreamleo> Ooops.  pull is not an alias
[15:00] <Peng> xif: Yeah.
[15:00] <jdong> xif: bzr's vast array of plugins... seems like there's more of them than for hg
[15:00] <xif> I prefer hg and bzr (or even darcs) because Python and Haskell are nice languages.
[15:01] <jdong> xif: also, hg is horrible without its smart server IMO
[15:01] <jdong> xif: which is a problem if you don't have the access to install hg on the remote system
[15:01] <Peng> Indeed.
[15:01] <jdong> bzr's non-smart-server performance is quite good with packs
[15:02] <xif> jdong: so if I want to stay lightweight (e.g. using the VCS to manage my own project) bzr might be a better choice?
[15:02] <Peng> And even if the performance was poorer, at least it supports dumb servers fully.
[15:02] <edreamleo> Ok, now I remember, I did a bzr co, not a bzr pull
[15:02] <Peng> (Well, it is poor*er*, just not that much worse.)
[15:02] <edreamleo> co *is* an alias
[15:02] <Peng> If I was smarter, I'd work on SFTP support for hg...
[15:02] <jdong> xif: I'd believe so.
[15:03] <jdong> Peng: last time I tried dumb HTTP, it didn't work well either
[15:03] <xif> OK, thanks.
[15:03] <jdong> Peng: and the response I got upstream was "well it's outdated, set up a CGI"
[15:03] <Peng> jdong: Heh.
[15:03] <Peng> jdong: I didn't know it was outdated.
[15:03] <Peng> jdong: I don't know how good it is now.
[15:04] <Peng> jdong: I've always had the impression that it doesn't get quite enough love, but I don't know whether it's still good enough.
[15:04] <jdong> Peng: well apparently thy are considering oldhttp to be obsolete
[15:04] <edreamleo> co is defined as co=checkout bzr+ssh://edreamleo@bazaar.launchpad/~edreamleo/leo-editor/main
[15:04] <edreamleo> now when I do a bzr co I get a Python traceback
[15:04] <LeoNerd> Who keeps highlighting me? :P
[15:04] <jdong> Peng: but I was surprised that they do not support SFTP
[15:05] <Peng> edreamleo: "co" is a builtin alias.
[15:05] <edreamleo> Oh!
[15:05] <Peng> edreamleo: (for "checkout")
[15:05] <Peng> jdong: I asked once, and mpm mentioned that he wouldn't want to add a dependency on Paramiko or whatever.
[15:05] <edreamleo> Right, that's what I was trying to do :-)
[15:06] <edreamleo> Trust a newbie to find the ways to crash a program.
[15:06] <Peng> :)
[15:06] <edreamleo> Ok, let me pick another name for co and see what happens...
[15:06] <Peng> edreamleo: Are you using bzr 1.2? If not, upgrade; if so, file a bug.
[15:06] <Peng> edreamleo: You shouldn't need to co the same branch so often that you need an alias for it...
[15:07] <jdong> edreamleo: also, why is the alias necessary? Do you really checkout that branch enough times that you don't want to type it out?
[15:07] <jdong> Peng: we're trampling over each other :D
[15:07] <edreamleo> I'm using bzr 0.90.0
[15:08] <jdong> edreamleo: I highly recommend upgrading to the latest
[15:08] <edreamleo> Iirc I used apt-get (or maybe the synaptic package manage) to get the latest version
[15:08] <jdong> edreamleo: what distribution?
[15:08] <edreamleo> Ubuntu, Gutsy Gibbon
[15:09] <jdong> edreamleo: you can either (1) enable backports, or (2) use the bzr PPA
[15:09] <jdong> although I'm the maintainer of backports, I recommend #2
[15:09] <edreamleo> What's the bzr PPA?
[15:09] <jdong> I've got hundreds of requests for updates and I can't keep backports as up to date as fast as the bzr PPA
[15:09] <Peng> edreamleo: Bzr's official apt repo thingamabob. https://launchpad.net/~bzr/+archive
[15:09] <jdong> edreamleo: it's an APT repository maintained by the bzr developers
[15:10] <Peng> (Though they do have a habit of screwing up bzrtools's dependencies... :P )
[15:10] <jdong> edreamleo: it contains the latest bzr packages, plus minus a few days ;-)
[15:10] <jdong> Peng: hehe well I'm guilty of doing the same
[15:10] <Peng> I'm hungry.
[15:10] <jdong> backports is currently on bzr 1.1, though I do intend on updating to bzr 1.2 once Hardy's entire stack is ready
[15:11] <jdong> but backports gives you other cool new packages too ;-)
[15:12] <edreamleo> Ok, I see bzr-1.2.-1~bazaar2~gutsy1 at the url you gave.
[15:12] <edreamleo> Are there installation instructions?
[15:12] <jdong> edreamleo: the page should have such instructions
[15:13] <jdong> edreamleo: pick Gutsy from the dropdown....
[15:13] <jdong> edreamleo: add the "deb" line to Software Sources Manager in system->admin
[15:13] <jdong> the deb-src line is optional
[15:17] <edreamleo> I did system->admin->software soucrces...
[15:18] <edreamleo> Now I see a dialog, with 5 tabs...
[15:18] <edreamleo> What's the "deb" line?
[15:18] <jdong> elmo: click Third Party Software, then Add
[15:19] <jdong> grr wrong person
[15:19] <jdong> he doesn't need to know how to add sources lines... :)
[15:19] <edreamleo> Heh, heh,
[15:19] <jdong> in the dialog that pops up, type deb http://ppa.launchpad.net/bzr/ubuntu gutsy main
[15:22] <edreamleo> djong: ok, that seemed to work.
[15:22] <edreamleo> Do I do an apt-get now?  If so, what would I do exactly?
[15:24] <edreamleo> Never mind, the latest version now shows up in the package manager.  Doing an update now.
[15:24] <jdong> edreamleo: you can pop up update manager or synaptic, check and apply for new updates
[15:29] <edreamleo> Ok, we have progress...
[15:29] <edreamleo> Now we have bzr 1.2.0
[15:30] <edreamleo> And now bzr co (still with the confusing co alias) doesn't crash, it says...
[15:30] <jdong> edreamleo: run bzr reconcile and bzr upgrade on your existing branches to bring them to the new faster packs format
[15:30] <edreamleo> ssh: connect to host bazaar.launchpad prt 22: connection refused
[15:31] <edreamleo> Ok.  bzr reconcile and bzr upgrade made what seem like happy sounds.
[15:32] <jdong> edreamleo: bazaar.launchpad.net
[15:32] <jdong> unless you're one of those lucky people on the .net domain :D
[15:34] <edreamle1> Drat: something weird happened to gaim.
[15:36] <edreamle1> gdong: I'll check the url and change the co alias to something else...
[15:36] <jdong> edreamleo: yeah the URL is the only problem I see
[15:41] <Peng> Also, again, why are you checking out the same thing so often that you need an alias?
[15:42] <dato> Peng: bzr provides the alias
[15:43] <edreamle1> Peng: my memory isn't the best, so I like to leave bread crumbs around wherever possible.
[15:43] <edreamle1> Success: the bad url was the problem
[15:43] <jdong> edreamleo: you'd probably want to alias your branch location as a branch
[15:43] <jdong> rather than alias the entire co command to one branch
[15:43] <edreamle1> Btw, bzr co worked just fine, even with co as an alias
[15:43] <jdong> edreamleo: after the initial checkout, you never have to type the branch URL again
[15:43] <jdong> just "bzr up, bzr commit, bzr log" all work inside the branch
[15:44] <jdong> so I don't see the point of making the co=checkout branch alias.
[15:44] <edreamle1> jdong: you must be right :-)
[15:45] <edreamle1> jdong: but what if I wanted to check out another sandbox?  Wouldn't I need to know the url?
[15:46] <Peng> Is it possbile to checkout or branch a checkout?
[15:47] <jdong> Peng: yes
[15:47] <jdong> edreamle1: indeed, but you can branch from your existing checkout
[15:47] <jdong> edreamle1: or type "bzr info" inside the branch to figure out what URL it was from
[15:47] <edreamle1> jdong: Thanks for these tips.
[15:47] <edreamle1> Clearly, I don't understand bzr branches yet...
[15:49] <edreamle1> Anyway, many thanks for your help.  I'm unstuck.
[18:00] <Odd_Bloke> Does anyone know anything about http://article.gmane.org/gmane.emacs.devel/89117 ?
[18:02] <Peng> Odd_Bloke: No. It's been confirmed as true, but there's still no information.
[18:03] <Peng> Odd_Bloke: Ask Mark Shuttleworth or poolie?
[18:03]  * Peng shrugs.
[18:03] <Peng> Ok.
[18:03] <Odd_Bloke> OK, it's the confirmation that I was looking for.
[18:04] <Odd_Bloke> Peng: Thanks. :)
[18:04] <Peng> The confirmation isn't very useful when I have no idea what it *means*.
[18:05] <Peng> RMS is replacing poolie as lead developer? Mark Shuttleworth paid them $10,000 to get "GNU" stamped on bzr?
[18:05] <Peng> Of course, I could do research and see what exactly it usually means, but I'm busy reading about Star Trek.
[18:06] <abentley> Peng: It means nothing in terms of personnel.  It means that GNU will endorse bzr, use it for their own projects, and update Savannah to support it.
[18:07] <Toksyuryel> awesome!
[18:07] <Peng> Right. It's just marketing.
[18:07] <Peng> I forgot.
[18:07] <abentley> It does mean that there are certain rules we must follow.  I forget the details at the moment.
[18:07] <Toksyuryel> yay bzr ^_^
[18:07] <Peng> You said that earlier. :P
[18:08] <Toksyuryel> What does it mean with regards to launchpad?
[18:08] <abentley> Well, if you're gonna get snotty, I don't have to say anything...
[18:08] <johnny> Toksyuryel, nothing afaics
[18:09] <Odd_Bloke> The list of things that have to be complied with is at http://www.gnu.org/prep/maintain/
[18:09] <Peng> I'm only being a tiny bit snotty.
[18:09] <Peng> And that's non-sarcastic.
[18:09] <Peng> I completely forgot that you explained it earlier.
[18:10] <Peng> Odd_Bloke: Yikes, 100K of ASCII?
[18:10] <diocles> Odd_Bloke: There's also the GNU Coding Standards, and maybe a few other documents.
[18:11] <Toksyuryel> it's not really fair to call it "just marketing", I think that bzr being endorsed by GNU is a pretty damn big deal
[18:13]  * Toksyuryel thinks that it shows just how good bzr is, that they would choose it over other things out there :) it also grants a lot of additional credibility to the project
[18:13] <diocles> Peng: http://www.gnu.org/help/evaluation.html#whatmeans would seem to answer your questions, but I realise Star Trek is important.
[18:15] <Toksyuryel> Stargate is better~ *hides*
[18:15] <Peng> Toksyuryel: What about Firefly?
[18:15] <johnny> they're all dumb :)
[18:15] <abentley> I'm not aware of any direct effects on Launchpad, though it does turn Savannah into a Launchpad competitor.
[18:15] <johnny> that should solve it..
[18:15] <johnny> barely..
[18:15] <johnny> a very very poor one
[18:15] <Toksyuryel> I never watched firefly, I heard good things about it though
[18:16] <Toksyuryel> abentley: my concern is more related to the issue of the fact it's not a free/open project (yet)
[18:16] <Peng> Toksyuryel: Same here. I'm afraid that whenever I do finally watch it, it won't live up to my expectations thanks to the hype. :\
[18:16] <johnny> Toksyuryel, has no effect on bzr
[18:16] <Peng> diocles: Thanks. I have 550 tabs open!
[18:17] <Toksyuryel> mmkay
[18:17] <johnny> launchpad is the only reason i'm considering using bzr seriously
[18:17] <johnny> which is upsetting, since it's not free
[18:17] <Toksyuryel> there's a lot of great things about bzr completely unrelated to launchpad...
[18:17] <johnny> like?
[18:18] <diocles> johnny: What are you comparing bzr with?
[18:18]  * Toksyuryel personally considers it to be the best vcs of them all, period ^_^
[18:18] <Peng> The GNU documents mentions using an @gnu.org address for bugs, and hosting on gnu.org. What is bzr going to do?
[18:18] <johnny> i mean above and beyond git,mtn,hg
[18:18] <johnny> Peng, the docs mention that
[18:18] <johnny> there's notice you put on there
[18:19] <Toksyuryel> bzr is way way better than git and hg. not sure what mtn is but bzr is probably better than that too :)
[18:19] <johnny> how so?
[18:19] <johnny> how is it better than git or hg?
[18:19] <johnny> other than being much easier to use than git :)
[18:19] <Peng> Toksyuryel: Monotone.
[18:19] <johnny> hg is not really in my consideration tho
[18:19] <Toksyuryel> there are documents on the website that do a way better job explaining than I ever could
[18:19] <Peng> Toksyuryel: Kinda inspired git and hg, but not very popular. Slow.
[18:19] <johnny> i've read them Toksyuryel
[18:19] <Toksyuryel> eww, ok, bzr is definitely better than that XD
[18:20] <Peng> Toksyuryel: Gaim/Pidgin used it, last I checked.
[18:20] <johnny> and i wasn't convinced
[18:20] <Toksyuryel> well I was
[18:20] <Peng> johnny: Why not hg?
[18:20] <johnny> bzr has launchpad, hg doesn't bzr has the potential to be tested across 1000s of projects
[18:20]  * Toksyuryel is even considering using it to version his entire system, but thinks he may need a bigger hard drive for that
[18:20] <johnny> hg has a few, and moz..
[18:21] <johnny> but bzr will always have the edge due to launchpad
[18:21] <Peng> Toksyuryel: Don't do that.
[18:21] <johnny> since it mirrors everything in bzr
[18:21] <Peng> Toksyuryel: I do; it sucks.
[18:21] <johnny> Toksyuryel, bzr doesn't handle privs
[18:21] <johnny> at least not last i heard..
[18:21] <Toksyuryel> ohh
[18:21] <Toksyuryel> yeah that could be tricky...
[18:21] <Peng> Oh, that's true.
[18:22] <johnny> you need seperate sfotware
[18:22] <diocles> johnny: The other advantage over git might be Windows support. But that never bothered me.
[18:22] <james_w> johnny: there will hopefully be a plugin to handle that at some point.
[18:22] <Peng> None of the popular VCSes handle more than the exec bit.
[18:22] <johnny> yes
[18:22] <Peng> I don't version my whole system, just my homedir.
[18:22] <johnny> Pe is correct
[18:22] <Peng> And I'm reducing that today.
[18:22] <james_w> for now you can check out etckeeper, which there is a bzr plugin for.
[18:22] <johnny> err Peng is correct
[18:22]  * Toksyuryel has never considered windows support to be a feature, rather finds it to distract people from the features that matter
[18:23] <johnny> i'm concerned about windows support
[18:23] <johnny> but git is mostly used by the hardc0re
[18:23] <johnny> and the speedsfreaks
[18:23] <Peng> Toksyuryel: (Especially since Windows support is a rough spot in both bzr and hg; at least case-insensitive file system stuff. Cough.)
[18:23] <diocles> I use git.
[18:23] <Toksyuryel> don't the benchmarks say bzr is faster than git?
[18:23] <johnny> no
[18:23] <johnny> try mirring the kernel and proving it
[18:23] <johnny> with full changes
[18:23] <Toksyuryel> dependant on the size of the project of course; they are working on that part :)
[18:23] <johnny> or moz for that matter
[18:24]  * diocles tries to work out whether he's "hardc0re" or a "speedsfreak".
[18:24] <johnny> Toksyuryel, i know what they are working on :)
[18:24] <johnny> i really really like in mtn how revisions are not dependent on a branch
[18:24] <johnny> a branch is just a cert on a revision
[18:24] <Toksyuryel> Peng: I find windows support to be a waste of time and resources that could better be spent improving the software =/
[18:24] <johnny> Toksyuryel, you're wrong
[18:24] <johnny> more devs come because of windows
[18:25] <johnny> and even more users come
[18:25] <Toksyuryel> they should switch to a real OS =/
[18:25] <johnny> and that is?
[18:25] <johnny> does it run autocad? or photoshop? :)
[18:25] <johnny> this is sad for me to have to say this :(
[18:25] <johnny> but it's true
[18:25] <Toksyuryel> that's not the fault of the OS
[18:26] <johnny> sure, but the OS doesn't mean much if it can't run apps
[18:26] <Toksyuryel> and photoshop is easily replaced besides
[18:26] <johnny> no it isn't
[18:26] <jdong> Toksyuryel: no it's not...
[18:26] <johnny> google is spending alot of money on wine support now tho
[18:26] <Toksyuryel> GIMP, inkscape, probably some other stuff out there too
[18:26] <johnny> nope
[18:26] <johnny> they are all weak
[18:26] <jdong> Toksyuryel: you've got to be kidding
[18:26] <Odd_Bloke> Guys, arguing about why people should switch from Windows in #bzr is kinda OT...
[18:26]  * Toksyuryel stops then
[18:26] <jdong> Toksyuryel: that's like saying gwbasic roughly replaces C
[18:27] <jdong> but at any rate, if you don't care about Windows, then windows support is not something to look at in your VCS of choice :)
[18:27] <johnny> i've used linux only on the desktop for 5 years now Toksyuryel .. and even i can't say those apps have proper replacements :)
[18:28] <jdong> likewise. I've used Linux for a few years and developed on it for a few less than that
[18:28] <jdong> I can say FOR ME I've found Linux replacements
[18:29] <jdong> but I can't say for every application there is a Linux replacement
[18:29] <diocles> Tut, tut, it's GNU/Linux. Don't you know bzr is a GNU project now?
[18:29] <jdong> that's completely nonsense
[18:29] <jdong> diocles: no it's not, I use a BSD userland ;-)
[18:29] <Peng> Who needs Photoshop; I can write JPEG by hand. With a magnet, up hill in the snow all three ways.
[18:29] <johnny> lol
[18:29] <diocles> jdong: I bet you don't. :)
[18:29] <jdong> diocles: how do you know? :)
[18:29] <johnny> it is possible tho
[18:30] <johnny> or the opposite ..
[18:30] <diocles> jdong: Because Ubuntu doesn't have a BSD port.
[18:30] <jdong> diocles: and that's where you start assuming :)
[18:31] <jdong> but ANYWAY, still OT :)
[18:31] <johnny> unless bzr won't run on that combination.. :)
[18:31] <jdong> johnny: A few of us here have independently got bzr running on IronPython
[18:31] <Toksyuryel> bzr ought to run on any POSIX-compliant system... I think
[18:32] <jdong> Toksyuryel: more than that :)
[18:32]  * jdong feels sorry for all the bzr devs who will be reading this scrollback
[18:33] <johnny> jdong, but then the boycottnovell guys will come after you !
[18:33] <johnny> lol
[18:34] <abentley> johnny: Bzr handles only the execute bit, not other privs.
[18:34] <johnny> abentley, i know :)
[18:34] <abentley> Oh, I thought you didn't because of how you phrased it.
[18:35] <johnny> supporting windows is difficult for sure :(
[18:35] <Toksyuryel> hmmm... The requested URL /bzr.1.2/en/release-notes/NEWS.html was not found on this server.
[18:37] <abentley> johnny: In most DVCses, branches link to revisions, and the revisions themselves are not tied to any particular branch.
[18:38] <johnny> maybe it's not as exposed in bzr in the docs then
[18:38] <johnny> i read over the user guide , and that other one
[18:40] <james_w> Toksyuryel: there is a missing symlink, someone reported it to the list already, but it doesn't seem to have been added yet
[18:40] <Toksyuryel> ok
[19:07] <Vadi> I'm trying to 'push' a branch online, but I get an 'Not a branch:' error. Is there some specific setup I need to have on my local folder or something?
[19:08] <Odd_Bloke> Vadi: What cmmand are you running?
[19:09] <Vadi> "bzr push bzr+ssh://vperetokin@bazaar.launchpad.net/~vperetokin/vadi-mapper/main"
[19:10] <Odd_Bloke> Vadi: That suggests that you're not in the branch when running the command.
[19:10] <Vadi> Ahah. Now what exactly does that mean? I'm in a folder on my laptop, that I want to upload the contents of on the branch (new to this)
[19:12] <Odd_Bloke> Vadi: OK, you'll need to use 'bzr init' to create an initially empty branch.
[19:12] <Odd_Bloke> Then you'll want to use 'bzr add' to add all of the files in the directory to the branch.
[19:12] <Odd_Bloke> s/branch/working tree/
[19:13] <Odd_Bloke> Then you'll want to commit the changes in your working tree (i.e. everything) to a revision of the branch, using 'bzr commit -m "Initial import."'
[19:14] <Odd_Bloke> The part in "s is the commit message, which will show up in the log of the branch.
[19:16] <Vadi> Where do I specify the branch I want to commit to?
[19:16] <Vadi> I got the bzr init'd and add'd
[19:19] <Vadi> Ahah, okay. I think I got it.
[19:20] <Vadi> I got a exceptions.AssertionError :(
[19:23] <abentley> Vadi: please copy the traceback into a pastebin
[19:23] <abentley> ubotu: paste
[19:23] <ubotu> pastebin is a service to post multiple-lines texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the channel topic)
[19:24] <Vadi> abentley - here you go: http://paste.ubuntu-nl.org/57363/
[19:24] <Vadi> I might have screwed up my ssh key, I'm not entirely sure.
[19:25] <abentley> I was just about to suggest doing sftp manually.
[19:25] <abentley> Just to make sure it's set up properly.
[19:25] <abentley> Also, you might consider upgrading to 1.2
[19:26] <Vadi> How? To both suggestions..
[19:26] <Vadi> I'm on Ubuntu 7.10.
[19:28] <jdong> # Implementation. Implement your chosen code design in Java. You might find that you want to make changes to your design. You are free to do this, but should record the changes so it is clear what the original design was and what changes you made to it.
[19:28] <jdong> # --> Test. Run the staff test suite using the test framework provided. If your program fails any of the tests, correct the problem, and rerun the test suite. Create at least three additional test cases of your own, that demonstrate the robustness of your Multipart implementation.
[19:28] <jdong> oops
[19:28] <jdong> stupid paste button
[19:29] <jdong> I meant to paste https://launchpad.net/~bzr/+archive
[19:34] <lifeless> moin
[19:35] <abentley> Vadi: for the first: "$ sftp vperetokin@bazaar.launchpad.net"
[19:36] <abentley> For the second, http://bazaar-vcs.org/DistroDownloads
[20:27] <awilkins> Random offtopic question : recommend a home office colour laser (scanner optional)
[20:36] <lifeless> no idea
[20:41] <ubotu> New bug: #195560 in bzr "version-info {clean} doesn't work" [Undecided,New] https://launchpad.net/bugs/195560
[21:18] <blueyed> wow... "bzr revert" after "bzr add" deletes files?? 8/
[21:20] <LaserJock> revert says "go back" so yeah
[21:20] <blueyed> well.. "only" the symlinks..
[21:20] <blueyed> LaserJock: nah.. I wanted to undo the add.. not delete files that were already there...
[21:20] <LaserJock> hmm
[21:21] <mwhudson> there should be backup files .~1~ or whatever
[21:21] <blueyed> bug 87548
[21:21] <ubotu> Launchpad bug 87548 in bzr "bzr add and revert on symlink deletes symlink" [Undecided,Invalid] https://launchpad.net/bugs/87548
[21:21] <blueyed> mwhudson: nope.. /etc/alternatives is now nearly empty..
[21:21] <mwhudson> LaserJock: i finally started the openbabel import btw
[21:21] <mwhudson> blueyed: oops!
[21:22] <lifeless> blueyed: this is the difference between 'undo' and 'revert' - undo needs to know exactly what sequence of things has occured
[21:22] <LaserJock> mwhudson: awesome, thanks
[21:22] <lifeless> blueyed: revert just puts them back the way they were
[21:22] <lifeless> you undo an action, and revert to a state
[21:23] <blueyed> lifeless: the way they were? e.g. /etc/rc?.d/ wasn't empty before "add". but it's after "revert".
[21:23] <blueyed> I just did "bzr init; bzr add;", thought "well, add some ignores first", so "bzr revert" and oooops..
[21:24] <blueyed> lifeless: there's no "good" undo, is there?
[21:26] <lifeless> blueyed: no we don't have an undo, I'm not aware of a vcs that has one - its actually quite unwieldy. Anyhow, that said - I think its a bug that we didn't make backup files called .~1~ of each symlink
[21:26] <lifeless> blueyed: (unless we did ?)
[21:27] <blueyed> lifeless: no.. also not for empty directories like ".common/vim/.svn/props/"
[21:27] <blueyed> so, where's my backup of "/etc"? :/
[21:28] <dato> lifeless: uh, if `bzr add regularfile; bzr revert` does not remove/rename regularfile, why would it not behave the same for symlinks?
[21:28] <blueyed> dato: exactly my thinking.. (including empty dirs)
[21:28] <Vad1> abentley: Hiya
[21:30] <abentley> Vad1: Hi.
[21:31]  * abentley is inclined to fix revert so that it always deletes files, thus not leading people down the garden path.
[21:31] <shagbag> lifeless, I'm running the command: bzr co http://bazaar.launchpad.net/~awn-extras/awn-extras/trunk awn-extras-bzr -r 347
[21:31] <shagbag> and it's taking a LONG time to 'transfer'
[21:32] <Vad1> abentley: I'm still having that error with bzr. Do you know if there's a .deb of the 1.2 version? I'm running 0.9 right now.
[21:33] <abentley> Yes, there is.  Did you see the link I posted?
[21:33] <Vad1> No, but it somehow was opened in firefox already. I was wondering if I was dilusional
[21:33] <Vad1> Whew.
[21:34] <Vad1> (how did you do that though?)
[21:36] <dato> abentley: so how does one undo an add before commit? rm?
[21:36] <Vad1> A bit better this time, but still not quite there: http://paste.ubuntu-nl.org/57373/
[21:36] <abentley> dato: Yes.
[21:37] <lifeless> blueyed: there isn't one, because revert was doing what it is designed to do. That said,  I think we can provide more of a safety net
[21:37] <abentley> Although, I call it "remove", because it's not the same thing as rm.
[21:37] <blueyed> abentley: and how would you undo an "add"?
[21:37] <lifeless> abentley: we can define merge-hashes for links and dirs too
[21:37] <abentley> blueyed: see above.
[21:37] <lifeless> shagbag: its in knit format, knit format is slow.
[21:37] <abentley> lifeless: Not for dirs.
[21:37] <Vad1> I did paste the public ssh key in my ubuntu profile. Not sure what can be wrong - but then again, I couldn't find clear instructions on how to do all of this either.
[21:38] <lifeless> blueyed: 'bzr rm --keep --new'
[21:38] <blueyed> ah.. I see..
[21:38] <lifeless> abentley: yes, we can - sha1('\x00'.join(sort(child.name for child in dir._children)))
[21:39] <blueyed> but I expect "rm" to be more bad to my data than "revert"..
[21:39] <ryanakca> Is it possible to commit in someone's name (other than going sudo -u jsmith bzr commit -m "ponies") ?
[21:39] <abentley> blueyed: So call it "remove" instead.  both work.
[21:39] <lifeless> ryanakca: sure, long as they are not expecting gpg signed commits ;)
[21:39] <lifeless> ryanakca: also see --author IIRC
[21:40] <blueyed> for me, the previous state is "unknown" for those symlinks, empty dirs (and files) in general.
[21:40] <ryanakca> lifeless: okies, thanks :)
[21:40] <lifeless> yes, --author
[21:40] <lifeless> to commit
[21:40] <abentley> lifeless: I don't think that's a clear indicator of whether the directory was automatically created.
[21:41] <lifeless> abentley: merge-hashes records the hash value of a file that we write to disk, IIRC ?
[21:42] <lifeless> abentley: so if we create a directory with 'foo' 'bar' and 'baz', we can look at disk and see that it actually has 'foo', 'bar', 'baz', 'baz.pyc' and conclude that its been altered since.
[21:43] <abentley> Technically, yes.  But the connotation is that the content was generated automatically, not subject to user info.  For example, even though shelf rewrites files, it doesn't update merge-hashes.
[21:43] <blueyed> lifeless: so it's at least a bug that there are no ~1~ files, yes?
[21:44] <lifeless> blueyed: I think its arguable that that is the case.
[21:44] <lifeless> abentley: got you
[21:45] <Vad1> What does a "Permission denied (publickey)." in bazaar mean? It
[21:45] <Vad1> It's not exactly unique, so google doesn't help
[21:46] <lifeless> Vad1: thats being reported by ssh, not bzr
[21:46] <TFKyle> Vad1: if it's while pushing/pulling to sftp it's likely that the other end requires ssh public key authentication and bzr/your ssh client didn't provide any (or you didn't get your passphrase right possibly)
[21:46] <shagbag> lifeless: thanks.  the command worked tonight (unlike last night).  I'm trying the
[21:47] <shagbag> lifeless: thanks, it's downloaded (unlike last night) and compiling now.
[21:47] <Vad1> TFKyle: Okay, how can I do it without the keys?
[21:47] <Vad1> TFKyle: I can't find clear instructions that work anywhere for uploading. The ones I'm going by right now are here (http://ddaa.net/blog/launchpad/bzr-hosting)
[21:48] <lifeless> shagbag: contact the branch owner and get them to upgrade with bzr 1.0 or newer
[21:48] <TFKyle> Vad1: you'd have to configure the server to accept things other than public keys, with openssh have a look at /etc/ssh/ssshd_config
[21:48] <lifeless> shagbag: it will massively improve performance
[21:48] <Odd_Bloke> Vad1: If you're trying to upload to Lauchpad, you need to have an SSH key set up.
[21:49] <TFKyle> but yeah, with lp you need a public key
[21:49] <Vad1> Okay, I do have one in my profile in launchpad
[21:49] <Vad1> Do I need one on my laptop too or?
[21:49] <Odd_Bloke> Vad1: When you create a public key, it generates a private key and a public key.  You should have uploaded the public key.
[21:50] <Odd_Bloke> Vad1: If you haven't created one on your laptop yet, then yes.
[21:50] <Vad1> Right, I uploaded the public key
[21:50] <Vad1> What to do with the private one?
[21:50] <LaserJock> it should be in ~/.ssh/
[21:50] <Odd_Bloke> Vad1: It should have been generated in the correct place, IIRC.
[21:50] <Vad1> Any specific file name?
[21:51] <Vad1> I did it on my server :/
[21:51] <LaserJock> I have a id_dsa in ~/.ssh/
[21:51] <LaserJock> if you have that you can scp that over
[21:53] <blueyed> Wouldn't it be possible to detect a "revert" before any commit, so that no files would get deleted? (I've read in bug 193980 that the problem only is too less information to have "proper" "undo")
[21:53] <ubotu> Launchpad bug 193980 in bzr "revert after add destroy my working tree" [Undecided,New] https://launchpad.net/bugs/193980
[22:00] <ubotu> New bug: #195578 in bzr ""bzr revert" does not backup symlinks and empty directories" [Undecided,New] https://launchpad.net/bugs/195578
[22:29] <igc> morning
[22:30] <lifeless> hi
[22:35] <lifeless> abentley: ping
[22:35] <abentley> lifeless: pong
[22:35] <lifeless> whats a good test to crib from that works with public locations?
[22:36] <lifeless> I want bzr push --shallow to default to looking for the parent branches public location
[22:36] <abentley> Maybe a merge directive test?
[22:37] <lifeless> k I'll look thanks
[22:40] <igc> lifeless: I'm wondering whether we ought to put an upper bound on the auto-repacking
[22:40] <lifeless> igc: we should fix the bugs marked 'pack'
[22:40] <igc> in my OOo import, the repack of 10 10,000 packs has been going for 14 hours now
[22:41] <igc> and in still stage 2/5
[22:41] <lifeless> igc: you are at 100K revisions?
[22:41] <igc> yup
[22:41] <igc> there's 300,000+ just in trunk
[22:41] <igc> the full rpeo is closer to 500,000
[22:42] <igc> I wondering whether 10,000 packs is big enough and beyond that we should only manually pack
[22:44] <lifeless> so, thats very slow. We should fix it being slow
[22:44] <lifeless> igc: with 10 packs you have 10 times the latency problem of 1 pack.
[22:45] <lifeless> igc: please get a lsprof of it.
[22:45] <lifeless> igc: hint: you can cp -a the repository while pack is active
[22:45] <lifeless> igc: then you can break lock and run 'pack' manually to lsprof it
[22:45] <igc> ok
[22:46] <lifeless> igc: so I don't think number of things to rearrange is the issue; because - its exponential backoff
[22:46] <lifeless> igc: the new pack this 10x10K operation creates will not be altered again at all by bzr during your import
[22:47] <lifeless> igc: clearly though we have a performance problem in the pack logic and we should fix that
[22:48] <igc> and memory pressure as well
[22:48] <igc> I think it's lack of memory (4G) that is causing the issue
[22:48] <igc> but 4G isn't 'lack of memory'
[22:48] <lifeless> so
[22:48] <lifeless> pack streams data
[22:49] <lifeless> it holds two things: the index, and an individual delta in memory at a time
[22:49] <lifeless> it uses a readv interface; a bug there would cause very high memory pressure
[22:50] <lifeless> and it buffers writes crudely; a bug there could lead to high memory pressure if you have many big deltas
[22:50] <lifeless> (but many small deltas will be fine)
[22:50] <lifeless> it could be the index builder
[22:51] <igc> thanks for the info
[22:51] <lifeless> it could be the memory pressure of the index
[22:51] <igc> I'll go digging later today
[22:51] <lifeless> so yeah - backup the repo before it completes so that we can reproduce it
[22:51] <igc> shall do so now
[22:51] <lifeless> and get a basic handle on whats wrong and I'll help fix that
[22:52] <igc> ok
[22:52] <foom> does bzr write out profile data even if you interrupt an operation, these days?
[22:52] <lifeless> for instance we may need to start tape-sorting the index we are creating incrementally with very large index sizes
[22:52] <lifeless> foom: maybe; ctrl-\ + a little prodding will let you finish early though :)
[23:07] <lifeless> is there a way to do optional strings on an option?
[23:07] <lifeless>  --reference=bar, with --reference when given defaulting to something e.g. auto:// ?
[23:08] <lifeless> I'd like to not have two options (--shallow and --reference=url)
[23:12] <poolie> lifeless: i see your point but i think it's bad style
[23:12] <spiv> lifeless: hmm, I don't think so.  How would that disambiguate between "--reference unrelated_argument" and "--reference bar"?
[23:12] <poolie> confusing when people say --option SOMETHING
[23:12] <lifeless> yeah
[23:13] <poolie> wot he said
[23:13] <lifeless> this has already occured to me
[23:13] <lifeless> but I still thought I'd ask
[23:41] <Prodoc> I accidentally added some folders I didn't want to track using 'bzr add' (windows xp), now when I try to remove those folders using 'bzr remove <folder name>' I get an error message: 'bzr: ERROR: Can't safely remove modified or unknown files:', can someone explain what's going on here? Is this a bug or should I exclude the folders in a different way?
[23:44] <lifeless> bzr rm --new --keep
[23:45] <Prodoc> --new?
[23:47] <lifeless> bzr help rm
[23:48] <Prodoc> heh, of course, thank. I'm ashamed to admit that I'm too much used to GUI's :-$
[23:49] <Prodoc> it worked, cheers lifeless
[23:57] <lifeless> poolie: np