leo2007 | does the windoes installer require python to work properly? | 00:07 |
---|---|---|
Verterok | leo2007: there is a standalone bzr.exe and a installer that needs a python installation | 00:11 |
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:13 |
leo2007 | Verterok: trying to push a local branch to a remote machine through sftp, it didn't succeed | 00:15 |
Verterok | leo2007: any error msg? | 00:16 |
leo2007 | Verterok: it looks like it succeeded but no files were actually uploaded. | 00:19 |
Verterok | leo2007: a push don't create/update a remote workingtree | 00:20 |
Verterok | leo2007: in the remote location you should have a .bzr/ dire | 00:21 |
Verterok | s/dire/dir/ | 00:21 |
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:22 |
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:23 |
Verterok | leo2007: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#push | 00:25 |
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:26 |
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:30 |
Verterok | leo2007: I don't use windows, but take a look to qbzr, bzr-gtk and tbzr (tortoise-like) | 00:34 |
Verterok | leo2007: http://bazaar-vcs.org/QBzr , http://bazaar-vcs.org/bzr-gtk | 00:36 |
Verterok | leo2007: and http://bazaar-vcs.org/TortoiseBzr | 00:37 |
leo2007 | Verterok: thank you very much. I will take some time to read the doc properly. | 00:40 |
Verterok | leo2007: y'r welcome :) | 00:40 |
leo2007 | Verterok: good night;) | 00:42 |
Verterok | leo2007: seeya | 00:43 |
rockstar | james_w, are you around? | 01:42 |
alencool | hello | 07:28 |
alencool | is there anyone in here that could help me? | 07:29 |
skavez | is there an easy way to install bzr-svn on os x? or is recompiling svn still the only way? | 08:31 |
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:32 |
lifeless | ola! | 08:41 |
lifeless | so | 08:41 |
lifeless | who wants to hear some good ne | 08:41 |
lifeless | ws | 08:41 |
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:44 |
RAOF | My my. | 08:45 |
RAOF | That _is_ impressive. | 08:45 |
lifeless | am now ingensting caffeine and grease | 08:45 |
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:46 |
lifeless | git 200, 200 638227 0.6MB | 08:48 |
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:49 |
lifeless | RAOF: oh, I don't do any of that whacky try-N diffs and pick one stuff either. | 08:51 |
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:52 |
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:53 |
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:55 |
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:56 |
RAOF | Right. | 08:57 |
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:58 |
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 | 08:59 |
RAOF | Ok. | 09:00 |
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:01 |
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:02 |
lifeless | the only reason to do this in preference to e.g. lzma is that I know I don' need the intermediate texts | 09:03 |
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:04 |
RAOF | :) | 09:06 |
RAOF | Right. So, nice and quick unpacking. Cool. | 09:07 |
lifeless | yah, typical dictionary decompressiors need to care about the entire input stream | 09:09 |
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:10 |
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:11 |
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:12 |
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:15 |
lifeless | skavez: you need bzr.dev for that version of bzr-svn I think | 09:23 |
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:25 |
skavez | lifeless: ah ok. i'll give that a shot | 09:26 |
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:27 |
BjornT | lifeless: well, i'd love to use mutt :), as long as it would allow me to send the e-mail. | 09:28 |
lifeless | BjornT: poke at the help, and the mnual, failing that file a bug | 09:29 |
BjornT | lifeless: at least it works if i specify mail_client=mutt | 09:31 |
BjornT | xdg-email email@example.com doesn't work either, so i guess that's where the bug is | 09:33 |
lifeless | BjornT: I would guess so | 09:40 |
lifeless | RAOF: lp:~lifeless/+junk/bzr-groupcompress | 09:40 |
lifeless | -<> gate A18 now :) | 09:40 |
=== mwhudson_ is now known as mwhudson | ||
=== Tank|Awa1 is now known as Linnk | ||
j^ | is it a common problem that the trac plugin gets really slow for the /timeline view? | 13:55 |
j^ | when i started a new repos it was ok, but it seams it gets slower with each commit i make | 13:56 |
jetto | hello | 15:15 |
jetto | I come from cvs and Clearcase(base not ucm), and I'm looking to use a more advenced scm tool. | 15:16 |
jetto | I'm very confused with bzr concept I want to do some test one a real work | 15:18 |
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:21 |
jetto | How can I do this on bzr ? I mean having something like a vendor branch on CVS | 15:22 |
Odd_Bloke | jetto: What SCM tool are they using on SF? | 15:34 |
uws | cvs :) | 15:45 |
Odd_Bloke | Hmm, I'm not sure of the best way to deal with CVS is. | 15:46 |
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:49 |
bigdog | I am using windows | 15:50 |
uws | bigdog: yes, or #launchpad | 15:50 |
bigdog | I am using bzr 1.5 | 15:50 |
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:51 |
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:52 |
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:53 |
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:54 |
bigdog | same response for set BZR_SSH=plink | 15:55 |
bigdog | and set BZR_SSH=paramiko | 15:55 |
bigdog | any insight? | 15:55 |
bigdog | uws: Sunday morning is busy day for people, I will try #launchpad | 16:01 |
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:02 |
bigdog | Odd_Bloke: thanks | 16:08 |
Tim3393 | Hello, | 16:19 |
Tim3393 | I have a question regarding the way bazaar does handle duplicate files when storing them in a repository. | 16:19 |
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? | 16:20 |
clemente | Bazaar stops when doing some operations (ex: branch) and starts running again after I press ENTER four times... | 17:35 |
clemente | In fact it's doing read(0,...) according to strace | 17:36 |
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:40 |
clemente | It is probably related to dbus... | 17:50 |
antoranz | hi guys! Do you know when 1.6 is commign out? | 18:14 |
leo2007 | how to set up emacs to use bzr in windows? | 18:28 |
clemente | (I submitted bug 246052 for that problem of halting on STDIN) | 18:34 |
ubottu | Launchpad bug 246052 in bzr "Bazaar halts and silently expects input from STDIN" [Undecided,New] https://launchpad.net/bugs/246052 | 18:34 |
* Foskasse ▄█▀ █▬█ █ ▀█▀ | 19:07 | |
Kinnison | How delightful | 19:09 |
* Foskasse █▬█ █ | 19:26 | |
Kinnison | My god it's expensive to convert from weave to btree-plain | 19:28 |
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:19 |
gour | Kinnison: when is btree supposed to go into trunk? | 20:23 |
Odd_Bloke | kgoetz: That error looks familiar, but I can't remember what causes it. :( | 20:28 |
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:29 |
Kinnison | gour: no idea | 20:34 |
Odd_Bloke | kgoetz: I'd recommend looking through LP for bugs and looking at the ML. | 20:35 |
kgoetz | Odd_Bloke: i'll try and give LP a trawl. | 20:36 |
kgoetz | this bug looks similar, but seems totally unrelated. https://bugs.launchpad.net/bzr-gtk/+bug/237205 | 20:45 |
ubottu | Launchpad bug 237205 in bzr-gtk "error starting webbrowser.GenericBrowser in python2.4" [Medium,Fix committed] | 20:45 |
mwhudson | any devs awake? | 21:44 |
=== 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 | ||
abentley | mwhudson: I'm not *really* awake... | 21:50 |
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:51 |
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:52 |
abentley | mwhudson: I haven't see the actual traceback... | 21:54 |
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:55 |
mwhudson | though the exception is from before the comment | 21:56 |
mwhudson | but yeah, it seems the problem is somewhat known | 21:56 |
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:00 |
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:01 |
abentley | Okay, here's what I think happens. | 22:03 |
abentley | relpath is being used in a check. | 22:03 |
abentley | specifically, if I try to get foo/bar/baz, I should get redirected to */baz | 22:04 |
mwhudson | right | 22:04 |
abentley | And there's a discrepancy between what e thinks the url was and what the transport thinks it was. | 22:05 |
mwhudson | hm hm | 22:10 |
mwhudson | abentley: i think the problem is more basic: | 22:14 |
mwhudson | abentley: http://pastebin.ubuntu.com/25513/ | 22:15 |
* mwhudson winds up a poking for spiv when he wakes up | 22:15 | |
abentley | mwhudson: How does that contradict me? | 22:16 |
mwhudson | abentley: it doesn't | 22:16 |
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:17 |
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:19 |
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:20 |
mwhudson | hm | 22:21 |
abentley | transport.base will give the the final value the transport used. | 22:22 |
mwhudson | so yeah, this stuff in redirected() does look a bit bogus then | 22:25 |
jetto | hum bzr looks like too hard form me :-( | 22:26 |
mwhudson | jetto: ? | 22:27 |
jetto | I would like to do some thing very simple and it's not clear how to do it : | 22:28 |
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:31 |
mwhudson | jetto: i think the 'bzr import' command can help with this | 22:32 |
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:33 |
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:34 |
jetto | well I'll test this, thanks. | 22:35 |
jetto | It's hard for me to adapt to decentralized SCM | 22:37 |
jetto | even choosing one is very hard ;-) | 22:38 |
jetto | do I need to do a init-repository ? | 22:39 |
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:40 |
* Foskasse 1:20 para fazer anos!!! | 22:49 | |
jetto | mwhudson, your pocedure rocks, thanks | 23:25 |
mwhudson | jetto: glad i helped | 23:25 |
* Foskasse quase quase quase a fazer anos!!! :D :D :D | 23:28 | |
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:31 |
jetto | Pilky, I think I'll do this but not for home work | 23:32 |
luiss | hola | 23:53 |
luiss | hola | 23:53 |
luiss | hola | 23:53 |
poolie | hello | 23:54 |
Verterok | mornin' poolie | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!