[00:07] <leo2007> does the windoes installer require python to work properly?
[00:11] <Verterok> leo2007: there is a standalone bzr.exe and a installer that needs a python installation
[00:13] <Verterok> leo2007: bzr-setup-1.5.exe is the standalone installer, and bzr-1.5.win32-[py2.5/py2.4].exe needs a python install
[00:15] <leo2007> Verterok: trying to push a local branch to a remote machine through sftp, it didn't succeed
[00:16] <Verterok> leo2007: any error msg?
[00:19] <leo2007> Verterok: it looks like it succeeded but no files were actually uploaded.
[00:20] <Verterok> leo2007: a push don't create/update a remote workingtree
[00:21] <Verterok> leo2007: in the remote location you should have a .bzr/ dire
[00:21] <Verterok> s/dire/dir/
[00:22] <leo2007> Verterok: yes. but my local repo has versioned files
[00:22] <leo2007> they weren't uploaded
[00:22] <Peng> leo2007: Push doesn't create a working tree. All of the history is in .bzr.
[00:23] <Peng> leo2007: If you just want to push and pull from that location, you don't need a working tree.
[00:23] <Peng> leo2007: If you really do need one, check out the bzr-upload plugin.
[00:25] <Verterok> leo2007: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#push
[00:26] <Verterok> leo2007: check the "Description" section, or bzr help push ;)
[00:26] <leo2007> Peng: Thank you. That resolved my confusion. I thought the files were being left out
[00:30] <leo2007> what tool do you use to manage bzr repo in windows? I have been using the dos window and it is quite inefficient.
[00:34] <Verterok> leo2007: I don't use windows, but take a look to qbzr, bzr-gtk and tbzr (tortoise-like)
[00:36] <Verterok> leo2007: http://bazaar-vcs.org/QBzr , http://bazaar-vcs.org/bzr-gtk
[00:37] <Verterok> leo2007: and http://bazaar-vcs.org/TortoiseBzr
[00:40] <leo2007> Verterok: thank you very much. I will take some time to read the doc properly.
[00:40] <Verterok> leo2007: y'r welcome :)
[00:42] <leo2007> Verterok: good night;)
[00:43] <Verterok> leo2007: seeya
[01:42] <rockstar> james_w, are you around?
[07:28] <alencool> hello
[07:29] <alencool> is there anyone in here that could help me?
[08:31] <skavez> is there an easy way to install bzr-svn on os x? or is recompiling svn still the only way?
[08:32] <RAOF> Newer bzr-svn has it's own subversion bindings; you'd need to build bzr-svn, but you shouldn't need to rebuild subversion.  I think.
[08:41] <lifeless> ola!
[08:41] <lifeless> so
[08:41] <lifeless> who wants to hear some good ne
[08:41] <lifeless> ws
[08:44] <RAOF> lifeless: Oooh!  Oooh!  Me!
[08:44] <lifeless> RAOF: on the plane I wrote a new compressor that is (unoptimised) 10% slower than knits, but generates data 10% of the size: smaller than git-repack --window 200 --depth 200
[08:45] <RAOF> My my.
[08:45] <RAOF> That _is_ impressive.
[08:45] <lifeless> am now ingensting caffeine and grease
[08:46] <lifeless> and will try to make it end user accessible/fix some glaring inefficiencies
[08:46] <RAOF> I hope you're rounding that meal out with the other 2 food groups (starch and burnt crispy bits).
[08:48] <lifeless> git  200, 200        638227   0.6MB
[08:49] <lifeless>  patience all:
[08:49] <lifeless> 16665951 25.320 197 164 0-mbp%40sourcefrog.net-20050323055643-668814a4d6478235
[08:49] <lifeless> after zlib 599036
[08:49] <lifeless> and - thats getting some stuff whackily wrong ecause sequencematcher is not designed for relocations
[08:49] <lifeless> so am rewriting the match logic entirely
[08:51] <lifeless> RAOF: oh, I don't do any of that whacky try-N diffs and pick one stuff either.
[08:52] <RAOF> You're not using the rsync compression algorithm, either :)
[08:52] <lifeless> no
[08:52] <lifeless> its broadly speaking just sliding window with references to the output
[08:53] <RAOF> Is this possibly going to improve initial-branch-from LP speed?
[08:53] <lifeless> but line orientated and entropy coded post processor
[08:53] <lifeless> well, downling 10% of te total data -> should be faster
[08:53] <lifeless> but there is a ways to go from here to production
[08:55] <RAOF> Right.  Initial-branch is basically the only bzr operation that takes an apreciable and annoying time for me, so that's the filter I view bzr improvements through.
[08:55] <RAOF> I should really learn a little more compression theory.  I'm only familiar with huffman encoding.
[08:55] <lifeless> so huffman is probabilistic encoding:
[08:56] <lifeless> build a tree weighted by the probability of a symbol, and to emit something you name a path in the tree; the deeper the tree the more things you can output with a short path
[08:57] <RAOF> Right.
[08:58] <lifeless> I'm reasonably sure I have http://www.amazon.com/Data-Compression-Book-Mark-Nelson/dp/1558514341 first edition around at home somewhere
[08:58] <lifeless> or a t least, I have *a* textbook on dc
[08:59] <lifeless> anyhow dictionary based compression you have a dictionary, and the compressor outputs keys in the dict
[08:59] <lifeless> most compressors are dynamic these days - turning the state with the symbols rom the input stream, and the decompressor mirrors that
[09:00] <RAOF> Ok.
[09:01] <lifeless> anyhow, what I do is:
[09:01] <lifeless> output the first text
[09:01] <lifeless> diff the next against that, output the diff
[09:01] <lifeless> dif the next against the total output so far
[09:01] <lifeless> and so on
[09:02] <lifeless> so the output is a combination of refernces to the output stream so far, and new symbols
[09:02] <lifeless> which is basically an infiinte window  dictionary cmopressor
[09:03] <lifeless> the only reason to do this in preference to e.g. lzma is that I know I don' need the intermediate texts
[09:04] <lifeless> so decompression is basically one read, split the bytes into 'text before the delta we want, and the delta w want'
[09:04] <lifeless> pasrese the delta
[09:04] <lifeless> apply
[09:04] <lifeless> also, typign from London; excuse the spellink
[09:06] <RAOF> :)
[09:07] <RAOF> Right.  So, nice and quick unpacking.  Cool.
[09:09] <lifeless> yah, typical dictionary decompressiors need to care about the entire input stream
[09:10] <lifeless> whereas my references are not to an internal symbol able, but to the actual output
[09:10] <lifeless> less efficient,. but for some work sets I'm seeing 200:1 compression *before* zlib is applied
[09:11] <RAOF> I suppose revision data is likely to be an ideal candidate for compression.
[09:11] <lifeless> one insight the git devs had that is very useful is that decreasing size makes most patches a series of deletes
[09:12] <lifeless> (or more deletes than adds)
[09:12] <lifeless> I *think* I can make that largely irrelevant, but until I finish replacing the 'does this work' sketch with something that handles moves it will bite
[09:15] <skavez> argh! does "bzr: ERROR: exceptions.ImportError: cannot import name make_file_factory"  sound like something i can fix? i'm getting it while trying to branch an svn repo with bzr-svn 0.4.11 and bzr 1.6b2
[09:23] <lifeless> skavez: you need bzr.dev for that version of bzr-svn I think
[09:25] <BjornT> do i need any special configuration for using 'bzr send'? when i try 'bzr send --mail-to=email@example.com', all that happens is that a terminal with mutt is opened (listing my inbox), and no mail is sent
[09:26] <skavez> lifeless: ah ok. i'll give that a shot
[09:27] <lifeless> BjornT: the hlep should describe it BjornT ; its trying to use mutt as your mailer; perhaps you have misconfigured xdg-utils or something?
[09:28] <BjornT> lifeless: well, i'd love to use mutt :), as long as it would allow me to send the e-mail.
[09:29] <lifeless> BjornT: poke at the help, and the mnual, failing that file a bug
[09:31] <BjornT> lifeless: at least it works if i specify mail_client=mutt
[09:33] <BjornT> xdg-email email@example.com doesn't work either, so i guess that's where the bug is
[09:40] <lifeless> BjornT: I would guess so
[09:40] <lifeless> RAOF: lp:~lifeless/+junk/bzr-groupcompress
[09:40] <lifeless> -<> gate A18 now :)
[13:55] <j^> is it a common problem that the trac plugin gets really slow for the /timeline view?
[13:56] <j^> when i started a new repos it was ok, but it seams it gets slower with each commit i make
[15:15] <jetto> hello
[15:16] <jetto> I come from cvs and Clearcase(base not ucm), and I'm looking to use a more advenced scm tool.
[15:18] <jetto> I'm very confused with bzr concept I want to do some test one a real work
[15:21] <jetto> I try to hack a game : rrgbis. I got sources from SF and do some fix. then upstream release a new version than include some of my fix. I would like merge then continue to hack.
[15:22] <jetto> How can I do this on bzr ? I mean having something like a vendor branch on CVS
[15:34] <Odd_Bloke> jetto: What SCM tool are they using on SF?
[15:45] <uws> cvs :)
[15:46] <Odd_Bloke> Hmm, I'm not sure of the best way to deal with CVS is.
[15:49] <bigdog> good morning
[15:49] <bigdog> is this the place to ask about a problem I am having pushing a branch up to launchpad?
[15:50] <bigdog> I am using windows
[15:50] <uws> bigdog: yes, or #launchpad
[15:50] <bigdog> I am using bzr 1.5
[15:51] <bigdog> uws: I will start here, If I describe my problem, and I should go to #launchpad, let me know
[15:51] <bigdog> When I was using bzr 1.2, on windows, with ssh key,  I was able to push branches with no problem (a couple of months ago)
[15:51] <uws> bigdog: i'm not the one who can help you I'm afraid
[15:52] <bigdog> uws: ok
[15:52] <uws> but usually the people in this channel are quite responsive and helpful
[15:52] <uws> so do proceed
[15:52] <bigdog> thanks
[15:53] <bigdog> So everything worked a couple of months ago.  windows + pagaeant  .
[15:53] <bigdog> yesterday I had some time to push a new branch.  I noticed there was a new version of bzr, so I grabbed and ran the installer
[15:54] <bigdog> H:\launchpad\txcomputegrid>bzr launchpad-login -v  bigdog
[15:54] <bigdog> bzr: ERROR: The user bigdog has not registered any SSH keys with Launchpad.
[15:54] <bigdog> I have the same ssh key, that is registered with paegent
[15:55] <bigdog> same response for set BZR_SSH=plink
[15:55] <bigdog> and set BZR_SSH=paramiko
[15:55] <bigdog> any insight?
[16:01] <bigdog> uws: Sunday morning is busy day for people,  I will try #launchpad
[16:02] <Odd_Bloke> bigdog: That'll probably be a result of the Debian SSL issues.
[16:02] <Odd_Bloke> bigdog: Check that you actually _do_ have a LP key registered.
[16:08] <bigdog> Odd_Bloke: thanks
[16:19] <Tim3393> Hello,
[16:19] <Tim3393> I have a question regarding the way bazaar does handle duplicate files when storing them in a repository.
[16:20] <Tim3393> In my project there are often a number of identical files in different locations of the working tree.
[16:20] <Tim3393> As I do not want the repository to be unnecessarily blown up I would like to know if bazaar is so smart that it will detect the identical copies and actually only store their content once?
[17:35] <clemente> Bazaar stops when doing some operations (ex: branch) and starts running again after I press ENTER four times...
[17:36] <clemente> In fact it's doing read(0,...) according to strace
[17:40] <clemente> Do you also get this behaviour? I can always reproduce it
[17:40] <clemente> Both with 1.5 and with latest version from today
[17:50] <clemente> It is probably related to dbus...
[18:14] <antoranz> hi guys! Do you know when 1.6 is commign out?
[18:28] <leo2007> how to set up emacs to use bzr in windows?
[18:34] <clemente> (I submitted bug 246052 for that problem of halting on STDIN)
[19:07]  * Foskasse ▄█▀ █▬█ █ ▀█▀
[19:09] <Kinnison> How delightful
[19:26]  * Foskasse █▬█ █
[19:28] <Kinnison> My god it's expensive to convert from weave to btree-plain
[20:19] <kgoetz> hi hackers! i seem to have exploded bzr :( http://paste.ubuntu.com/25500/ i installed python 2.5 recently. could this be the cause?
[20:23] <gour> Kinnison: when is btree supposed to go into trunk?
[20:28] <Odd_Bloke> kgoetz: That error looks familiar, but I can't remember what causes it. :(
[20:29] <kgoetz> Odd_Bloke: incase it helps: i merged from the repos default branch, then realised i had no local changes, then pulled, and you see the result there.
[20:34] <Kinnison> gour: no idea
[20:35] <Odd_Bloke> kgoetz: I'd recommend looking through LP for bugs and looking at the ML.
[20:36] <kgoetz> Odd_Bloke: i'll try and give LP a trawl.
[20:45] <kgoetz> this bug looks similar, but seems totally unrelated. https://bugs.launchpad.net/bzr-gtk/+bug/237205
[21:44] <mwhudson> any devs awake?
[21:50] <abentley> mwhudson: I'm not *really* awake...
[21:51] <mwhudson> abentley: so bzr get nosmart+<http url that redirects> bombs out pretty messily
[21:51] <mwhudson> abentley: any obvious ideas for places to look?
[21:52] <mwhudson> oh
[21:52]  * mwhudson finds a fixme
[21:52] <mwhudson>             # FIXME: If 'transport' has a qualifier, this should
[21:52] <mwhudson>             # be applied again to the new transport *iff* the
[21:52] <mwhudson>             # schemes used are the same. Uncomment this code
[21:52] <mwhudson>             # once the function (and tests) exist.
[21:52] <mwhudson>             # -- vila20070212
[21:54] <abentley> mwhudson: I haven't see the actual traceback...
[21:55] <mwhudson> sorry
[21:55] <mwhudson> abentley: http://pastebin.ubuntu.com/25504/
[21:55] <abentley> Yeah, so I think you've already found the relevant bit.
[21:56] <mwhudson> though the exception is from before the comment
[21:56] <mwhudson> but yeah, it seems the problem is somewhat known
[22:00] <mwhudson> i guess vila is the man to hassle about this
[22:00] <abentley> mwhudson: So what's being done there is a bit bogus.
[22:00] <abentley> Because there's no reason to assume that it's a relative path.
[22:00] <mwhudson> right
[22:00] <abentley> It could legitimately be on a different host, for example.
[22:01] <mwhudson> indeed, in http its really really not supposed to be
[22:01] <abentley> So it should probably be using urlutils.relative_url instead.
[22:01] <mwhudson> something a little funky is happening, because http redirects do actually work most of the time
[22:01] <abentley> That operation doesn't error when the urls are unrelated.
[22:03] <abentley> Okay, here's what I think happens.
[22:03] <abentley> relpath is being used in a check.
[22:04] <abentley> specifically, if I try to get foo/bar/baz, I should get redirected to */baz
[22:04] <mwhudson> right
[22:05] <abentley> And there's a discrepancy between what e thinks the url was and what the transport thinks it was.
[22:10] <mwhudson> hm hm
[22:14] <mwhudson> abentley: i think the problem is more basic:
[22:15] <mwhudson> abentley: http://pastebin.ubuntu.com/25513/
[22:15]  * mwhudson winds up a poking for spiv when he wakes up
[22:16] <abentley> mwhudson: How does that contradict me?
[22:16] <mwhudson> abentley: it doesn't
[22:17] <abentley> Oh.  Okay.
[22:17] <mwhudson> well, hm
[22:17]  * mwhudson thinks
[22:17] <abentley> I think that it is correct to not treat http://foo/bar as a child of bzr+http://foo
[22:19] <mwhudson> p = '...'; get_transport(p).relpath(p) shouldn't fail though, should it?
[22:19] <mwhudson> this is tripping up the puller where we force all http: urls to be nosmart+
[22:20] <mwhudson> maybe there's a better way to do that
[22:20] <abentley> mwhudson: Yes, it's legitimate for that to fail.
[22:20] <abentley> get_transport may canonicalize the url, and it may do a lookup.  e.g. lp:bzr
[22:21] <mwhudson> hm
[22:22] <abentley> transport.base will give the the final value the transport used.
[22:25] <mwhudson> so yeah, this stuff in redirected() does look a bit bogus then
[22:26] <jetto> hum bzr looks like too hard form me :-(
[22:27] <mwhudson> jetto: ?
[22:28] <jetto> I would like to do some thing very simple and it's not clear how to do it :
[22:31] <jetto> I get source as a tgz from upstream. I hack a little, then the upstream release a new version. I merge and continue to hack. How to do this ?
[22:32] <mwhudson> jetto: i think the 'bzr import' command can help with this
[22:33] <jetto> I mean I would like to follow pure upstream change (maybe in a branch) and do my change in another
[22:33] <mwhudson> jetto: something like bzr init-repo repo; bzr init repo/upstream
[22:33] <mwhudson> cd repo/upstream; bzr import ~/release-0.1.tgz; bzr add; bzr ci -m 'relese 0.1'
[22:33] <mwhudson> cd ..
[22:33] <mwhudson> bzr branch upstream
[22:34] <mwhudson> bzr branch upstream my-branch (sorry)
[22:34] <mwhudson> cd my-branch
[22:34] <mwhudson> hack hack hack
[22:34] <mwhudson> cd ../upstream
[22:34] <mwhudson> bzr import ~/release-0.2.tgz; bzr add; bzr ci
[22:34] <mwhudson> cd ../my-branch
[22:34] <mwhudson> bzr merge ../upstream
[22:34] <mwhudson> (disclaimer: i haven't done this)
[22:35] <jetto> well I'll test this, thanks.
[22:37] <jetto> It's hard for me to adapt to decentralized SCM
[22:38] <jetto> even choosing one is very hard ;-)
[22:39] <jetto> do I need to do a init-repository ?
[22:40] <mwhudson> you don't need to make a repository no
[22:40] <mwhudson> it's just a way of sharing storage, it takes up less disk space and makes making new branches quicker
[22:40] <mwhudson> but i guess in your case, history is going to be pretty shallow
[22:49]  * Foskasse  1:20 para fazer anos!!!
[23:25] <jetto> mwhudson, your pocedure rocks, thanks
[23:25] <mwhudson> jetto: glad i helped
[23:28]  * Foskasse quase quase quase a fazer anos!!! :D :D :D
[23:31] <Pilky> jetto: if it helps at all you can use bzr as a centralised VCS, with all the improved branching/merging benefits
[23:31] <Pilky> in some ways bzr is one of the best centralised VCSs out there ;)
[23:32] <jetto> Pilky, I think I'll do this but not for home work
[23:53] <luiss> hola
[23:53] <luiss> hola
[23:53] <luiss> hola
[23:54] <poolie> hello
[23:55] <Verterok> mornin' poolie