[01:12] <idnar> bzr: ERROR: No module named configobj
[01:12] <idnar> is there some way to make that more verbose?
[01:13] <idnar> ah, .bzr.log has a traceback
[01:13] <lifeless> -Derror
[01:13] <tct_> hi, bzr started crashing on me today when i tried to commit
[01:14] <idnar> I guess bzr-fastimport is out of date wrt bzrlib, or something
[01:14] <tct_> any ideas?  trackback is here: http://pastebin.com/aiUXNkWm
[01:14] <lifeless> idnar: I think we stopped bundling configobj
[01:15] <lifeless> idnar: fastimport should be importing the system configobj, if it wants to play with configobj directly.
[01:15] <idnar> lifeless: yeah, this code tries to do "import bzrlib.util.configobj.configobj as configobj"
[01:15] <lifeless> yeah, naughty.
[01:15] <lifeless> tct_: most folk are on leave with easter
[01:15] <lifeless> tct_: you might file a bug
[01:18] <tct_> thanks, will do
[01:19] <idnar> what... the heck is fast-import doing
[01:19] <idnar> I suppose I should just create the destination myself
[02:04] <lifeless> poolie: I <3 google - lmirrors pypi page is the first hit for 'lmirror' :>
[02:05] <poolie> that's pretty quick
[07:21] <vila> hi all !
[09:16] <GaryvdM> Hi all
[09:25] <reyman> hello guys
[09:30] <GaryvdM> Hello reyman
[09:35] <reyman> i have question about bzr, and i see anything about that in help  ...
[09:35] <reyman> i'm working with launchpad, and i want to work in a decentralized workflow
[09:36] <bialix> hi all
[09:37] <reyman> i checkout a trunk branch, but when i try to duplicate in a local branch with branch command, bzr says me " trunk is not a branch" :/
[09:37] <reyman> hi bialix
[09:40] <bialix> reyman: I don't understand your problem
[09:40] <bialix> maybe it helps if you pastebin shell session
[09:41] <bialix> or example of commands
[09:42] <reyman> i make first a "bzr checkout /myproject/trunk trunk" , a mirror if i understand correctly the help.
[09:43] <reyman> then i want to work in decentralized workflow, users commit on local branch before mergin with human gate keeper on launchpad
[09:43] <bialix> checkout is the checkout or bound branch. It's not exactly mirror
[09:43] <GaryvdM> hi bialix
[09:44] <bialix> you can convert your checkout to the simple branch with command `bzr unbind`
[09:44] <bialix> hi GaryvdM !
[09:44] <reyman> ok
[09:45] <reyman> about mirror branch the help says : "To create a mirror branch, set-up a shared repository (if you haven’t already) and then use the branch (or checkout) command to create the mirror"
[09:46] <reyman> but why create a checkout branch, if i need to unbind after to duplicate the checkout with branch command
[09:47] <reyman> it's impossible to make a "bzr branch trunk newTrunk" when trunk is a "checkout mirror"
[09:47] <bialix> reyman: why it's impossible? it's not true AFAIK
[09:47] <fullermd> No it's not...
[09:48] <bialix> hi fullermd !
[09:53] <AndrewLuecke> ello
[09:53] <bialix> olle
[09:53] <fullermd> lole?
[09:54] <bialix> leol?
[09:54] <AndrewLuecke> I hate to admit, I've been against Bazaar for a while, but now thinking of setting up a new revision control system.. Been comparing bzr and git.. Bazaar looks nice, but I'm just wondering if there are any updated benchmarks?
[09:54]  * AndrewLuecke has a 1-2GB repo
[09:55]  * bialix does not think bzr can beat git on such repo
[09:55] <AndrewLuecke> Everyone seems to be saying Git is much faster, (and they both seem to have good features, with bzr more polished).. But the other benefits I see for bazaar seem to put it in the running
[09:56] <AndrewLuecke> Yeah.. but I don't need it to beat all cases, but just not be much slower than SVN..
[09:56] <fullermd> I doubt it's arguable that git will be faster.  But will git be pleasant, and bzr unpleasant?
[09:56] <fullermd> Doubt you could say without trying.
[09:57] <reyman> bialix: so ok it's possible, but i try and i don't understand why i fail with this command :s
[09:57] <AndrewLuecke> well, been going through the features, addons, etc.
[09:57] <bialix> reyman: pastebin please
[09:57] <reyman> oki thx bialix
[09:57] <bialix> reyman: also I'm not native english speaker it's hard to understand you what's wrong
[09:58] <GaryvdM> bla - I don have my gpg key here.  going to pop in to work to get it. See you all later.
[09:58] <reyman> i'm not native english too :] with bad bad bad english
[09:59] <AndrewLuecke> from your opinions though, does Bazaar feel like it gets really slow?
[09:59] <bialix> !pastebin
[10:00] <bialix> reyman: ^
[10:00] <fullermd> Well, I've never used it with a 2 gig repo.  There are a lot of variables other than size that have huge effects on speed too.  It depends on shape of history, size and shape of tree, yada yada.
[10:01] <bialix> AndrewLuecke: if you want to know what is slow, you can try to run benchmarks on Windows
[10:02] <AndrewLuecke> yeah.. only prob is, I'm in Australia, so quota'ed internet.. Must save downloads.. Not sure I could run a good comparison (maybe a local one I guess, but not sure how useful that would be)
[10:02] <AndrewLuecke> but anyway, if it was woefully slow, I guess there wouldn't be as many people here, as there are now..
[10:03]  * AndrewLuecke put up with SVN for this long anyway
[10:04] <bialix> one of my past coworkers said one day: the result of meterings is highly dependent on the methods of measuring.
[10:04] <bialix> so mostly all benchmarks lies
[10:04] <bialix> only your PC and the operations you're interested is make sense
[10:04] <AndrewLuecke> yeah.. Normally I would stick the tree into both.. But hard to say
[10:05] <AndrewLuecke> fact is, we don't know yet fully what is needed, because we are forking an open source project
[10:07] <artagnon> What's the bzr equivalent of git reset --hard <sha1>?
[10:07] <AndrewLuecke> meh.. fedge it.. maybe I will give them a proper test (technically, the code can be broken into 3 trees anyway, so each would only be 600MB anyway I guess. Most of its mozillas code I guess
[10:08] <fullermd> artagnon: I believe that would be bzr pull --overwrite -r<abc>
[10:09] <reyman> pff i delete all my branch, checkout and restart cmd, and it's ok ... duplicate checkout in another local branch is ok.. sorry for inconvenience.
[10:09] <bialix> most likely bzr pull . --overwrite -r<abc>
[10:10] <fullermd> Well, yeah.  My brain typed the period; not its fault if my fingers didn't comply   :p
[10:10] <bialix> reyman: there were gremlins
[10:11] <artagnon> fullermd && bialix: Got it, thanks :)
[10:11] <bialix> artagnon: always happy to help
[10:11] <artagnon> Huh? I just got a huge bunch of conflicts!
[10:13] <fullermd> Did you have local changes?
[10:13] <artagnon> Yeah :|
[10:13] <fullermd> Mmm.  pull may try to merge them.  I can never remember if --overwrite affects that or not.
[10:13] <fullermd> Well, git reset --hard blows them away too AFAIK, so you can just revert to get back to a pristine rev <abc> WT.
[10:14]  * artagnon nods
[10:14] <artagnon> so bzr pull . --overwrite -r<r> isn't the equivalent
[10:14] <fullermd> Not quite.  pull ; revert (or revert ; pull) would be I guess.
[10:15] <fullermd> git reset blurs the lines.  In bzr, pull affects the branch, and revert the WT.
[10:16] <artagnon> ok, got it
[10:17] <artagnon> what do I do now though? I just want to hard reset to HEAD and try all this
[10:18] <fullermd> revert with no args will blat a pristine state of the current rev onto your working tree.  After the pull, that 'current rev' will be what you set for there, so just 'revert' should do it.
[10:20] <artagnon> Ok, nice. Now bzr status indicates a lot of unknown files though- how do I get rid of them?
[10:21] <fullermd> Mmm.  Probably a construction of bzr ls --someargs | xargs rm
[10:21] <jszakmeister> artagnon: I haven't tried it before, but 'bzr clean-tree' is probably what you're looking for.
[10:22] <fullermd> Probably  --unknown -R ?
[10:22] <lifeless> rm `bzr unknowns`
[10:22] <fullermd> Oh look, another ls bogusness I find in checking that...   how surprising.
[10:22] <bialix> `bzr clean-tree` FTW
[10:23] <reyman> in help there are a chapter "advanced layout", and the speak about the launchpad model, but when you use launchpad to host the code, you doesn't have choice with your layout for repository, no ?
[10:25] <jszakmeister> Is it sound to pass a URL to bzrlib.config.LocationConfig()?
[10:26] <artagnon> jszakmeister: works perfectly, Thanks :)
[10:26] <jszakmeister> artagnon: you're welcome!
[11:17] <defn> Hi all -- I have a branch, of a branch, of a "master" repository -- This branch is on a server.  How can I create a branch of my remote branch so I can work locally, and then push my commits into my the remote branch
[11:18] <defn> so right now I have branch-foo -> branch-bar -> master, and i want to have branch-local --|--> branch-foo -> branch-bar -> master
[11:18] <defn> does that make sense?
[11:20] <GaryvdM> defn bzr branch server/master
[11:20] <GaryvdM> defn: you will then have a master branch on your computer
[11:21] <GaryvdM> defn: I think that it is easier than you are expecting it to be :-)
[11:52] <defn> GaryvdM: :) thanks
[11:57] <spirov92> hi people, I'm having problems commiting to a launchpad branch, is launchpad down or something?
[11:58] <spirov92> ah, yes, it seems so
[12:18] <defn> GaryvdM: so would it look like:  bzr branch user@remotehost:dir/of/my/branch
[12:19] <GaryvdM> defn: maybe bzr branch sftp://user@remotehost/dir/of/my/branch
[12:20] <GaryvdM> defn: how is the branch shared?
[12:20] <defn> GaryvdM: im not sure im new to bzr
[12:20] <defn> i have a branch in another user's branch, which is pulled into the master
[12:22] <GaryvdM> defn: The branch can be shared over ftp, ssh(sftp), http, or anything that you can mount.
[12:22] <defn> i have a dir with a .bzr/ dir in it, and then i created a branch named v1.0 in the same directory which has its own .bzr directory inside
[12:23] <defn> that branch was created from the other user's branch
[12:23] <defn> does any of what im saying make sense?
[12:23] <defn> :)
[12:24] <GaryvdM> defn: no, rather don't move the .bzr dirs arround yourself.
[12:24] <defn> i havent touched the .bzr dirs
[12:24] <defn> im getting "Not a branch"
[12:25] <GaryvdM> defn: What are we trying to do again. I thought you were trying to get a branch from a server
[12:25] <defn> bzr branch bzr+ssh://user@server/dev/repo/v1.0
[12:25] <defn> GaryvdM: im trying to do local development of that remote branch, like so i can commit locally when im not on the LAN
[12:25] <defn> and then when i get to work i can commit those changes
[12:26] <GaryvdM> And what happens when you do bzr branch bzr+ssh://user@server/dev/repo/v1.0 ?
[12:26] <defn> server does not understand bazaar network protocol 3, ... error: not a branch
[12:27] <GaryvdM> Who created the branch? maybe they did not?
[12:27] <lifeless> is bzr installed on the server?
[12:27] <defn> lifeless: yes but it's an older version i think
[12:27] <defn> 1.3.1
[12:28]  * GaryvdM -> lunch
[12:31] <defn> okay so here is the layout...
[12:32] <defn> another user on the same remote server created a branch for me in his home directory. on that server i created a branch in my home directory by doing: bzr branch /home/otheruser/dev/repo/branch branch-name
[12:35] <defn> okay i think i got it
[12:36] <defn> i guess my next question is, now that i've got a local copy of my branch, how do i commit locally only, so i dont need to have access to the remote server at all times?
[12:37] <luks> if you downloaded the brach using 'bzr branch', just use 'bzr commit'
[12:38] <defn> and then how, when im on the lan, do i push those commits to the remote branch?
[12:38] <defn> push?
[12:39] <luks> bzr push
[12:39] <luks> yes
[12:39] <defn> okay cool
[12:39] <defn> thanks everyone
[13:20] <reyman_aw> i don't understand why i have "sproject.dev/trunk" and not "/trunk" when i make bzr checkout "bzr checkout http://bazaar.launchpad.net/~reyman64/sproject/sproject.dev"
[13:22] <bialix> actually you should have only sproject.dev
[13:22] <bialix> the last part of URL used by default as the directory name
[13:23] <reyman_aw> yes i have only a branch sproject.dev in serie trunk
[13:24] <nomatter001> hi
[13:24] <reyman_aw> i want to make a human gate keeper flow, with a trunk only available for merge by me
[13:24] <nomatter001> i have problems with qlog because of that error: https://bugs.launchpad.net/ubuntu/lucid/+source/qbzr/+bug/544928
[13:25] <nomatter001> ubottu: exactly that problem, any whay to solve that?
[13:25] <reyman_aw> ^^
[13:25] <nomatter001> lol
[13:25] <bialix> reyman_aw: you may want to push your branch as lp:~reyman64/sproject/trunk
[13:25] <nomatter001> is there any way known to solve that problem
[13:25] <bialix> nomatter001: downgrade the PyQt
[13:25] <nomatter001> bialix: no other way?
[13:26] <nomatter001> manual patch in pyqt/qbzr?
[13:26] <bialix> GaryvdM working on this, he's away for lunch now
[13:26] <reyman_aw> bialix: yes, with no confirmation for me, and restriction review for other push'er
[13:27] <bialix> reyman_aw: lp:~reyman64/xxx is only writable by you
[13:27] <bialix> reyman_aw: check this page and read https://code.launchpad.net/~reyman64/sproject/sproject.dev
[13:27] <reyman_aw> ok thx bialix
[13:27] <nomatter001> bialix: does it work with pyqt-4.7.0-2?
[13:27] <bialix> reyman_aw: when I'm looking at your branch I see the following message: "You cannot upload to this branch. Only sebastien.rey  can upload to this branch. "
[13:28] <bialix> GaryvdM: are you here?
[13:28] <GaryvdM> nomatter001: Yes
[13:28] <bialix> Gary the Wizard came to the room
[13:28] <nomatter001> GaryvdM: ok thx
[13:29] <reyman_aw> and, so i have sprojet.dev in my repository after checkout, but why there are trunk folder into, don't understand ..if i want to create a fix , i need to branch the sprojet.dev/trunk or sprojet.dev only ?
[13:29] <bialix> reyman_aw: just advice: use english for the project description
[13:29] <bialix> or at least english + french
[13:29] <reyman_aw> ok bialix thx for advice, i translate later ;)
[13:30] <bialix> reyman_aw: are you using Bazaar Explorer?
[13:31] <reyman_aw> no
[13:31] <reyman_aw> command line for understand :)
[13:32] <reyman_aw> (try to understand ...)
[13:32] <bialix> wait a sec, I'll try to reproduce
[13:33] <bialix> bzr 2.1?
[13:40] <reyman_aw> yes bialix
[13:40] <reyman_aw> latest bzr on windows
[13:46] <bialix> okay
[13:46] <bialix> the same here
[13:46] <bialix> reyman_aw: you have trunk directory in your branch
[13:47] <reyman_aw> hum :/
[13:47] <bialix> the sproject.dev is the checkout root
[13:47] <bialix> do following:
[13:47] <bialix> cd trunk; bzr mv * ../
[13:47] <bialix> cd ..
[13:47] <bialix> bzr rm trunk
[13:47] <bialix> bzr commit
[13:48] <reyman_aw> ok so i make noob mistake in my manipulation when i create a trunk folder , arg
[13:48] <reyman_aw> thx a lot bialix, it's clear now :]
[13:48] <reyman_aw> sorry for this noob inconvenience
[13:49] <bialix> no problem
[13:49] <bialix> reyman_aw: remember: bzr info is your friend when you lost in the bzr forest
[13:49] <reyman_aw> ok thx for advice :)
[13:49] <bialix> `bzr info` tells you what bzr object you have and where its root
[13:50] <reyman_aw> i see yes
[13:51] <bialix> reyman_aw: you can try Bazaar Explorer
[13:51] <bialix> it provides some hints
[13:52] <reyman_aw> ok
[13:52] <bialix> back to your question about workflow
[13:52] <bialix> you'd better create shared repo for local work
[13:53] <bialix> bzr init-repo sproject
[13:53] <bialix> cd sproject
[13:53] <reyman_aw> i create a shared repo yes
[13:53] <bialix> bzr checkout lp:sproject trunk
[13:53] <bialix> the last command will create local checkout of your lp branch
[13:54] <bialix> then if you need to create new feature branch you do: bzr branch trunk xxx
[13:54] <reyman_aw> ok
[13:55] <bialix> to merge your branch back to trunk do: cd trunk; bzr merge ../xxx
[13:55] <reyman_aw> ok
[13:55] <bialix> after merge you need to check the result, resolve conflict if needed, and commit
[13:55] <reyman_aw> and if i want to propose merge on initial checkout trunk
[13:56] <reyman_aw> i make this with launchpad interface?
[13:56] <bialix> what it means?
[13:56] <bialix> if you want to create merge proposal?
[13:56] <bialix> or somebody else?
[13:57] <reyman_aw> only ~reyman64 have the access of initial trunk, but if other want to create feature and want to merge,
[13:57] <reyman_aw> yes bialix exactly
[13:57] <bialix> usually to create merge proposal one have to push his branch to lp
[13:57] <bialix> then do: bzr lp-open
[13:58] <bialix> the latter command will open the branch page, like https://code.launchpad.net/~reyman64/sproject/sproject.dev
[13:58] <bialix> there will be a button to create merge proposal
[13:59] <bialix> and ~reyman64 will receive the mail about merge proposal
[13:59] <reyman_aw> ok :]
[13:59] <reyman_aw> perfect !
[13:59] <bialix> then to merge the branch from lp you need to cd to shared repo sproject
[13:59] <bialix> then: bzr branch lp:other-branch
[14:00] <bialix> cd trunk
[14:00] <bialix> bzr merge ../other-branch
[14:00] <bialix> and commit as usual
[14:00] <reyman_aw> bialix: thx a lot for this tutorial, there are no real tutorial for decentralized workflow :/
[14:00] <reyman_aw> on launchpad
[14:00] <bialix> reaaly?
[14:00] <bialix> there is tutorials on Bazaar site
[14:01] <bialix> reyman_aw: http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/index.html
[14:01] <reyman_aw> yes but, not really for launchpad, so i don't understand the layout branch for launchpad
[14:01] <bialix> http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/using_bazaar_with_launchpad.html
[14:01] <bialix> ask your questions, give us feedback
[14:02] <bialix> send proposals to ML how the docs should be improved
[14:02] <bialix> there was nice tutorial on arstechnica
[14:03] <bialix> anybody has the link to that article?
[14:03] <reyman_aw> ok ! i search on arstechnica
[14:03] <reyman_aw> i have this review http://arstechnica.com/business/news/2010/02/an-introduction-to-collaborative-development-with-launchpad.ars
[14:04] <bialix> yes, that's it
[14:08] <bialix> reyman_aw: what do you mean by "the layout branch for launchpad"?
[14:14] <reyman_aw> bialix: in help there are a chapter " advanced layout"
[14:14] <bialix> link please
[14:15] <reyman_aw> ah the end :
[14:15] <reyman_aw> http://doc.bazaar.canonical.com/latest/en/user-guide/shared_repository_layouts.html
[14:15] <reyman_aw> -h+t
[14:15] <reyman_aw> layout " Simple developer naming (project/joe/foo, project/barry/bar) "
[14:15] <reyman_aw> this is not very clear for newbies
[14:15] <reyman_aw> like me :)
[14:16] <AndrewLuecke> Btw, has anyone tested both HTTPS and ssh, which was faster?
[14:16] <AndrewLuecke> Actually, nevermind, I'll just use SSH
[14:16] <bialix> bzr+ssh
[14:17] <bialix> reyman_aw: yep, there is the picture of tree of folders
[14:17] <bialix> reyman_aw: I think you don't need advanced things while you're newbie
[14:18] <bialix> reyman_aw: in short about lp: it uses the simple naming scheme: lp:~USER/PROJECT/BRANCH
[14:18] <reyman_aw> now i understand that the folder tree is a snapshoot of the launchpad ,no ?
[14:18] <bialix> I'd say that doc should be improved
[14:19]  * vila is stunned by bialix explanations, who needs doc after that ?
[14:20] <reyman_aw> bazaar have a great doc, and bialix help a lot ! Perhaps a tutorial on "how participate" on real launchpad project for dub :p
[14:20] <reyman_aw> make things more clear
[14:21] <vila> reyman_aw: patches welcome ! :)
[14:21] <reyman_aw> eheh
[14:21] <AndrewLuecke> I'm correct in believing bzr_access only allows r/rw/nothing right? Not anything special thats per directory (unless I create many users).. That is correct right?
[14:22] <vila> reyman_aw: I'm only half-joking here, at this instant, *you* have the clearer idea about what is missing...
[14:23] <AndrewLuecke> nevermind.. doesn't matter anyway :P
[14:23] <vila> AndrewLuecke: roughly yes, there was some discussion about going further but I can't remember it if was 1) with bzr-access, 2) with another script, 3) only discussed
[14:23] <reyman_aw> yes, i'm pionner in my entreprise, so i probably make a tutorial for the other later :]
[14:23] <vila> reyman_aw: keep notes !
[14:23] <reyman_aw> and why not for communities
[14:23] <AndrewLuecke> I think I heard somewhere vila, there is was ACL's, is that what you are refering to?
[14:24] <vila> AndrewLuecke: not ACL as the OS ones, but yes, something about allowing more fine-grained control at branch level
[14:24] <AndrewLuecke> ok
[14:25] <vila> AndrewLuecke: but nothing *below* the branch level in case that's what you're after
[14:25] <bialix> vila: the bug for 1st april: https://bugs.launchpad.net/bzr/+bug/553955 (unfortunately today is 2nd)
[14:26] <AndrewLuecke> nah.. It was more of a theoretical.. But I guess it doesn't matter, as I'll only probably have 1 primary repository anyway I guess
[14:26] <reyman_aw> i have a problem bialix, i delete the false trunk in my sproject.dev, make commit, but i have BZR ERROR: cannot lock dir : transport operation no possible : http does not support mkdir() ( ?? )
[14:27] <vila> AndrewLuecke: I'm 80% sure someone has a working solution, I just can't remember the details (Alzheimer, etc)
[14:27] <bialix> reyman_aw: because you did checkout from http branch, which is read-only
[14:27] <reyman_aw> hmm
[14:27] <AndrewLuecke> ok vila.. It will probably pop up anyway
[14:28] <bialix> reyman_aw: do the following: bzr switch lp:xxx (where xxx is your lp branch)
[14:28] <reyman_aw> ok
[14:28]  * AndrewLuecke is still wrestling with debian anyway
[14:28] <vila> bialix: naah, you can't delete foo.txt, that's not allowed
[14:29] <bialix> AndrewLuecke, vila: there is ClueBzrServer project which I'm still planning to try out
[14:29] <reyman_aw> thx bialix it's ok :)
[14:29] <bialix> vila: seriously? %-)
[14:29] <AndrewLuecke> cool
[14:30] <vila> bialix: no :) 'bzr remove foo.txt' is so engrained in mind that I cannot encounter such a bug, checking
[14:30] <bialix> phew
[14:30]  * bialix used Windows Explorer, but don't say anybody
[14:33]  * AndrewLuecke debates switching his server to ubuntu again
[14:33] <vila> bialix: feel free to mark such bugs as confirmed and set an importance (I just did)
[14:34]  * vila needs to reboot bbiab
[14:48] <bialix> vila, come back
[14:50] <GaryvdM> Bug 544928 Fixed.
[14:51] <GaryvdM> bialix: Because it affects so many people, I'm going to release 0.18.5 now. That ok?
[14:52] <bialix> GaryvdM: sure, please also put in the release my fix for backslashes
[14:52] <GaryvdM> Yes
[14:52] <bialix> GaryvdM: congratulations on the bug fix!
[14:53] <bialix> I've planned to do 0.18.5 anyway tomorrow
[14:53] <bialix> GaryvdM: you can leave it for me
[14:53]  * GaryvdM grumbles about qt....
[14:53]  * bialix grumbles about all new versions of all software
[14:54] <GaryvdM> I'm developing a love hate relationship with qt.
[14:54] <bialix> (excluding qbzr of course)
[14:54] <bialix> or PyQT?
[14:59] <vila> jam ?
[15:26] <GaryvdM> vila: I'm loving BZR_PLUGINS_AT
[15:27] <vila> GaryvdM: I'm glad you like it, but I wonder how you avoided bug #552922 though....
[15:28] <vila> GaryvdM: fix available at https://code.edge.launchpad.net/~vila/bzr/552922-plugins-at/+merge/22697
[15:28] <bialix> wow, nice feature
[15:28] <GaryvdM> vila: I don't know
[15:44] <AndrewLuecke> woot.. I am such a fool.. Nobody cares, but its hard to explain the satisfaction you get when ssh actually authenticates properly
[15:44] <vila> AndrewLuecke: You're not alone :-)
[15:45] <vila> AndrewLuecke: about the satisfaction that is...
[15:45] <vila> AndrewLuecke: nah kidding, I'm so a fool too :-P
[15:45] <AndrewLuecke> serves me right for using 2 different texts to set up ssh (one told me that my home dir should be my repo, and I forgot I did that so clearly, authenticated keys wouldn't work)
[15:46] <AndrewLuecke> ooh.. Import time.. Time to see how fast I can import from songbird's svn to prgmr
[15:46] <vila> AndrewLuecke: 'ssh -v' is your friend too
[15:47] <AndrewLuecke> it was a server side issue.. I thought I did the authorised keys thing wrong.. So dumb as I was.. I figured if I redid the same thing 5 times it would work..
[15:48] <vila> AndrewLuecke: good policy, served me right for the last 20 years, I use 2 instead of 5 though :-D
[15:48]  * vila kills more chicken
[15:49] <AndrewLuecke> Speaking of chicken.. If I'm not here tomorrow, its because the chicken in the fridge I purchased 2 or 3 days ago wasn't safe anymore
[15:50] <vila> tsk tsk, always sacrifice *live* chicken so you're sure they are fresh when you eat them...
[15:50]  * AndrewLuecke needs to find out how big the SVN tree is his importing, he suspects it wont fit on his VPS
[15:51] <AndrewLuecke> Nah.. no need
[15:51] <AndrewLuecke> Danger is my middle name...
[15:52] <AndrewLuecke> btw.. there is a broken link on: http://doc.bazaar.canonical.com/bzr.2.1/en/admin-guide/migration.html#subversion-conversion
[15:52] <AndrewLuecke> it points to http://doc.bazaar-vcs.org/en/migration/foreign/bzr-on-svn-projects.html
[15:52] <AndrewLuecke> which isn't found..
[15:52] <vila> AndrewLuecke: please file a bug on lp
[15:52] <AndrewLuecke> I assume we don't have access to edit that
[15:53] <AndrewLuecke> How do I file a bug?
[15:53]  * AndrewLuecke is joking...
[15:53] <vila> AndrewLuecke: the admin-guide is part of the sources, so you can even provide a fix if you know the right url :)
[15:54] <vila> doc/en/admin-guide/migration.txt
[15:54] <AndrewLuecke> not sure yet.. Anyway.. priority #1 is to start tearing the SVN to pieces (because that might take a day or so)
[15:55] <vila> sure, I'm just trying to help you find something to do while waiting for the import :-D
[15:55] <AndrewLuecke> Haven't started the import yet.. I'm concerned about waking up tomorrow and finding my VPS full.. Trying to find out how big it is first..
[16:06] <NfNitLoop> Hrmm, I remember there being some caveats in the difference between lightweight/heavyweight checkouts that don't seem to be mentioned on http://wiki.bazaar-vcs.org/CheckoutTutorial
[16:07]  * AndrewLuecke wonders when google wave got proper extensions
[16:07] <NfNitLoop> and I vaguely remember things like "rebase" sortof ... break in a heavyweight checkout.
[16:07] <NfNitLoop> AndrewLuecke: "proper" extensions?   It's had extensions from the start.
[16:07] <AndrewLuecke> yeah.. but now, it actually has some in the list.. not only 2 or 3 (lots of em)
[16:12] <bialix> vila: can you help? It seems I found rather serious bug in bzrlib
[16:12] <vila> April 2th, really 2th !
[16:13] <vila> bialix: don't ask to ask :-)
[16:13] <bialix> oh, it seems I understand
[16:14] <bialix> bug about relative path to the master of light checkout
[16:14] <bialix> rats
[16:16] <bialix> it kills mew
[16:16] <bialix> me
[16:16] <vila> I think someone reported a bug about that recently or at least mentioned it on the ML or here
[16:18] <bialix> I can work with light checkout at all if it uses absolute path to another windows drive!!!
[16:24] <GaryvdM> bialix: Have you noticed a difference in qbzr startup time?
[16:24] <GaryvdM> bialix: Have you noticed a difference in qbzr startup time?
[16:25] <bialix> no, I havent
[16:25] <bialix> o I havent
[16:25] <vila> GaryvdM: it's twice as slow ?
[16:25] <vila> GaryvdM: it's twice as slow ?
[16:25] <bialix> no, I havent
[16:26] <GaryvdM> :-( Sorry about the dup, I push up+enter, the wrong window had focus :-)
[16:26] <bialix> we're joking
[16:26] <bialix> relax
[16:26] <GaryvdM> :-)
[16:26] <bialix> :-)
[16:26] <vila> :-)
[16:26] <GaryvdM> no difference though?
[16:27]  * bialix just hits the wall with relative paths
[16:27] <bialix> GaryvdM: in which branch/revno?
[16:27] <vila> bialix: I thought poolie may have landed a related patch recently but I can't find it....
[16:28] <bialix> vila: I'm not sure
[16:28] <vila> bialix: anyway if things have changed and broke your workflow, raise a bug
[16:28] <GaryvdM> bialix: in trunk since rev 1229 (2010/03/25)
[16:28] <bialix> vila: things are not changed I belivev, I've just found another use case when absolute paths are show stopper for me
[16:29] <bialix> GaryvdM: oh, I'm often working/dogfooding with 0.18
[16:29] <vila> bialix: haaa, then I may be I've got everything backwards and the discussion was about using relpaths instead
[16:30] <bialix> GaryvdM: but no, I don't think I've noticed any highly visible improvements
[16:30] <bialix> GaryvdM: do you have benchmarks?
[16:30] <bialix> vila: relative paths will helps
[16:32] <bialix> GaryvdM: when you'll finish with 0.18.5 can you look at my question in qbzr ML about qlog+colo?
[16:32] <bialix> please
[16:33] <GaryvdM> Sure, I have a half finished draft
[16:33] <GaryvdM> Such a change will need quite a bit of plumbing work in qlog...
[16:33] <ctrlsoft> bialix: did you see my reply?
[16:34] <bialix> jelmer, is it you?
[16:34] <bialix> ctrlsoft: no, I don't
[16:35] <bialix> reply for what?
[16:35] <ctrlsoft> bialix: your email about colo support in qlog
[16:35] <ctrlsoft> s/qlog/qbzr
[16:36] <bialix> ctrlsoft: no, is it recent?
[16:36] <ctrlsoft> bialix: a couple of days ago I think
[16:36] <bialix> I've sent my question just yesterday
[16:37] <bialix> I don't see any your mails, ctrlsoft
[16:37] <GaryvdM> ctrlsoft: can't see it either. Maybe got filtered by google groups spam filter.
[16:37] <ctrlsoft> hmm :-(
[16:38] <ctrlsoft> bialix: to summarize it; bzr 2.2 has support for colocated branches in its API
[16:39] <bialix> I have to admit that google groups became worse in last weeks
[16:39] <ctrlsoft> bialix: it would be nice if qbzr and bzr-colo supported that, that would also give you support for colocated branches in git repositories
[16:39] <bialix> ctrlsoft: that sounds great
[16:40] <bialix> can you CC your mail to bzr ML, please?
[16:41] <bialix> ctrlsoft: you have joined to qbzr ML with your samba mail
[16:41] <bialix> your mail have to arrive, I believe
[16:42] <GaryvdM> bialix: For inno setup, should I us the unicode, or non unicode version? Does it make a difference to the output?
[16:42] <GaryvdM> *use
[16:43] <bialix> GaryvdM: currently I'm using 5.3.3 which is pre-unicode IIRC
[16:43]  * bialix is just lazy to upgrade
[16:44] <bialix> in short: I dunno
[16:44] <GaryvdM> OK
[16:44] <bialix> vila: is it new thing that push to another drive letter don't create working tree?
[16:45] <vila> meh, I don't think so, are you sure you're not pushing into a --no-trees repo ?
[16:46]  * bialix checks
[16:46] <bialix> vila: info -v says: Create working tree for new branches inside the repository.
[16:47] <vila> bialix: no idea then, but I don't recall any change in this area either
[16:47] <bialix> okay, time for bug report
[16:49] <bialix> hmmm, can't reproduce
[16:50] <bialix> with simple branch I can't reproduce
[16:50] <vila> bialix: kill more chicken
[16:50] <bialix> what's that?
[16:51] <vila> bialix: black magic against the gremlins
[16:51] <bialix> oh, cool
[16:51]  * bialix notes
[16:52] <bialix> level-up!
[16:52] <vila> :-)
[16:53] <bialix> OIC, I'm pushing from colo workspace, which uses treeless branches and light co
[16:53]  * GaryvdM checks if he is in the right channel....
[16:54] <GaryvdM> bialix: oh - thats how bzr qlog sees the colo branches...
[16:55] <bialix> GaryvdM: bzr qlog colo: ?
[16:56] <GaryvdM> yeah
[16:56] <bialix> vila: yes, I can reproduce
[16:57] <GaryvdM> bialix: fyi: I get an error with the unicode version of inno. It went away when I installed the non unicode version...
[16:58] <bialix> GaryvdM: ok, thanks for the info
[16:58] <bialix> perhaps wine issue?
[16:58] <GaryvdM> maybe wine related...
[16:58] <GaryvdM> yes
[16:58] <GaryvdM> http://pastebin.org/131345
[17:00] <GaryvdM> btw - it rocks that I can now build the windows installer on ubuntu.
[17:00] <bialix> strange
[17:00] <bialix> indeed, rocks
[17:00] <bialix> wine is cool
[17:01] <vila> GaryvdM: you should 1) backup your HD, 2) wipe it clean 3) insall Ubuntu, 4) install a windows VM :)
[17:02] <vila> bialix: you too :-P
[17:02] <bialix> vila: :-P
[17:03] <bialix> and who will report about windows bugs then?
[17:03] <vila> bialix: you can still use windows in the VM :-)
[17:03] <GaryvdM> vila: The problem is that I have allsorts of windows apps that I'm not sure If I have instalers for.
[17:04] <vila> bialix: Some addictions just can't be cured
[17:04]  * bialix prouds to be addicted
[17:04] <vila> :)
[17:04] <GaryvdM> vila: It would be cool if I could boot my existing windows installation in a vm...
[17:05] <vila> GaryvdM: That will be a good occasion to cleanup :)
[17:05] <bialix> I'm using windows also because there is a lot of PC games for my daughter
[17:05] <bialix> (and sometimes for me)
[17:05] <vila> GaryvdM: I've never done it, but I think it can be done
[17:06] <GaryvdM> vila: I pritty much weened of it now. The last real thing that I need is to be able to run classic asp on linux.
[17:06] <reyman_aw> bye all, and thx for the advice !
[17:06] <GaryvdM> For maintenance.
[17:07]  * bialix waves
[17:07] <reyman_aw> exit
[17:08] <vila> GaryvdM: just checked, VirtualBox can use raw host hard disk from a guest, either an entire physical hard disks or selected partitions
[17:09] <GaryvdM> Oh cool - I'll try that...
[17:10] <vila> GaryvdM: but if I had to try that, I'd make sure to have backups, just in case something weird happen like windows suddenly thinking that it's running on a new hardware because the video card is not the same anymore or something like that
[17:10] <vila> GaryvdM: this is from chater 9.5 Advanced storage configuration in the vbox doc by the way
[17:16] <GaryvdM> qbzr 0.18.5 code name Silver terminalia
[17:16] <bialix> nice!
[17:26] <vila> bialix, GaryvdM : Can you run python -c 'import paramiko; print paramiko.__version__' and tell me which version is shipped with bzr ?
[17:27] <bialix> vila: no
[17:27] <vila> hehe
[17:27] <bialix> it's not easy with py2exe
[17:27] <bialix> wait a minute
[17:30] <bialix> vila: it seems 1.7.6 (Fanny)
[17:30] <vila> bialix: cool, thanks
[17:31]  * bialix was lazy to install depends plugin
[17:33] <GaryvdM> vila: 1.7.6 (Fanny) (on lucid)
[17:34]  * bialix eods
[17:34] <bialix> bye all
[17:34] <GaryvdM> bialix:
[17:34] <vila> GaryvdM: yeah, I know, babune reports a test failing on lucid and so far I've got 1.7.4 passing on karmic and 1.7.6 failing on lucid, but maybe it's pycrypto instead
[17:34] <vila> bignose: enjoy your week-end !!
[17:34] <vila> too late :-/
[17:34] <vila> and wrong nick :-(
[17:35] <vila> sorry bignose that was for bialix
[17:36] <vila> jam: ping, I seem to remember you mentioned something about paramiko/pycrypto on windows but I can't remember the details
[17:37] <jam> hi
[17:37] <vila> jam: something about either patching one package or the other or going with a workaround
[17:37] <vila> yeah ! jam is here ! Good morning !
[17:37] <jam> so paramiko uses a RandomPool from pycrypto IIRC
[17:37] <jam> and
[17:37] <vila> yeah, along these lines
[17:37] <jam> 1) With older pycrypto and MS < Windows
[17:37] <jam> it loops around time.clock() 100 times, with 15ms granularity (taking 1.5s to start)
[17:38] <jam> 2) With MS Vista at least (sorry time.time()) granularity goes to 1ms
[17:38] <jam> so it is only 100ms to start
[17:38] <jam> 3) We can patch pycrypto to use time.clock()
[17:38] <jam> 4) Newer pycrypto doesn't have the bug, but has completely deprecated RandomPool
[17:38] <vila> right, but during the discussion I think it was mentioned another point about some, yeah that
[17:38] <jam> so raises a warning that paramiko is using it
[17:39] <jam> 5) So we have to patch paramiko to work around *that*
[17:39] <jam> So at the moment, we stick with older pycrypto and patch it
[17:39] <jam> We could upgrade to newer pycrypto and patch paramiko somehow
[17:40] <vila> right, so across all our platforms, freebsd, gentoo and now lucid are failing because paramiko use RandomPool
[17:41] <vila> (not 100% sure for lucid, but gentoo and freebsd now says: PID check failed. RNG must be re-initialized after fork(). Hint: Try Random.atfork()
[17:42] <vila> with a traceback from crypto to paramiko
[17:43] <vila> jam: ok, so patching paramiko seems to be the only viable alternative there, I'm EODing, but I'll file a bug first thing when I came back
[17:44] <vila> bye all, have a nice week-end !
[17:46] <vila> jam: just one last thing, when/where do we *require* paramiko ?
[17:47] <jam> we have to have it for sftp support
[17:47] <AndrewLuecke> night
[17:47] <AndrewLuecke> and thanks
[17:47] <jam> we *can* use it as an ssh agent instead of openssh
[17:47] <jam> so bzr+ssh shouldn't require paramiko if you have openssh
[17:48] <vila> jam: right, thanks for confirming
[20:50] <psynaptic> hey guys
[20:52] <psynaptic> is there a way to display just *my* commits
[20:52] <psynaptic> I'm expected to provide a log of my work each day and it would be ideal if I could run something like bzr log -u email@example.com
[20:54] <lifeless> bzr log -m email@example\\.com
[20:58] <psynaptic> lifeless: doesn't seem to work on this server. is there a special requirement?
[20:59]  * psynaptic pasted http://pastie.textmate.org/private/gepmld86ygjflga6qro3a
[20:59] <psynaptic> this is what I tried
[21:00] <lifeless> uhm, it might not search author/committer; file a wishlist bug
[21:00] <psynaptic> ok, thank you
[21:21] <lifeless> vila: ping
[21:31] <bac> lifeless: can you tell me how to get a diff of the changes since a given revision MINUS the changes merged in from trunk?
[21:32] <lifeless> uhm
[21:32] <lifeless> make a temp branch
[21:32] <lifeless> of that rev
[21:32] <bac> yep
[21:32] <lifeless> merge trunk to it
[21:32] <lifeless> make a temp branch of tip
[21:32] <lifeless> merge trunk to that
[21:32] <lifeless> diff --old first-temp --new second-temp
[21:33] <bac> i'd tried *most* of that.  let me try.  thanks
[21:33] <lifeless> (this feeds into why looms and pipelines have things merged together)
[21:34] <magcius> I'm having problems when pulling from a repo.
[21:35] <magcius> bzr: ERROR: KnitPackRepository('local-repo') is not compatible with CHKInventoryRepository('lp-repo')
[21:35] <magcius> different rich-root support
[21:41] <ctrlsoft> magcius: the remote repository has more information than the local one, so the revisions can't be losslessly stored locally
[21:41] <ctrlsoft> magcius: you might want to upgrade to a newer repository format
[21:41] <ctrlsoft> ("bzr upgrade")
[21:41] <magcius> ctrlsoft: um
[21:41] <magcius> ctrlsoft: you should have a better error message, or do that automatically
[21:41] <magcius> ctrlsoft: because it was an older version before, so when I try to pull it should try to upgrade
[21:41] <ctrlsoft> magcius: I agree a better error message would indeed be a good idea, I think there's an open bug about that.
[21:42] <ctrlsoft> magcius: we don't want to upgrade automatically because it will make the repository unreadable by older versions of bazaar
[21:58] <vila> lifeless: pong
[21:59] <lifeless> hai
[21:59] <lifeless> bzrlib's HTTP transport
[21:59] <lifeless> is it threadsafe?
[22:00] <lifeless> and if I were to do a 'get' on it, does it buffer the full response still ?
[22:00] <lifeless> vila: ^
[22:00] <vila> hmm, I can't think of any part that shouldn't.
[22:00] <lifeless> vila: persistent connection cache ?
[22:00] <vila> pycurl buffers, urllib doesn't
[22:01] <vila> the connection  is shared between the transports that use it, there is no global cache
[22:01] <vila> lifeless: the only weak point is when the server and the client are in the same process but I don't think you care about that
[22:02] <vila> and even there it's more a python bug than unsafe thread code
[22:04] <vila> lifeless: when you do a get, the urllib transport try to make all reads goes to the socket without buffering (at least for the data, headers are a different story but again you should not care about that)
[22:05] <magcius> can someone explain this though? "We identify revisions using sequential numbers per branch, not per repository."
[22:05] <magcius> I thought branch was synonymous with repository?
[22:06] <mkanat> magcius: bzr help init-repo
[22:07] <luks> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
[22:08] <magcius> can bzr revision numbers theoretically get to 1.6.12.46.76.1.6.78/123 and so on?
[22:08] <magcius> s:/:.:
[22:08] <luks> seriously, read http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs
[22:08] <luks> short answer, no, they can't
[22:09] <vila> magcius: no, they are either 123 or 123.456.789 i.e. one or three numbers
[22:09] <magcius> wait, what?
[22:09] <magcius> sorry, I'm a bzr noobie
[22:09] <vila> magcius: yeah, luks gave you a very good url for that
[22:09] <lifeless> vila: right, I don't care about that
[22:09] <lifeless> vila: is there control over cache-control yet ?
[22:10] <RumblePure> got an older revision, since that revision I have removed and created new files. How to restore the older revision?
[22:10] <vila> lifeless: no, we explicitly disable the caching unconditionaly
[22:11] <luks> RumblePure: bzr revert -r X path/to/file
[22:11] <luks> if I understand correctly that you want to undelete a file
[22:11] <lifeless> vila: yeah, I thought so
[22:12] <lifeless> vila: is it at least in a function I could override ?
[22:12] <vila> lifeless: see -urlib2_wrappers.AbstractHTTPHandler._default_headers
[22:12] <magcius> How are the pieces stored on the disk? Is it pickle or something?
[22:12] <luks> which pieces?
[22:12] <parthm> hello all. i was looking at bug #518609
[22:12] <lifeless> vila: bug 120697
[22:12] <magcius> luks: the files, the commit metadata
[22:13] <vila> lifeless: overriding AbstractHTTPHandler.http_request should be a good starting point
[22:13] <parthm> it seems that the exception occurs due to log.add('message', message) in format_rio.py but message is already unicode
[22:13] <parthm> http://pastebin.com/XP5VfTJt
[22:13] <lifeless> hth debbian things its fixed, I dunno
[22:13] <parthm> any ideas what the problem might be?
[22:14] <luks> magcius: there are various repository and branch formats in bzr
[22:14] <lifeless> parthm: it shouldn't be unicode
[22:14] <RumblePure> luks: simple enough. thx for your help. :)
[22:14] <vila> lifeless: yes I remember this bug
[22:14] <magcius> luks: is there any documentation on them, if I wanted to, say, implement a bzr web viewer in PHP or Perl?
[22:14] <luks> magcius: only the source code, I'm afraid
[22:14] <vila> lifeless: especially comment #9 :)
[22:15] <luks> but reading them directly is not going to be easy
[22:15] <parthm> lifeless: oh. so does bzr store message as regular 8-bit strings?
[22:15] <parthm> byte strings
[22:15] <magcius> luks: ouch
[22:16] <lifeless> magcius: bzr, like all VCS's, is a database.
[22:16] <luks> magcius: bzr is more a vcs framework than a simple application :)
[22:16] <lifeless> magcius: would you write a viewer for Postgresql or MySQL databases in PHP/Perl ?
[22:16] <magcius> lifeless: it's been done
[22:16] <luks> the interface (both user and API) was always more important than the file formats
[22:16] <lifeless> magcius: well, its that order of complexity.
[22:17] <lifeless> you need to implement the B+Tree index logic, groupcompress compression engine, pack file format, to have any hope
[22:17] <lifeless> and then on top of that you can start implementing user visible things.
[22:17] <lifeless> those three things are well documetned, in pydoc.
[22:18] <luks> and hope bzr will not change it's default format in the next version :)
[22:18] <magcius> lifeless: do you have a library written in something like C that I can get bindings to?
[22:18] <lifeless> luks: that doesn't really matter, a given website can stay on any format it wants indefinitely.
[22:18] <lifeless> magcius: you can call python from C; so our existing Python code is accessible from C.
[22:19] <magcius> lifeless: um
[22:19] <lifeless> and bzr is structured very cleanly as front-end and library.
[22:19] <luks> lifeless: I assume if somebody invests time in writing a reader for the 2a format, they want to actively use it
[22:19] <lifeless> there is also bzr-xmloutput, xml bindings for most commands.
[22:19] <luks> and bzr doesn't tend to support old formats indefinitely
[22:20] <parthm> magcius: loggerhead is a bzr web viewer written in python https://launchpad.net/loggerhead
[22:20] <lifeless> luks: we still support the very earliest alpha formats
[22:20] <magcius> parthm: yes, I've used loggerhead and seen it break thousands of time
[22:20] <luks> lifeless: usually only for conversion
[22:20] <lifeless> luks: its only the absolutely oldest ones (that couldn't even do networking or merge) that are readonly
[22:20] <luks> you wouldn't want to use them
[22:20] <lifeless> luks: !citation time, you're making FUD
[22:20] <vila> magcius: bug reports and patches welcome :)
[22:21] <luks> lifeless: :)
[22:21] <luks> a little too serious? :)
[22:21] <magcius> vila: I made a feature request a while ago: indentation lines or a left margin, it's awful reading Python code in Loggerhead because I can't tell where global scope is
[22:22] <vila> luks: he's right, the test suite guarantees that and fully pass for every commit on mainline...
[22:22] <magcius> vila: second, fix your URLs, I don't want to see %2F or whatever : is in my URLs. Third, I don't like how you have different URLs for reading files or trees. I should be able to change the URL to delete the filename and make it work.
[22:22] <luks> vila: yes, I know they are fully working
[22:22] <luks> vila: but they are inneficient
[22:22] <vila> magcius: I didn't write loggerhead
[22:22] <lifeless> luks: magcius have you filed a bug for that ?
[22:23] <lifeless> sorry
[22:23] <lifeless> magcius: have you filed a bug for that?
[22:23] <luks> vila: and they get more inneficient as new formats get developed
[22:23] <magcius> lifeless: I was told that both bugs already existed earlier
[22:23] <vila> luks: well I surely the newer formats are more efficient
[22:23] <lifeless> luks: they shouldn't be more inefficient than their intrinsic capabilities
[22:23] <parthm> lifeless: you are right `log.add('message', message.encode('ascii', 'ignore'))` fixes the issue. but is this the right place to convert the message to ascii? or do i need to find out why the message is becoming unicode in the first place?
[22:23] <lifeless> luks: we have removed unsafe optimisations that we used as a stopgap while preparing better formats
[22:23] <vila> magcius: I don't clearly see how reading the low-level bzr data will help you there ?
[22:23] <luks> vila: knits were getting alower along with packs development, the original packs were getting slower along with ...
[22:24] <lifeless> parthm: I have no idea what you're doing, so I can't really answer that.
[22:24] <lifeless> parthm: perhaps mail the list ?
[22:24] <luks> vila: anyway, I never wanted to argue about this :)
[22:24] <lifeless> parthm: unless vila has time to dig into this - I don't right now,s orry.
[22:25] <luks> I only said that this would be a reason for me to not implement bzr's internal file formats
[22:25] <vila> luks: I won't deny that but I won't say that the degradation were more important than the optimizations either
[22:25] <parthm> lifeless: i will do that. thanks for the pointer on message being ascii.
[22:25] <vila> luks: that's for sure :-)
[22:25] <parthm> lifeless: mailing list is probably good :)
[22:26] <lifeless> vila: so - http://launchpadlibrarian.net/10490569/120697.patch
[22:27] <vila> lifeless: yup, still valid (still not usable as is but in essence that's what controls the caching)
[22:27]  * vila giggles at the # Begin bundle, long time not seen :)
[22:28] <lifeless> vila: I've suggested an API
[22:29] <vila> lifeless: I'll happily review any patch you can come with :-P
[22:37] <vila> lifeless: but roughly, caching packs/* and indices/* should cover at least 90% of the possible gains no ?
[22:53] <lifeless> vila: yes
[22:53] <lifeless> I don't plan to do that
[22:53] <lifeless> I want caching in another project, dealing with large data sets