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