| igc | beuno: no too bad thanks | 00:00 |
|---|---|---|
| lifeless | jam: hi | 00:09 |
| jam | lifeless: hi | 00:09 |
| jam | $ bzr bench-gc bzrlib/inventory.py --reverse | 00:09 |
| jam | Compressed 312 texts with 12471026 bytes to 1034947 bytes (12.05:1) in 2.403s | 00:09 |
| jam | builtins.py --reverse | 00:10 |
| jam | Compressed 1837 texts with 210568735 bytes to 21061973 bytes (10.00:1) in 113.506s | 00:10 |
| lifeless | jam: sweet | 00:13 |
| jam | NEWS --reverse | 00:13 |
| jam | Compressed 3213 texts with 437350320 bytes to 5814355 bytes (75.22:1) in 116.813s | 00:13 |
| lifeless | jam: this is with your C compressor? | 00:13 |
| jam | lifeless: yes | 00:13 |
| lifeless | jam: where is your branch :P | 00:15 |
| jam | lp:~jameinel/+junk/bzr-groupcompress | 00:15 |
| lifeless | reckon its merale ? | 00:16 |
| jam | lifeless: ? It is well tested | 00:16 |
| lifeless | mergable | 00:16 |
| jam | I think so | 00:16 |
| lifeless | will do | 00:16 |
| jam | I have a couple tweaks yet to do | 00:20 |
| jam | but I think it is a good start | 00:20 |
| jam | anyway, I'm off for a bit | 00:20 |
| lifeless | ok | 00:20 |
| lifeless | nice work | 00:20 |
| fullermd | % bzr bind :push | 00:23 |
| fullermd | abentley++ | 00:23 |
| jiho | hello everyone. I am currently getting to know bzr and one thing I liked in git and can't get in bzr is nice colored output. there's cdiff in bzrtools but is there anything more general (color output on more commands, word diff with colored output etc.)? | 00:34 |
| jiho | I am particularly after some nice word diff options. I do a lot of latex and having word diffs rather than line diffs is necessary. | 00:35 |
| amanica | the lessdiff plugin does the trick for me | 00:35 |
| jiho | thanks I'll check that | 00:37 |
| amanica | (I dont know about word diffs though) | 00:38 |
| lifeless | jiho: how do you do word diffs in git? | 00:39 |
| jiho | git diff --color-words | 00:40 |
| lifeless | thats built in ? | 00:40 |
| jiho | yes | 00:40 |
| lifeless | thanks | 00:40 |
| jiho | well I think. I have wdiff on my system but it does not do color, wo I guess git uses its own code | 00:41 |
| jiho | amanica: care to guide me one how to install lessdiff? I've just cloned it hoping to find a read me but there is just the source | 00:42 |
| amanica | put it in ~/.bazaar/plugins/ | 00:43 |
| jiho | thanks | 00:44 |
| amanica | I aliased my diff to use it. In ~/.bazaar/bazaar.conf in the [ALIASES] section I put the following | 00:45 |
| amanica | diff = 'lessdiff --diff-options "-wp -U10 --strip-trailing-cr"' | 00:45 |
| jiho | thanks for that | 00:45 |
| jiho | too | 00:45 |
| amanica | cool | 00:45 |
| dash | I usually use meld for that | 00:48 |
| jiho | dash: thanks for the tip but I am mostly on OS X | 00:52 |
| mwhudson | should be able to use FileMerge somehow then | 00:53 |
| jiho | yes I can indeed. bzr output is fine for that | 00:53 |
| jiho | just: bzr diff --using="opendiff" | 00:54 |
| jiho | FileMerge has UI glitches when opened this way but it mostly works | 00:54 |
| jiho | the real problem is that it is yet another window open on a small laptop screen | 00:55 |
| jiho | ;) | 00:55 |
| lifeless | anything we can improve to fix the glitches? | 00:55 |
| mwhudson | ah, right | 00:55 |
| jiho | I'll check but my guess is that the issue comes from the opendiff command itself | 00:55 |
| jiho | lifeless: that's right, the issue comes from opendiff (still present when diffing two files outside of bzr). so there's nothing you can do. | 00:59 |
| lifeless | ah well | 01:01 |
| jiho | OK, so the status on this seems to be that is it easy to get coloured line diffs, but not word diffs. I have yet to investigate vimdiff but since I am no vi expert I guess it won't be very productive to use it only to view diffs | 01:01 |
| lifeless | jam: the pyrex step fails | 01:05 |
| lifeless | /home/robertc/source/baz/plugins/groupcompress/trunk/_groupcompress_c.pyx:254:30: Expected an identifier or literal | 01:05 |
| lifeless | jam: its the +=, &= operators | 01:06 |
| lifeless | interesting, its about 10% faster :( | 01:09 |
| jiho | correction on my self. using this in [ALIASES]: | 01:16 |
| jiho | wdiff = 'lessdiff --using="wdiff -l"' | 01:16 |
| jiho | makes it a pretty decent "colourized" word diff | 01:16 |
| jiho | (where colour = bold/underline) | 01:16 |
| jiho | (still there's something visual about it) | 01:16 |
| jiho | cool I can ditch git | 01:19 |
| jiho | ;) | 01:19 |
| jiho | thanks everyone | 01:19 |
| jiho | bye | 01:19 |
| amanica | thanx for teaching me about wdiff | 01:19 |
| amanica | bye | 01:19 |
| AfC | "I can ditch git, kthxbye". That's a nice way to start the day. | 01:20 |
| steltho | bzr branch http://bzr.savannah.gnu.org/r/gnash/trunk gnash_new | 01:32 |
| steltho | bzr: ERROR: Invalid http response for http://bzr.savannah.gnu.org/r/gnash/.bzr/repository/indices/2c779c251220f8afce08bcec69277e32.rix: Expected a boundary ("a3=Zi=KvaN:JowhY.VpV", application/plain) line, got '--a3=Zi=KvaN:JowhY.VpV | 01:33 |
| steltho | ' | 01:33 |
| steltho | I am getting the above error message, trying to create a new branch with bzr. | 01:33 |
| AfC | steltho: which version of Bazaar are you using as your client? [it probably doesn't matter, but people will be curious] | 01:35 |
| steltho | I am using 1.5 | 01:35 |
| lifeless | pretty sure we had a bugfix for that during the 1.6 development cycle | 01:35 |
| steltho | so, do you think if I tried version 1.6b3 this problem might be fixed? | 01:37 |
| lifeless | I think it might be yes | 01:41 |
| steltho | I am trying it now. | 01:41 |
| lifeless | Fix quoted boundary lines bugs exposed by tests in previous revision. | 01:42 |
| lifeless | there are definite boundary improvements | 01:42 |
| lifeless | it might be something else, like a broken local proxy | 01:42 |
| steltho | It is weird because I never had any problems pulling from that location, and then one day it started to get this error message. | 01:43 |
| lifeless | interesting | 01:43 |
| steltho | I also asked on the gnash-dev mailing list and nobody else is having trouble. | 01:44 |
| lifeless | that suggests a local issue of some sort - your machine/router/isp | 01:44 |
| steltho | I just ran across this bug report https://bugs.launchpad.net/bzr/+bug/198646, which looks like it might be similar to my problem. | 01:44 |
| ubottu | Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released] | 01:44 |
| steltho | Hmm, it looks like who ever posted the bug is living in Thailand and thinks that there is some proxy there that is causing the problem. | 01:50 |
| steltho | I also live on that side of the world, so maybe my request is also being distorted by some local proxy. | 01:53 |
| lifeless | steltho: thailand has a country-wide intercepting proxy | 02:11 |
| steltho | Yeah, I wonder if the country I am in has something similar. | 02:16 |
| amanica | I better go sleep now. have to get up in a hour. cheers | 02:42 |
| jam | lifeless: as I mentioned, I still have some tweaking | 02:46 |
| jam | I just added a change which seems to improve things by about 20% | 02:46 |
| jam | I'm hoping to get more from a deeper change | 02:46 |
| jam | but honestly, you were using python dicts and lists like they were *meant* to be used :) | 02:46 |
| jelmer | is .bzrrules is going to be part of the revision tree? I thought it was just going to live in the working tree but have a status similar to .bzr/ ? | 02:49 |
| jam | jelmer: I believe it is going to have a life similar to .bzrigore | 02:51 |
| jam | .bzrignore | 02:51 |
| jam | so it will be versioned | 02:51 |
| jelmer | ah :-( | 02:51 |
| jam | $ bzr bench-gc bzrlib/builtins.py --reverse | 02:52 |
| jam | Compressed 1837 texts with 210568735 bytes to 21061973 bytes (10.00:1) in 84.286s | 02:52 |
| jam | lifeless: ^^ that is down from the 113 that I posted last commit | 02:52 |
| Odd_Bloke | jelmer: How have your experiments with using autoppa on sid been going? | 03:07 |
| jelmer | Odd_Bloke, patched a couple of things then got stuck trying to build bzr-svn | 03:07 |
| jelmer | I haven't looked at it since, not sure how hard my last problem was to fix | 03:07 |
| lifeless | jam: cool; I have pushed a merged version of the previous | 03:07 |
| jam | next tweak drops it to 73s | 03:26 |
| spiv | poolie: | 03:28 |
| spiv | * Knit format repositories are deprecated and bzr will now emit | 03:28 |
| spiv | warnings whenever it encounters one. Use ``bzr upgrade`` to upgrade | 03:28 |
| spiv | knit repositories to pack format. (Andrew Bennetts) | 03:28 |
| spiv | poolie: is that NEWS entry ok with you? | 03:28 |
| poolie | looks good | 03:40 |
| lifeless | jam: 2% in time.clock() | 03:41 |
| jam | lifeless: yeah, I'm taking that out now | 03:41 |
| lifeless | and 12% in flush_range | 03:41 |
| jam | lifeless: well, also be aware that lsprof "lies" and makes python functions much slower than they really are while not skewing the compiled functions. | 03:52 |
| lifeless | jam: I know :) | 03:59 |
| jam | but yeah, for 'builtins.py' you end up with 1837 texts, 1734373 calls to find the longest matching sequence for a given line, and 1727645 calls to 'flush_range' | 04:00 |
| jam | lifeless: so it turns out that for builtins.py one of the major overheads was just reallocating the array of output lines | 04:16 |
| jam | I changed "realloc()" to give myself some fudge room | 04:17 |
| jam | and things got a lot faster | 04:17 |
| jam | I probably am giving a bit too much room | 04:17 |
| poolie | hello jam | 04:17 |
| jam | but it went from 60s => 20s for builtins.py | 04:17 |
| jam | poolie: hi | 04:17 |
| lifeless | jam: nice | 04:17 |
| jam | lifeless: I wish it was easier to profile Pyrex code, though | 04:17 |
| lifeless | jam: gprof? | 04:17 |
| lifeless | or oprofile | 04:17 |
| jam | lifeless: well, I went for the "time.clock()" solution :) | 04:18 |
| jam | the one thing I like about time.clock() is that it doesn't usually interfere with real-world time as much as some of the other solutions. | 04:25 |
| jam | But thanks for the quote spiv | 04:25 |
| jam | :) | 04:25 |
| spiv | jam: It made me smile :) | 04:25 |
| jam | lifeless: so, if I assume that the lsprof values for C code are exact, and the values for py functions are grossly overinflated | 04:26 |
| jam | For the 20s to recompress all of builtins.py | 04:27 |
| jam | 13s is spent in get_longest_matching | 04:27 |
| jam | NEWS takes 38.8s, with 31.4s in get_longest_matching | 04:27 |
| lifeless | the quote ? | 04:27 |
| jam | So it is still a large portion of overall time. | 04:27 |
| jam | lifeless: Quotes page | 04:28 |
| lifeless | oh :) | 04:28 |
| jam | still, it is finally a net win | 04:29 |
| jam | I was actually seeing a net *loss* for a while there | 04:29 |
| jam | I just checked memory consumption for a second and got a bit frightened | 04:35 |
| jam | recompressing NEWS was taking almost 800MB | 04:35 |
| jam | and then I realized, that is just because my bench-gc code extracts everything first | 04:35 |
| jam | I don't know why I'm getting 2x the raw bytes | 04:35 |
| jam | any ideas? | 04:36 |
| jam | (reverting to an older version shows identical memory usage) | 04:36 |
| jam | lifeless: 'time bzr branch plugins/bzrtools gc-repo/bzrtools" 42s | 04:38 |
| lifeless | hmmm | 04:40 |
| jam | did you ever get anywhere with changing the insert order? | 04:40 |
| lifeless | in progress | 04:40 |
| jam | (time bzr branch bzrtools into a packs repo is 4.5s) | 04:40 |
| * igc lunch | 04:41 | |
| lifeless | I'm trying to decide whether to alter GenericRepoFetcher | 04:45 |
| lifeless | or do a custom | 04:45 |
| jam | lifeless: I don't think you want to "generically" fetch in reverse topological order, do you ? | 04:52 |
| lifeless | jam: I am considering having get_record_stream(versions, self.target._fetch_order, not self.target._fetch_uses_deltas) | 04:53 |
| lifeless | jam: how much of that 42 seconds is in reconcile ? | 04:58 |
| jam | lifeless: lsprof breaks it down (as 105s0 into: http://rafb.net/p/HxGoOe37.html | 05:06 |
| jam | 51s in 'insert_record_stream' | 05:07 |
| jam | 31s in 'fetch revision texts' | 05:07 |
| jam | 9s in fetch inventory | 05:07 |
| jam | 12s in 'item_keys_introduced by' | 05:07 |
| jam | insert_record_stream is 18.7s in 'compress' | 05:07 |
| jam | 23s in 'get_bytes', and 18s in 'get_record_stream' | 05:08 |
| jam | and down around 4.4s spent in 'get_matching_blocks' | 05:09 |
| jam | flush_range goes way up on topo-order insertions | 05:09 |
| jam | because it finds lots of short matches | 05:09 |
| lifeless | yeah | 05:10 |
| jam | lifeless: so... if I understand all this correctly, the re-compression time is actually pretty trivial | 05:10 |
| jam | versus the api mismatches going from Pack => GC repos | 05:11 |
| jam | probably just because we have to go through the GenericRepoFetcher | 05:11 |
| lifeless | somewhat yeah | 05:11 |
| lifeless | I'd like to make the delta format more C optimised | 05:11 |
| jam | I think the 18s total in compress, versus the 23s in get_bytes + 18s in get_record_stream kind of point to the major slow-down being the *extract from packs* side of things. | 05:12 |
| jam | lifeless: I don't know how you feel about it, but I would recommend unifying bytes versus lines for "copy" versus "insert" | 05:13 |
| lifeless | we also are extracting from the group we're inserting into | 05:13 |
| lifeless | jam: yeah, i(byte-count) | 05:13 |
| jam | lifeless: and you *might* consider special casing inserting a newline | 05:13 |
| jam | It may not be a huge win | 05:13 |
| lifeless | I'm thinking a pure C extract facility | 05:13 |
| lifeless | well | 05:13 |
| jam | but I was seeing 26,000 "i1\n\n" | 05:13 |
| lifeless | I mean i(byte_count)[bytes] - no more \n after the isntruction, self delimited count | 05:14 |
| lifeless | e.g. a qw counter, or variable-length bitfield | 05:14 |
| jam | lifeless: sure | 05:14 |
| jam | I'm not sure if that gives you a lot after zlib | 05:14 |
| lifeless | could be | 05:15 |
| === mark1 is now known as markh | ||
| lifeless | so the 26K i1\n\n is because those 4 bytes are cheaper than a c instruction for the same | 05:15 |
| jam | lifeless: sure, but a "n\n" is 2x cheaper still | 05:15 |
| jam | again, that would save... 52K bytes | 05:15 |
| jam | but again, the entropy encoder may nuke that anyway | 05:16 |
| jam | And it is only about 0.2% of the total output size | 05:17 |
| jam | (before zlib) | 05:17 |
| jam | lifeless: wow: Compressed 1837 texts with 210568735 bytes to 657272 bytes (320.37:1) in 22.620s | 05:21 |
| jam | After using zlib over the whole stream | 05:21 |
| lifeless | yes :) | 05:22 |
| lifeless | jam: you see why the threshold is set at 20MB currently :P | 05:22 |
| jam | lifeless: though that means that to get *any* of the texts you need to read 20MB, right? | 05:23 |
| jam | Or were you thinking to use Z_SYNC_FLUSH so that you could read any subset | 05:23 |
| jam | also, my result is slightly skewed, as I forgot the final flush() | 05:26 |
| jam | still 318:1, though | 05:27 |
| mwhudson | impressive numbers :) | 05:28 |
| jam | bz2 only gets 325:1 on builtins.py | 05:28 |
| lifeless | jam: you need to read 650K to get any text | 05:28 |
| jam | well, builtins.py is only 170k ATM, so that is a bit extra | 05:29 |
| jam | mwhudson: NEWS is a special case, but there I get 1391:1 compression :) | 05:29 |
| jam | (NEWS being a *big* file that only has lines appended to it, so not a lot of churn, and a lot of redundant lines between versions) | 05:30 |
| jam | interestingly after zlib, I'm at 380k for NEWS, while NEWS on disk is 258k | 05:31 |
| lifeless | right, so possibly 10MB before starting a new group | 05:31 |
| jam | so *almost* compressed down to 1:1 :) | 05:31 |
| jam | I guess there is *some* churn in NEWS | 05:31 |
| lifeless | there are a few full-content patches | 05:31 |
| lifeless | where we realigned stuff | 05:32 |
| jam | ah, sure | 05:32 |
| jam | and changed the formatting to ReST, etc | 05:32 |
| lifeless | so my basic idea is | 05:32 |
| lifeless | to tune this | 05:32 |
| lifeless | so that while we read a bit more its a single read for many parts of a tree | 05:33 |
| lifeless | which should be a big win | 05:33 |
| jam | lifeless: Sure, though I again wonder about Z_SYNC_FLUSH after every text inserted | 05:33 |
| lifeless | and yeah not reading 600K for the front text | 05:33 |
| jam | or maybe just periodically | 05:34 |
| lifeless | well | 05:34 |
| lifeless | I'd rather not TBH :) | 05:34 |
| jam | as a lot of the "texts" are just tiny "c,X,Y" bits | 05:34 |
| lifeless | I'd rather just add e.g. 50K to the current position | 05:34 |
| lifeless | zlib has a 32K buffer | 05:35 |
| jam | lifeless: well, I was thinking about doing it: 1) After the first text, 2) after zobj.compress() returns data | 05:35 |
| jam | And I thought it was a 64k buffer | 05:36 |
| jam | but I certainly could be wrong about that | 05:36 |
| jam | anyway I need to go sleep | 05:36 |
| lifeless | gnight! | 05:36 |
| treeform | hi all i am trying to get bzr working on windows ... its always been pretty easy (thats why i use bzr) but it let me down this time. If i install bzr-win-standalone i dont get paramiko support and i cant seem to install it any place inside its installation .... if i install the bzr for python that i allready have then i cant get to ti form the shell please help. | 05:36 |
| jam | make sure to get my latest version | 05:36 |
| jam | revno 51 is a pretty big win | 05:36 |
| treeform | jam for me?? | 05:38 |
| lifeless | jam: 0.05seconds faster on my test-load :P | 05:39 |
| lifeless | markh: ^ | 05:52 |
| lifeless | treeform: jam was talking to me | 05:52 |
| treeform | thats ok | 05:52 |
| treeform | 1.5 works | 05:52 |
| treeform | and i submited bug report | 05:52 |
| markh | treeform; I've an experimental binary you can try if you are keen. | 05:53 |
| treeform | sure give me 1 hour thouh | 05:54 |
| treeform | be back | 05:54 |
| markh | ok | 05:55 |
| jml | lifeless: hi | 06:11 |
| jml | lifeless: do you mind if I add something about the "loom now shows current thread on status" to NEWS? | 06:11 |
| treeform | markh: ok | 06:14 |
| treeform | back | 06:14 |
| treeform | what kind of binary you have? | 06:14 |
| markh | treeform: http://starship.python.net/crew/mhammond/bzr-setup-1.6b4-mh1.exe is fairly recent, includes paramiko and works fine for me with ssl, and includes an experimental tortoisebzr | 06:16 |
| markh | So I'd really like to hear it works for you too :) | 06:16 |
| treeform | tortoisebzr ! | 06:16 |
| treeform | wpw | 06:16 |
| treeform | wow* | 06:16 |
| markh | I've actually got another with the svn plugin included, but I havem't uploaded that yet | 06:16 |
| treeform | one of the big reasons my artists done like using bzr is because its command line | 06:17 |
| markh | I ran out of time for bzr this week :( | 06:17 |
| treeform | if you get the tortoisebzr to work that would be great! | 06:17 |
| markh | yeah, it will, and hopefully soon :) You should be able to checkin files using tortoise if they are on your local disk with that release - but its *very* early and need lots more "meat" before it could be recommended. | 06:18 |
| lifeless | jml: please do | 06:19 |
| markh | but - the non-tortoise bits of that release should be rock-solid! | 06:19 |
| treeform | markh: what is missing from the tortoise? | 06:19 |
| markh | too many things to mention :) | 06:19 |
| markh | the list of what works is much smaller :) the readme should let you know | 06:19 |
| markh | but there is lots of hidden "framework" in place | 06:20 |
| treeform | ok | 06:20 |
| treeform | are you contributing to the tortoisebzr or just packaging it? | 06:20 |
| markh | I'm the main contributor | 06:21 |
| treeform | oh great | 06:21 |
| markh | the packaging more fell in my lap ;) | 06:21 |
| treeform | :) | 06:21 |
| treeform | yeah that is how it goes | 06:21 |
| treeform | i am checking out my codes base on this new windows install (the code is 300mb) so its going a bit slow as soon as its done i will install your version and see how it works | 06:22 |
| treeform | markh: what gui tool kit does tortosebzr use? | 06:23 |
| treeform | last time i remmber it was some thing odd like GTK | 06:23 |
| treeform | GTK on windows ... | 06:24 |
| markh | yeah, I think bqzr is a better fit for windows - native l&f | 06:25 |
| markh | I'm not sure the old tortoise ever was released as a binary either | 06:25 |
| treeform | bqzr -- google did not find any thing cool | 06:25 |
| treeform | markh: could you fill me in on history of windows bzr tools? | 06:26 |
| treeform | it looks like lots of starts and no finishes | 06:26 |
| spiv | I think he means "qbzr" | 06:26 |
| markh | so I now intend advocating qbzr to everyone who will listen so tortoise gets all enhancements "for free" :) | 06:26 |
| treeform | explain ... are the projects related? | 06:27 |
| lifeless | spiv: can I ring your house to get poolie ? :) | 06:28 |
| spiv | lifeless: yep | 06:28 |
| markh | yes, sorry, qbzr. The history or tortoise is that it was a google SOC project that didn't quite get finished. This one will - clearing hurdles like binary releases and gui toolkits is critical, hence that is being done before it is "finished" | 06:28 |
| markh | qbzr and the gtk extensions are developed independently of each other, and without Windows in mind. However, tortoise doesn't need to invent yet another toolkit, so has to choose a bandwagon to jump on :) | 06:29 |
| treeform | so you are just doing a framework around explorer shell that integrates with qbzr? | 06:29 |
| markh | yes - tortoisesvn for bzr | 06:30 |
| markh | in effect | 06:30 |
| markh | it turns out to require a remote "cache/command" process and an RPC mechanism, which is much of the "invisible framework" I mentioned. | 06:30 |
| treeform | oh | 06:31 |
| markh | short version of the story: we don't want python+bzrlib embedded in every process that uses the shell, so we have a lightweight shell extension and heavier process the shell talks to | 06:32 |
| treeform | ok | 06:33 |
| treeform | markh | 06:38 |
| treeform | so i do bzr checkout | 06:38 |
| treeform | it throws an error | 06:38 |
| markh | that's no good :( | 06:38 |
| treeform | unrecognizedCommandError: checkout | 06:38 |
| treeform | bzr branch worked | 06:38 |
| markh | hrmph - its listed in "bzr help commands"? | 06:39 |
| treeform | yes | 06:40 |
| treeform | way more commands then i am used too | 06:40 |
| treeform | there is no "qcheckout" | 06:41 |
| treeform | but there is "qbranch" | 06:41 |
| markh | oh - you mean from tortoise? | 06:41 |
| treeform | no | 06:41 |
| markh | hrm | 06:41 |
| treeform | from cmmand line C:\p>bzr help commands | 06:42 |
| treeform | lists bunch of commands | 06:42 |
| treeform | and checkout is there | 06:42 |
| markh | so yeah, I have no 'qcheckout' either - but 'checkout' works for me. Not all commands have 'q' versions. | 06:42 |
| treeform | yeah | 06:42 |
| treeform | i am trying to check out through tortoise context menu | 06:42 |
| treeform | i think the command line checkout should work | 06:43 |
| markh | yes - cmdline checkout should work - but tortoise not working wouldn't surprise me ;) | 06:44 |
| treeform | oh | 06:44 |
| markh | I mean, tortoise getting as far as displaying the menu and trying to execute *something* is great news from my POV :) | 06:44 |
| pygi | so somebody is working on tortoise again?! | 06:45 |
| * markh is | 06:45 | |
| pygi | markh, nice, thanks | 06:46 |
| pygi | how is it going? | 06:46 |
| markh | we have a solid framework in place and now need to fill it out a little. Its not ready to recommend its use, but its looking good with that in mind :) | 06:47 |
| pygi | marianom, who's "we"? :P | 06:47 |
| pygi | and how do I signup to help after I'm back from vacations? | 06:47 |
| pygi | actually, gimme bzr branch :P | 06:47 |
| pygi | that's the best way to signup :) | 06:47 |
| treeform | pygi: marh gave me a binary | 06:48 |
| treeform | i am testing it now | 06:48 |
| pygi | binary? A python binary? | 06:48 |
| pygi | markh, what did I miss? xD | 06:48 |
| treeform | http://starship.python.net/crew/mhammond/bzr-setup-1.6b4-mh1.exe | 06:48 |
| treeform | and installer with tools | 06:48 |
| pygi | ah, bzr :P | 06:48 |
| === davi_ is now known as davi | ||
| pygi | no idea, can't test, don't use windows :) | 06:49 |
| markh | stand-alone binary. See the tbzr project on launchpad - branch is there and contributions welcome :) | 06:49 |
| markh | well, help on qbzr, as we are leaning on that :) | 06:49 |
| pygi | I don't have much idea about qbzr, I know bzr-gtk tho :P | 06:50 |
| pygi | but we'll see :) | 06:50 |
| markh | bugger :) I knew that would happen! But qt really looks much slicker | 06:50 |
| markh | and look-and-feel matters on windows. | 06:50 |
| pygi | markh, I mentored creation of Olive in bzr-gtk so :) | 06:50 |
| pygi | markh, hm... | 06:51 |
| markh | yeah - sadly the gtk extensions were more mature, but the qt framework really looks nicer on windows | 06:51 |
| markh | with help it could be user configured ;) | 06:52 |
| markh | for many commands I am literally just calling the plugin | 06:52 |
| markh | adding zero value to the process :) | 06:52 |
| pygi | hehe :) | 06:52 |
| pygi | markh, btw! | 06:54 |
| pygi | I think there was/is a really slick gtk theme for windows | 06:54 |
| lifeless | there is/was a 'win32' theme engine which uses native widgets | 06:55 |
| pygi | lifeless, that might be it :P | 06:56 |
| markh | I don't know much about gtk - but the gtk plugin on windows looks alot like pidgin and very obviously gtk | 06:56 |
| lifeless | http://charupload.wordpress.com/2007/12/02/gtk-theme-engines-for-win32/ | 06:56 |
| pygi | that being said, as long as it's functional, users will be happy | 06:57 |
| pygi | lifeless, thanks ;) | 06:57 |
| lifeless | hmm that is not what I was thinking of | 06:57 |
| markh | and to be quite honest, I mentioned things on the list and one person pointed me at QBzr due to its look and feel and noone disagreed. I checked it out and agreed. But if you can get a mini-revolt together saying the project would be better served with gtk, I'd be happy to go along with it :) | 06:58 |
| * lifeless keeps looking | 06:58 | |
| markh | ie, I'm completely neutral in this :) | 06:58 |
| lifeless | markh: I don't really care :P | 06:58 |
| markh | yeah :) I more meant pygi :) | 06:58 |
| markh | anyone who wants to advocate one over the other can borrow my soapbox ;) | 06:58 |
| pygi | markh, as long as people are happy, I'm good :P | 06:58 |
| pygi | so no need for fight :) | 06:59 |
| markh | me too - cool :) | 06:59 |
| markh | hehe - or voilent agreement ;) | 06:59 |
| lifeless | http://gtk-wimp.sourceforge.net/ | 06:59 |
| lifeless | thats it | 06:59 |
| markh | I must tell the pidgin and bzr-gtk guys about it ;) | 07:00 |
| lifeless | http://gtk-wimp.sourceforge.net/screenshots/gfx/Gaim-WinXP.png | 07:00 |
| pygi | markh, about what?? :P | 07:00 |
| lifeless | markh: is that screenshot what pidgin looks like today? | 07:01 |
| lifeless | http://gtk-wimp.sourceforge.net/screenshots/gfx/xp.gif | 07:01 |
| markh | can see that exact dialog, but pretty much, yeah | 07:05 |
| lifeless | markh: ok, so perhaps pidgin is already using it :( | 07:06 |
| markh | yeah, I think it might be - just some parts of it don't quite look native | 07:06 |
| jml | file dialogs won't | 07:08 |
| lifeless | won't what | 07:08 |
| jml | look native | 07:08 |
| luks | gtk buttons will never look native on windows | 07:09 |
| luks | but that's gtk's fault, not wimp's | 07:09 |
| markh | I wish the choice wasn't there to be had, and instead there was one that got everyone's energy ;) | 07:09 |
| pygi | markh, ++ on that, but heh | 07:09 |
| luks | they will never have exact sizes and usually they also have icons (but that's applications fault) | 07:09 |
| kiorky | hellon i need some advice or experience toward bzr hosting. What i need is something like a centralized bunch of repository like we can had do with svn. I ve done something similar with mercurial and its forest extension. But with bazaar i m wondering what is the right way to have a bunch of repositories inside repositories and then serve them. Serving include control access like with sv authz format (on this purpose, i ve seen something called | 07:27 |
| pygi | kiorky, in theory my best answer would be "cheezburger" | 07:29 |
| pygi | in practice, that won't be available 'till end August or sometimes in September | 07:29 |
| kiorky | pygi: is that usable in some dev branch? | 07:29 |
| pygi | kiorky, no, that's only usable in my head sadly | 07:30 |
| kiorky | or are they just planned | 07:30 |
| kiorky | pygi: hehe | 07:30 |
| pygi | kiorky, but it's indented purpose is exactly what you stated | 07:30 |
| kiorky | pygi: so how launchpad is handling the whole? | 07:30 |
| pygi | kiorky, I guess they have their own settings with ssh keys. | 07:31 |
| kiorky | pygi: branch per dev/ lots of branches per repo | 07:31 |
| pygi | kiorky, will be possible I'm sure | 07:31 |
| * pygi notes all the use-cases :p | 07:31 | |
| lifeless | kiorky: so our forest equivalent is 'nested trees' | 07:32 |
| pygi | kiorky, the important thing is to get that working, but also the other workflow with mainline repos | 07:32 |
| lifeless | kiorky: but its immature | 07:32 |
| kiorky | pygi: am i wrong to say that shared repositories are intended to have branches from the same project? | 07:33 |
| lifeless | kiorky: shared repositories can handle arbitrarily large numbers of projects | 07:33 |
| lifeless | kiorky: I have one with 13K branches, of 13K projects | 07:33 |
| kiorky | pygi: not a/Someproject a/Otherproject | 07:33 |
| lifeless | kiorky: that works fine | 07:33 |
| kiorky | lifeless: ok, can i partially check out just one branch ? | 07:33 |
| lifeless | kiorky: do you mean get just some subset of the files on disk ? | 07:34 |
| kiorky | lifeless: yep | 07:34 |
| lifeless | igc: has been planning a 'views' feature that will do that | 07:34 |
| kiorky | repo has a/b a/c, just a/c | 07:34 |
| kiorky | where b and c are two distinct branches | 07:35 |
| lifeless | kiorky: if the repo has a/b and a/c as branches you can get just a/c | 07:35 |
| igc | kiorky: filtered views will provide that | 07:35 |
| lifeless | kiorky: 'repositories' are _just_ storage optimisation - they don't affect how branches work | 07:35 |
| igc | see http://bazaar-vcs.org/FilteredViews | 07:36 |
| kiorky | lifeless: so i can checkout a/c or a/c/d/e/f if c and f are branches isnt it ? | 07:36 |
| kiorky | lifeless: is there anyway to serve that over http | 07:37 |
| lifeless | kiorky: yes. if c and f are branches you can check them out | 07:37 |
| lifeless | kiorky: sure, that will work over http just fine: | 07:37 |
| lifeless | bzr init-repo a | 07:37 |
| lifeless | bzr init a/c | 07:37 |
| lifeless | mkdir a/c/d | 07:37 |
| lifeless | mkdir a/c/d/e | 07:37 |
| lifeless | bzr init a/c/d/e/f | 07:37 |
| kiorky | lifeless: to continue, so each project can be a separate branch in my shared repository ? | 07:38 |
| kiorky | lifeless: but then how can i centralize the adfministrative stuff ? ~/.bazaar/access.conf ? | 07:38 |
| kiorky | lifeless: plan is to move my company over to bazaar | 07:38 |
| kiorky | i m planning the new layout :p | 07:39 |
| kiorky | going to work, see ya in something like one hour :) | 07:39 |
| kiorky | and trhx | 07:39 |
| lifeless | ok | 07:39 |
| lifeless | see you when you get back | 07:39 |
| pygi | lifeless, eh, so we need to automate all that magic with cheezburger =) | 07:40 |
| lifeless | pygi: IcanHaz? | 07:40 |
| pygi | lifeless, yes, ICanHaz easy bzr :P | 07:40 |
| pygi | told ya I wanna contribute finally somehow, it's been a while since I contributed by mentoring :P | 07:41 |
| pygi | can't play that card all the time =) | 07:41 |
| lifeless | :) | 07:42 |
| kiorky | lifeless: pygi re | 09:05 |
| pygi | kiorky, re | 09:05 |
| pygi | you've got my mail in pm | 09:05 |
| kiorky | yep i saw it before leaving | 09:07 |
| pygi | kiorky, great, so send me a mail pls with all your requirements in it? :) | 09:08 |
| kiorky | pygi: yep, something like this evening or tomororow i think | 09:08 |
| pygi | kiorky, thanks | 09:09 |
| pygi | appreciate it | 09:09 |
| kiorky | pygi: what i need is a layout similar to the onse i use for minitage | 09:09 |
| kiorky | pygi: http://trac.minitage.org/trac/browser | 09:09 |
| kiorky | pygi: http://hg.minitage.org | 09:09 |
| pygi | well, let's hope you'll be able to have it then =) | 09:10 |
| igc | night all | 09:10 |
| pygi | night igc | 09:10 |
| pygi | kiorky, gotta make the layout flexible somehow anyway | 09:11 |
| kiorky | pygi: and after that we ll like to have something like automatic bundle buggy integration and etc | 09:14 |
| pygi | kiorky, and loggerhead integration, I know | 09:14 |
| * pygi would gladly work on this full-time, but since there's no so much time ... :P | 09:15 | |
| kiorky | pygi: you push a new branch inside the "big repo", from there it will inherit the acls you have defined somewhere, it will be integrated into the viewers (loggorhead, trac, whatever) and the project will be registrated with tools like PQM, bundlebuggy | 09:16 |
| kiorky | pygi: hehe , as many of us | 09:16 |
| pygi | kiorky, ok, so you just mentioned tasks for like 3 months for a start at least xD | 09:17 |
| kiorky | pygi: and it can be served though http, push via ssh, and maybe webdav, but im not sure we can push over webdav with bzr | 09:17 |
| pygi | kiorky, sure we can, but I'd rather avoid pushing through webdav | 09:17 |
| kiorky | me either | 09:17 |
| kiorky | but its somthing usefull through firewalls | 09:18 |
| pygi | there is bzr-webdav plugin | 09:18 |
| pygi | do firewalls really block ssh connections? o.O | 09:18 |
| kiorky | yep , i saw it before, but i dont know its status unfortunatly | 09:18 |
| pygi | kiorky, it's recently been fixed so it works now | 09:18 |
| kiorky | pygi: yep, maany corp firewalls allow outcoming traffics only on specific ports | 09:18 |
| pygi | evil :p | 09:19 |
| kiorky | so commiting when you are at work will be diffcult, there are ways to work around :p like making a ssh tnnel oer http with apcache proxy | 09:19 |
| kiorky | then commiting your stuff :] | 09:19 |
| pygi | hehe | 09:20 |
| pygi | ah, ok | 09:20 |
| pygi | noted as well | 09:20 |
| pygi | gotta get the basics layed out first tho :P | 09:20 |
| kiorky | pygi: i ll can help to contribute, im relasing minitage i think this week end | 09:20 |
| kiorky | and i will freeze devs for a bit to regenrate ideas to continue | 09:21 |
| kiorky | so i ll have some time | 09:21 |
| pygi | right =) | 09:21 |
| pygi | I'm gonna do a bit of coding next week, then vacation, and then some more coding :) | 09:21 |
| pygi | but contributions are more then welcome | 09:21 |
| pygi | you're the third person this week that needs this, so xD | 09:24 |
| kiorky | pygi: for acls, bzr_access seems good for the prupose | 09:24 |
| kiorky | but i just had an eye on it | 09:25 |
| kiorky | i ll test it | 09:25 |
| kiorky | last time i did that for mercurial | 09:25 |
| kiorky | i reimplemented it :p | 09:25 |
| kiorky | ( http://hg.cryptelium.net/hg/system/config/hg/file/aeebb5a560c0/hg-ssh/hg-ssh ) | 09:25 |
| kiorky | pygi: hte plus i have with zr is the really good jelmer's bzr-svn | 09:26 |
| kiorky | pygi: i cant do that with hg :p | 09:26 |
| pygi | kiorky, bzr_access can be used as a start for defining permissions, sure | 09:28 |
| kiorky | pygi: on top of the script, i use posix acls to define file access | 09:28 |
| pygi | we'll see =) | 09:28 |
| kiorky | pygi: the configuration file is parsed with http://hg.cryptelium.net/hg/system/config/hg/file/aeebb5a560c0/hg-ssh/hg-ssh.aclmaker.py | 09:29 |
| kiorky | pygi: and generate a shell script to set the acls :) | 09:29 |
| pygi | :P | 09:29 |
| pygi | what I was thinking for example is: | 09:30 |
| pygi | bzr branch bzr@domain.com:repository/branch | 09:31 |
| kiorky | /B 3 | 09:33 |
| kiorky | /B 3 | 09:33 |
| kiorky | rah | 09:33 |
| pygi | hm? | 09:33 |
| guyblak | I'm trying to use bzr + pageant + buildbot, and it works with from the commandline, but it keeps erroring out when buildbot is added to the mix, anyone have any suggestion where/how to fix this? | 10:58 |
| lifeless | well, what error? | 11:05 |
| lifeless | is pageant not found/some error logged in ~/.bzr.log ? | 11:07 |
| === menesis1 is now known as menesis | ||
| j^ | hi, after merging changes from another branch, trac-bzr 0.11 fails here with | 12:05 |
| j^ | NoSuchRevision: KnitPackRepository | 12:06 |
| jelmer | j^, please file a bug | 12:37 |
| pickscrape | Is igc here? | 12:54 |
| bob2 | it is 10pm | 12:57 |
| james_w | pickscrape: he's probably sleeping | 12:57 |
| james_w | or at least left for the evening | 12:57 |
| pickscrape | Ah. The Bazzar success story he mailed to the mailing list about was the one I was doing | 12:57 |
| james_w | I thought it might be | 12:58 |
| pickscrape | The blog post was from a colleague of mine. | 12:58 |
| james_w | did the switch go well? | 12:58 |
| pickscrape | Very well indeed. It was a 27-hour working stint for me, but well worth it in the end. | 12:58 |
| james_w | wow | 12:59 |
| pickscrape | Yeah, I don't do that very often :) | 12:59 |
| james_w | I'm glad it's working well for you though. | 12:59 |
| james_w | were you the version control expert that was mentioned in the post? | 12:59 |
| pickscrape | Yes, apparently I'm a guru. I didn't know that... | 13:00 |
| LarstiQ | :) | 13:00 |
| pickscrape | I've moved this company from CVS to SVN, then SVK and now bzr | 13:00 |
| pickscrape | Hopefully I won't have to do it again :) | 13:00 |
| uws | jelmer: ping | 13:18 |
| uws | If I want to convert a SVN repo to bzr | 13:18 |
| uws | and it has both trunk, tags and branches | 13:18 |
| uws | how do I create a nice bzr repo from it? | 13:18 |
| uws | jelmer: bzr init-repo and then branching individual svn+ssh://.../branches/foo in there? | 13:19 |
| uws | bzr branch svn+ssh://..../ works as well | 13:19 |
| uws | but then I end up with trunk/, tags/ and branches/ in my bzr branch. | 13:19 |
| james_w | you may want to try svn-import | 13:20 |
| jelmer | uws: Hi | 13:30 |
| jelmer | uws: Yeah, you probably want svn-import | 13:30 |
| uws | jelmer: I'm trying that, but I fail in getting it to work | 13:31 |
| jelmer | What error are you getting? | 13:31 |
| uws | jelmer: the svn repo is svn+ssh://...../path/to/svn/PROJECTNAME/{trunk/,branches/,tags/} | 13:31 |
| uws | bzr svn-import --verbose --prefix=FOO svn+ssh://.../svn/FOO fails | 13:32 |
| uws | No Repository found at .... | 13:32 |
| jelmer | Specify svn+ssh://.../svn without FOO | 13:32 |
| uws | jelmer: no output | 13:33 |
| jelmer | uws, what version of bzr-svn? | 13:33 |
| jelmer | I did some fixes to this recently in the 0.4 branch, may work better withthat | 13:33 |
| uws | ii bzr-svn 0.4.10-2 Bazaar plugin providing Subversion integration | 13:33 |
| jelmer | uws, is this a public repo? | 13:33 |
| uws | jelmer: see /msg | 13:34 |
| uws | (for the curious: I'm currently just branching the trunk/ and branches into a bzr repo instead of using svn-imort. that works) | 13:38 |
| proppy | Hi, how do I drop a changeset (i.e: checkout a previous revision, and make a new changeset) ? | 14:12 |
| proppy | do I need to branch to another directory ? | 14:12 |
| LeoNerd | When you say drop, do you mean permanently forget you ever committed it? | 14:19 |
| === yacc_ is now known as yacc | ||
| proppy | LeoNerd: yep, I accenditaly commit two changes in one changeset | 14:28 |
| proppy | I want to split them | 14:28 |
| luks | proppy: bzr uncommit | 14:28 |
| LeoNerd | OK.. Well, I usually "bzr uncommit" to remove the top one | 14:28 |
| proppy | ah nice | 14:28 |
| proppy | I branched to previous revision | 14:28 |
| LeoNerd | It forgets you committed, but leaves the workdir files just as they are... so a "bzr diff" will show all the changes again | 14:28 |
| proppy | but I will use uncommit the next time I made the same mistake | 14:29 |
| proppy | thanks | 14:30 |
| uws | jelmer: still here? | 14:53 |
| jelmer | uws, yep | 14:53 |
| uws | The conversions and stuff have worked out pretty well | 14:53 |
| uws | I've even convinced $colleague and $project_lead to make the switch official | 14:53 |
| uws | so after I've setup an (internal) wiki page and prepared backup stuff, my project is officially hosted in bzr :) | 14:54 |
| uws | jelmer: One problem though | 14:54 |
| uws | for now we want to keep SVN in sync (for a little while) | 14:54 |
| uws | but pushing one of the bzr branches (with a few commits already with some merges) back to SVN crashes bzr-svn | 14:55 |
| uws | bzr: ERROR: svn.core.SubversionException: ("Failure opening '/SOMEUNRELATEDPROJECT/trunk'", 160016); | 14:55 |
| uws | jelmer: This is the same SVN repo I told you about in /msg, i.e. /path/to/svn/PROJECTNAME/{trunk/,tags/,branches/} | 14:56 |
| uws | (so the SVN repo is shared between projects) | 14:56 |
| jiho | hi everyone. Is that http://pastie.textmate.org/private/xqpf8v7jntqmbocs6tvza only happening to me or is it a known bug? | 15:03 |
| jiho | I am using bzr 1.5 | 15:03 |
| james_w | hi jiho | 15:04 |
| james_w | could you run "bzr -Derror diff" and pastebin the output please? | 15:04 |
| * jiho pasted http://pastie.textmate.org/private/fgnjmiofirydr9i4dka | 15:05 | |
| jiho | here it is ↑ | 15:05 |
| spiv | Ooh, up arrow. Fancy :) | 15:05 |
| jiho | yes I love that ;) | 15:06 |
| james_w | ah, you have lessdiff installed | 15:06 |
| spiv | jiho: that error appears to be caused by the lessdiff plugin you have installedc | 15:06 |
| james_w | I'm guessing you don't have "less" installed though | 15:06 |
| jiho | argh | 15:06 |
| spiv | jiho: I'm betting that if you try "bzr --no-plugins diff" the error won't occur. | 15:06 |
| jiho | less? as a plugin or the actual less command? | 15:06 |
| spiv | (obviously it won't use the lessdiff plugin either) | 15:06 |
| spiv | jiho: the traceback says it's happening when the lessdiff plugin tries to do os.execvp(pager, [pager, '-R', '-']) | 15:07 |
| spiv | jiho: so, the actual less command (or whatever pager the plugin is trying to use) | 15:07 |
| jiho | ok I've found the issue | 15:08 |
| jiho | sorry, nothing to do with bzr | 15:08 |
| jiho | my $PAGER was set to "less -R" (to try and get git to wrap those %$\* lines, which did not work by the way) | 15:09 |
| james_w | no problem | 15:09 |
| spiv | Hmm. | 15:09 |
| james_w | lessdiff should handle that though probably. | 15:09 |
| jiho | so lessdiff was trying to find the command "less -R" | 15:09 |
| spiv | It might be nice if bzr warned when errors are raised from inside a plugin, (i.e. the traceback includes a file inside the plugin path). | 15:09 |
| spiv | I'll file a wishlist bug... | 15:10 |
| philn | hello fellow hackers of the branches | 15:13 |
| jiho | james_w: I've sent an email to lessdiff devs about that | 15:14 |
| philn | i'm trying to branch lp:bzr-svn but i get this: http://pastebin.ca/1082570 | 15:14 |
| philn | with bzr 1.6 beta3 | 15:15 |
| james_w | jiho: great, thanks | 15:15 |
| philn | jelmer: ? | 15:16 |
| Peng_ | philn: I think bzr-svn's branches are in a different repo format. | 15:16 |
| Peng_ | jelmer: Augh, you push --overwrite lp:bzr-svn too much. | 15:17 |
| james_w | philn: I can't access pastebin.ca, could you stick it somewhere else, or paste the most important line here please? | 15:18 |
| philn | http://pastebin.ubuntu.com/30298/ | 15:18 |
| james_w | thanks | 15:19 |
| james_w | philn: could you run "bzr info" please? | 15:19 |
| philn | Shared repository with trees (format: pack-0.92) | 15:20 |
| Peng_ | bzr-svn uses rich-root-pack. | 15:20 |
| philn | is there a troubleless way to convert my repo? | 15:21 |
| Peng_ | So, you need to bzr init-repo --rich-root-pack and branch into that. | 15:21 |
| Peng_ | philn: You shouldn't convert your entire repo. | 15:21 |
| philn | ok i'll start a new one then | 15:21 |
| Peng_ | Blah, my copy of bzr-svn is still pack-0.92-subtree. | 15:21 |
| Peng_ | philn: Just put bzr-svn in its own, rich-root-pack repo. | 15:21 |
| philn | kthx | 15:22 |
| philn | next one: http://pastebin.ubuntu.com/30303/ | 15:30 |
| pickscrape | Would a weekly cron job to bzr pack our server repositories be sensible? | 15:34 |
| spiv | Well, basically harmless :) | 15:34 |
| spiv | It might improve performance slightly and keep the autopacks a little bit smaller, I guess, but don't expect any dramatic changes. | 15:35 |
| spiv | But cron jobs are cheap, so why not... it won't hurt. | 15:35 |
| pickscrape | I wasn't looking to do it for improvements, mainly to prevent performance degradation. | 15:36 |
| spiv | Well, the autopacking that happens automatically should prevent most of the degradation. | 15:37 |
| pickscrape | Oh, I didn't know it happened automatically. Does that apply to remote repositories too? | 15:38 |
| spiv | Yeah, it does it silently. It does happen to remote repos too. | 15:40 |
| spiv | Which can sometimes be a bit slow, because it has to download the packs it will combine, then reupload the same data. | 15:41 |
| luks | even over bzr+ssh? | 15:41 |
| spiv | But autopacking is gradual, so even when it does kick in most of the time it doesn't need to rearrange much of the repo. | 15:42 |
| spiv | luks: currently, yes. I sent a hackish patch to the list a while back to do it smarter. | 15:42 |
| spiv | I hope to get back to that quite soon. | 15:42 |
| pickscrape | I suppose it won't hurt to set up that cron job then :) | 15:43 |
| luks | pickscrape: well, it will try to autopack regardless :) | 15:43 |
| luks | hm, actually maybe no, 'bzr pack' creates just one pack? | 15:44 |
| pickscrape | Yeah, but if there's less to do, that's less time for the user to hang around, which means less likely I'll be asked what's wrong :) | 15:44 |
| jelmer | re | 15:49 |
| jelmer | uws, that should be fixed in the 0.4 branch | 15:50 |
| jelmer | uws, will hopefully be released within the next two weeks (parallel with bzr 1.6) | 15:51 |
| Peng_ | pickscrape: Your cronjob will use more disk space. When packing is done, all of the old packs are moved to .bzr/repository/obsolete_packs. When an autopack is done, it's just a few of the most recent packs, so not much disk space is wasted. But when "bzr pack" is done, it's *all* packs, so it will almost double the size of .bzr/repository. | 15:52 |
| philn | jelmer: using trunk of bzr and bzr-svn i get this: http://pastebin.ubuntu.com/30306/ | 15:52 |
| Peng_ | pickscrape: (Err, by "old packs", I meant "packs that are deleted".) | 15:52 |
| pickscrape | Peng_: won't that maintain itself over time though? i.e. existing obsolete packs get removed when packing? | 15:53 |
| Peng_ | pickscrape: Oh, yes. | 15:53 |
| luks | pickscrape: replaced, not just removed | 15:53 |
| uws | jelmer: ok, great | 15:53 |
| pickscrape | I'm not overly concerned about that: the server isn't short on disk space. | 15:53 |
| Peng_ | pickscrape: Okay, then. I just wanted to warn you. | 15:53 |
| uws | jelmer: do you want a traceback to be sure? | 15:53 |
| pickscrape | Peng_: thanks :) | 15:53 |
| jelmer | uws, never hurts :-) can you privmsg one? | 15:54 |
| uws | jelmer: sure | 15:54 |
| jelmer | philn, hi | 15:54 |
| jelmer | philn, what's the repository format you're trying to branch into? | 15:55 |
| philn | jelmer: i think my installed bzr could be conflicting with the uninstalled bzr trunk i (try to) use | 15:56 |
| jelmer | philn, looks like this is a regression in bzr.dev | 15:56 |
| pickscrape | Does the bzr unit test infrastructure extend to plugins? | 16:00 |
| philn | jelmer: i'm removing my installed bzr | 16:00 |
| Peng_ | pickscrape: Yes. | 16:00 |
| Peng_ | (Well, I think.) | 16:00 |
| jelmer | philn, I'm filing a bug | 16:01 |
| jelmer | pickscrape, yeah | 16:01 |
| pickscrape | How do you tell it to just run the tests in a given plugin? | 16:01 |
| philn | jelmer: ok i get same error :/ | 16:02 |
| jelmer | philn, where did you revert to? | 16:02 |
| jelmer | pickscrape, bzr selftest --starting-with=bzrlib.plugins.PLUGINNAME | 16:02 |
| philn | jelmer: i removed my installed bzr pkgs (installed via the ppa) | 16:03 |
| pickscrape | jelmer: Ah, I'd suspected that, but wondered if there was a more direct method. Thanks, I'll have a play :) | 16:03 |
| jelmer | philn: what version of bzr are you using then? | 16:05 |
| philn | jelmer: trunk | 16:08 |
| jelmer | philn, that's pretty much the same as 1.6b4 atm I think | 16:09 |
| jelmer | philn, you'll need an older revision on bzr.dev from before poolie's stacking fixes landed | 16:13 |
| === abentley1 is now known as abentley | ||
| === orospakr` is now known as orospakr | ||
| === mw is now known as mw|food | ||
| cr3 | when I try to branch a private project from LP, I get: bzr: ERROR: Not a branch: "https://code.launchpad.net/". | 20:15 |
| Peng_ | cr3: It's not. | 20:16 |
| Peng_ | cr3: Use the lp: URL. | 20:16 |
| cr3 | Peng_: I did use the lp: url, but that's the error it prints :) | 20:16 |
| Peng_ | Which bzr version, and which exact command did you run? | 20:16 |
| cr3 | Peng_: Bazaar (bzr) 1.3.1 and: bzr branch lp:~hardware-certification/hwtest-certify/trunk | 20:17 |
| Peng_ | I get 'Not a branch: "bzr+ssh://<my username>@bazaar.launchpad.net/~hardware-certification/hwtest-certify/trunk/"' | 20:18 |
| Peng_ | https://code.launchpad.net/~hardware-certification doesn't list any such branch. | 20:20 |
| Peng_ | OTOH, when I try to visit hwtest-certify, I get a 403 Forbidden, so I might just not be allowed to see it. | 20:20 |
| Peng_ | cr3: Have you run 'bzr launchpad-login your_username' | 20:20 |
| Peng_ | ? | 20:20 |
| cr3 | Peng_: that worked, but the error message is not obvious | 20:21 |
| Peng_ | Indeed. | 20:22 |
| Odd_Bloke | cr3: File a bug please. :) | 20:22 |
| beuno | Peng_, lp:~beuno/loggerhead/new_theme | 20:24 |
| Peng_ | beuno: Hmm. | 20:25 |
| beuno | no | 20:25 |
| beuno | wait | 20:25 |
| cr3 | Odd_Bloke: reported bug #251956 | 20:25 |
| ubottu | Launchpad bug 251956 in bzr "Unobvious error message before calling launchpad-login" [Undecided,New] https://launchpad.net/bugs/251956 | 20:25 |
| Peng_ | cr3: Some of the related error messages have been improved since 1.3.1, but branch-exists-but-is-private may just have never been thought of. | 20:25 |
| cr3 | there was already a bug when branching unexisting projects, this is for a private project | 20:25 |
| beuno | Peng_, pushing somewhere public now :) | 20:25 |
| Peng_ | beuno: Why the secrecy? | 20:26 |
| cr3 | Peng_: makes sense, private projects are not common under Launchpad | 20:26 |
| * Peng_ feels left out. | 20:26 | |
| beuno | Peng_, not me call :) | 20:26 |
| Peng_ | beuno: Does it work with bzr.dev? | 20:27 |
| beuno | Peng_, yeap | 20:27 |
| Peng_ | OK. Just wanted to check. | 20:27 |
| beuno | Peng_, https://code.edge.launchpad.net/~beuno/loggerhead/new_theme_trunk | 20:27 |
| Peng_ | Can you just make the other branch public? | 20:28 |
| beuno | Peng_, the ther branch is uninterestingly different | 20:28 |
| Peng_ | Any URLs changed? | 20:28 |
| beuno | nope, it's trunk with a new theme | 20:28 |
| beuno | Jc2k, you may me interested in ^ | 20:29 |
| * Peng_ is still curious what the other branch is. :P | 20:29 | |
| beuno | although we should probably try to integrate it with the Gnome headeer | 20:30 |
| beuno | Peng_, same branch, different colors | 20:30 |
| beuno | I promise | 20:30 |
| Jc2k | beuno: :O | 20:31 |
| Peng_ | Augh! | 20:31 |
| beuno | Jc2k, take it for a spin, and, if youm like it, I'll try and have a gnome branch for that | 20:31 |
| beuno | mwhudson, it's out :) | 20:32 |
| Peng_ | After I changed all the files but before I restarted LH, I got a hit, and SimpleTAL decided to flood my log with errors. | 20:32 |
| Peng_ | Haha, it did it 9300 times. | 20:33 |
| beuno | nice round number | 20:34 |
| Peng_ | Also, because I was surpised by that, there were over 2.5 seconds of downtime while I restarted it, totally ruining my average. :( | 20:34 |
| Peng_ | Anyway, on-topic, the new theme works, and it seems pretty nice. | 20:36 |
| Peng_ | No more Bazaar and LH logos at the bottom? | 20:36 |
| beuno | ah, we should probably have those on there again, yes | 20:36 |
| Peng_ | Is performance different? | 20:37 |
| beuno | there are no major reasons for it to be different | 20:37 |
| beuno | probably less HTML | 20:37 |
| beuno | so it may improve a bit | 20:37 |
| beuno | the diffs are the biggest improvement for me | 20:38 |
| Peng_ | Honestly, I've never been a huge fan of having little icons everywhere, or smooth (un)collapsing. | 20:38 |
| beuno | can you still find everything? | 20:39 |
| Peng_ | I think so. | 20:39 |
| beuno | I've just proposed to merge this intro trunk, so if you find any blockers, let me know :) | 20:40 |
| Peng_ | Well, the missing Bazaar logo, obviously... :P | 20:40 |
| beuno | I'll add those on now | 20:41 |
| Peng_ | Everything seems okay, but I don't have a lot of experience using LH anyway. | 20:42 |
| beuno | Peng_, cool, thanks | 20:43 |
| beuno | once this lands, I can focus on features again | 20:43 |
| Peng_ | Hmm, I want to compare performance with one of the slower pages. | 20:44 |
| === mw|food is now known as mw | ||
| Jc2k | beuno: don't suppose there is one running i can peek at? | 20:46 |
| beuno | Jc2k, maybe Peng_ can let you peak at his? | 20:46 |
| beuno | if not, I'll try and run locally | 20:47 |
| * Jc2k hopes no one ever reads that sentence stand alone.... | 20:47 | |
| Jc2k | xD | 20:47 |
| Peng_ | Woah: Rendering RevisionUI: 141.52576088905334 secs, 96439309 bytes, 42448684 (44.0%) bytes saved | 20:47 |
| Peng_ | Jc2k: http://bzr.mattnordhoff.com/loggerhead/imports/lighttpd/lighttpd-1.4.x/changes | 20:47 |
| Jc2k | tasty | 20:48 |
| Peng_ | Am I misreading, or was that 40 MB of whitespace? | 20:48 |
| Jc2k | beuno: that is very much WIN WIN WIN | 20:49 |
| beuno | Peng_, is that faster or slower then before? | 20:49 |
| beuno | Jc2k, so I should go ahead and do a gnome version of that? | 20:49 |
| Jc2k | indeed =) | 20:50 |
| Peng_ | beuno: I don't know; I was just grepping my logs for slow pages. | 20:50 |
| Peng_ | beuno: I'm testing a smaller on right now. | 20:50 |
| Peng_ | one* | 20:50 |
| Peng_ | Not hugely scientific though. | 20:50 |
| Peng_ | Err, oops. It wasn't a very large page; it was just generating the annotate information that was slow. Anyway, the old one was 2.3 seconds, and the new one 1.3, and the sizes were 800k vs. 600k, I think. | 20:52 |
| beuno | :) | 20:53 |
| beuno | mwhudson, ^ | 20:53 |
| Peng_ | Generating the annotate information was slightly faster too, oddly. | 20:53 |
| Peng_ | (13 seconds vs. 14-15.) | 20:54 |
| Peng_ | Actually, 13.0 vs. 14.9, I think | 20:54 |
| Peng_ | I'm afraid to try to render that 90 MB page. | 20:54 |
| beuno | heh, I would too | 20:55 |
| Peng_ | OTOH, I've been known to be stupid. Hold on. | 20:56 |
| Peng_ | I mean, it managed to render before. | 20:56 |
| Peng_ | So far, it's using 44.7% of my VPS's RAM. | 20:57 |
| Peng_ | Seemed to peak there. | 20:57 |
| Peng_ | beuno: Dude, another page just tracebacked. | 20:58 |
| beuno | Peng_, hmmmm, what traceback? | 20:58 |
| Peng_ | beuno: Here's what I could get of it: http://paste.pocoo.org/show/80322/ | 20:59 |
| beuno | hrmm... | 21:00 |
| jelmer | hi beuno, Peng | 21:00 |
| beuno | hey jelmer | 21:00 |
| jelmer | beuno, Any news on the Debian upload of bzr-upload? | 21:01 |
| Peng_ | Argh. | 21:01 |
| beuno | jelmer, no, sorry. Can you get it sponsored by someone else? | 21:01 |
| jelmer | beuno, I'll ask around | 21:02 |
| Peng_ | It may have been the really gigantic page. | 21:02 |
| jelmer | beuno, the number of DD's around here seems to've decreased :-( | 21:02 |
| beuno | Peng_, is it a public branch? | 21:02 |
| beuno | jelmer, yeah, and my favorate DD is procrastinating more than usual | 21:02 |
| Peng_ | Hmm. | 21:03 |
| Peng_ | For that really gigantic page, it took close to 4 minutes, and only downloaded 1.5 MB. So I guess it's the one that died. | 21:03 |
| Peng_ | beuno: Yeah. Googlebot has been indexing one of my trivial bzr branches. | 21:03 |
| Peng_ | Interesting, this time it downloaded that much after 30 seconds. | 21:04 |
| Peng_ | ...And I see that traceback again. So I guess it is that page. | 21:04 |
| Peng_ | Confirmed, it's this page: http://bzr.mattnordhoff.com/loggerhead/bzr/configobj-4.5.2/revision/1551.19.24?start_revid=aaron.bentley%40utoronto.ca-20071221022516-hd721fevdx6o7h8i&remember=1551.6.25&compare_revid=1551.6.25 | 21:05 |
| Peng_ | beuno: ^ | 21:06 |
| Peng_ | Hold on, I'm gonna revert to the old theme. | 21:07 |
| beuno | Peng_, it renders fine, but gives you the traceback? | 21:07 |
| Peng_ | I dunno. | 21:08 |
| Peng_ | I thought that was the page that used to be 90 MB. | 21:08 |
| Peng_ | Switching to the old theme, it downloaded 51 MB (which is the size of the page after trimming whitespace). | 21:11 |
| Peng_ | So yes, the new theme is doing something wrong. | 21:11 |
| Peng_ | And there's no way in hell I'm gonna try to visit either of them in my browser. :P | 21:12 |
| Peng_ | Switched to the new theme again. | 21:14 |
| beuno | ok, so the new theme is generating 90mb against 50mb for the old one? | 21:15 |
| Peng_ | No, the old theme generated 90 MB, which the whitespace stripper reduced to 50 MB. The new theme generates 1.5 MB and a traceback. | 21:15 |
| beuno | ah, I see | 21:16 |
| beuno | the new theme will generate smaller pages, that's for sure | 21:16 |
| beuno | it doesn't do a lot of stupid things, and, it doesn't generate the diffs twice | 21:16 |
| beuno | now, we need to fix that traceback... | 21:16 |
| beuno | Peng_, can I can grab that branch from somehere? | 21:17 |
| Peng_ | (Note: I'm running the old theme again, so don't try to visit that URL...) | 21:17 |
| Peng_ | beuno: http://bzr.mattnordhoff.com/bzr/bzr/configobj-4.5.2/ -- it was merged with bzr.dev months ago, so bzr.dev would probably work too. | 21:17 |
| beuno | Peng_, cool. I'll try revid aaron.bentley%40utoronto.ca-20071221022516-hd721fevdx6o7h8i | 21:18 |
| beuno | Peng_, revid aaron.bentley%40utoronto.ca-20071221022516-hd721fevdx6o7h8i doesn't give me a traceback | 21:20 |
| beuno | and it's 56k | 21:20 |
| Peng_ | (OK, I can confirm those are the same revisions in bzr.dev.) | 21:21 |
| Peng_ | What does compare_revid do? Those two revisions are 1.5 years apart, so they're vastly different... | 21:21 |
| beuno | Peng_, diff between the two revids | 21:22 |
| Peng_ | So It's doing an 18-month diff. No wonder it's slow. | 21:22 |
| beuno | ok | 21:22 |
| beuno | I found the traceback comparing :) | 21:23 |
| beuno | yes, it's probably not the best of the ideas | 21:23 |
| Peng_ | Heheh. | 21:23 |
| Peng_ | Poor Googlebot. | 21:23 |
| Peng_ | I should block it from doing arbitrary diffs. | 21:24 |
| beuno | right, once it get remember= on the URL | 21:24 |
| beuno | it'll take it with him through the whole branch | 21:24 |
| beuno | not so smart of us | 21:24 |
| Peng_ | Think I should block remember= then? | 21:25 |
| beuno | yeap | 21:25 |
| Peng_ | Or just compare_revid? | 21:25 |
| beuno | remember | 21:25 |
| beuno | there is no reason for Google to use remember | 21:25 |
| Peng_ | Without checking myself, what does compare_revid do on annotate? | 21:29 |
| beuno | I have no idea :) | 21:29 |
| Peng_ | It looks like compare_revid has been used on annotate, atom, changes, files, and revision. | 21:31 |
| Peng_ | Does LH sometimes just append the current URL's query string to all links? | 21:31 |
| beuno | no, it's a bit less stupid about that | 21:33 |
| beuno | not terribly smart yet though | 21:33 |
| Peng_ | 'remember' has been used on annotate, atom, changes, download, files, and revision. | 21:34 |
| beuno | we want to get of remember all together | 21:36 |
| Peng_ | BTW, would filter_file_id ever be useful to Googlebot? | 21:36 |
| beuno | it's the changes that have been amde to that specific file | 21:36 |
| beuno | so probably | 21:36 |
| Peng_ | I already disallowed it on most pages, just not sure if it was all of them. | 21:40 |
| Peng_ | Oh, I didn't disallow it on atom. | 21:41 |
| Peng_ | I did on annotate, changes, files, and revision. | 21:42 |
| jelmer | hi colbrac | 21:52 |
| colbrac | hi | 21:52 |
| colbrac | I'm checking the tick patch.. | 21:52 |
| colbrac | since I don't know how to test I'll leave it at eyeballing | 21:52 |
| beuno | Peng_, you'll have to terach me some day to debug how you do :) | 21:53 |
| colbrac | jelmer: Only the ProgressPanel gets the tick()? | 21:53 |
| jelmer | colbrac, what else should have it? | 21:54 |
| colbrac | jelmer: The ProgressBarWindow? | 21:54 |
| Peng_ | beuno: Have you figured it out? | 21:54 |
| colbrac | (I don't know exactly what a tick() does.. :P) | 21:55 |
| beuno | Peng_, not yet, no. It's the content of the diff of some bzr change in the last 18 months :) | 21:55 |
| colbrac | jelmer: And why give ProgressPanel all that *args **kwargs when GtkProgressBar.tick takes no input? (def tick(self)) | 21:57 |
| jelmer | colbrac, allows us to not worry about it when GtkProgressBar.tick takes args in the future | 21:58 |
| colbrac | jelmer: ok makes sense. :).. but what about the ProgressWindow? | 21:58 |
| jelmer | colbrac, I didn't hit this problem with ProgressWindow yet but it does indeed make sense to add tick there as well | 21:59 |
| colbrac | ok I'll tweak you then :) | 21:59 |
| colbrac | done | 22:00 |
| jelmer | thanks | 22:00 |
| jelmer | beuno, what's the right address to send loggerhead merge requests to? | 22:00 |
| colbrac | so.. how to test the seahorse patch? killall seahorse? | 22:00 |
| beuno | Peng_, fixed, I'll push now. It's 14mb with the new theme :) | 22:00 |
| Peng_ | beuno: Oh, great. What was the issue? | 22:00 |
| beuno | jelmer, you can either sent it to the bzr list, or file a merge request to a branch through LP | 22:00 |
| beuno | Peng_, the way I mangle strings now to be able to but them into nice little pieces to fit the screen | 22:01 |
| Peng_ | beuno: Err, what? | 22:02 |
| Peng_ | beuno: That size reduction is *really* great. :) | 22:02 |
| beuno | Peng_, itgoes down from 114sec to 51 for me | 22:02 |
| beuno | Peng_, if you see at the diffs now, they all fit on screen, instead of going way outside of it | 22:03 |
| Peng_ | Oh, line wrapping? | 22:03 |
| beuno | that makes it sound less magical, but yes | 22:03 |
| lifeless | ROTFL | 22:04 |
| Peng_ | Heheh. | 22:04 |
| lifeless | several weeks of work reduced to 'Oh, line wrapping?' | 22:04 |
| Peng_ | Haha, sorry. :P | 22:04 |
| beuno | exactly :) I was thinking about inventing a new term for it, but it seems I lack marketing skills | 22:05 |
| Peng_ | Pushed yet? | 22:05 |
| colbrac | jelmer: How is seahorse used? Only in bzr sign-my-commits? | 22:05 |
| beuno | Peng_, no, triple checking I didn't break something else | 22:05 |
| jelmer | colbrac, to display revision signatures in viz | 22:05 |
| colbrac | ok.. | 22:06 |
| colbrac | on a separate matter.. when I did 'bzr sign-my-commits' mentioning of all 56 commits of mine in trunk flashed by with a nice 'need passphrase to unlock key' message.. and afterwards bzr declares my commits signed :S | 22:07 |
| beuno | Peng_, pushed | 22:07 |
| beuno | jelmer, thanks for the patch, I'll apply it now | 22:07 |
| beuno | hopefuly, that means you'll package LH once we release 1.6 :) | 22:08 |
| jelmer | I've already packaged it | 22:08 |
| Peng_ | Hm. | 22:08 |
| beuno | jelmer, cool! do you have an ITP on it yet? | 22:08 |
| jelmer | I'm waiting for the other packages I have pending to be sponsored first though | 22:08 |
| Peng_ | beuno: I still don't see antyhing to pull. lp:~beuno/loggerhead/new_theme_trunk, right? | 22:09 |
| beuno | Peng_, argh, sorry, stupid 2 locations for everything | 22:11 |
| jelmer | beuno, new_theme looks much better... | 22:11 |
| beuno | jelmer, :) | 22:12 |
| Peng_ | beuno: OK, pulled | 22:12 |
| colbrac | jelmer: I approved the seahorse patch. bzr vis nicely starts seahorse-daemon when I kill it beforehand. | 22:14 |
| colbrac | jelmer: But now I have the issue that I signed all my commits on trunk.. with the main ID of my key instead of the launchpad/bzr-gtk ID | 22:15 |
| beuno | Jc2k, if Peng_ can't break anything in the next 10 minutes, I'll try and port the gnome theme to it | 22:15 |
| colbrac | jelmer: at least.. all broken seals :/ | 22:15 |
| beuno | Peng_, the new theme seems to use less memory for me in general (probably due to generating smaller files) | 22:16 |
| Peng_ | Haha. I do manage to break things a lot, don't I? | 22:18 |
| Odd_Bloke | Users, who needs 'em? :p | 22:18 |
| Peng_ | beuno: The massive diff page took 2:20.95. Rendering RevisionUI: 130.14956402778625 secs, 81780815 bytes, 44947311 (55.0%) bytes saved. | 22:19 |
| Peng_ | That's great; my last record for whitespace savings was 46%. | 22:19 |
| Peng_ | beuno: That's...35 MB downloaded, vs 51. | 22:19 |
| beuno | cool, because that can (and will) be reduces quite a lot soon | 22:20 |
| jam | Peng_: of course, if you put mod_gzip in front of that like a good boy, it wouldn't really matter | 22:20 |
| beuno | I have evil plans to drop sqlite cache, and other ajax bling | 22:20 |
| Peng_ | jam: Yeah. I'm running Lighttpd 1.4, which doesn't support compressing dynamic content. 1.5 does. | 22:21 |
| Peng_ | I have 1.5 running; maybe I should have my main 1.4 proxy to it, then have it proxy to LH. | 22:21 |
| beuno | Peng_, how's memory usage? | 22:22 |
| Peng_ | beuno: Seems about the same | 22:22 |
| Peng_ | But I've also received a few other requests, of course. | 22:23 |
| Peng_ | It might be 6 MB lower. | 22:23 |
| beuno | not significant | 22:23 |
| * Peng_ restarts LH to save RAM. | 22:24 | |
| colbrac | jelmer: Can you probe subkeys in seahorse.py line 239? | 22:26 |
| jonnydee | Hi :) | 22:30 |
| jonnydee | I'm just playing around with Bazaar and stumbled over a question... | 22:31 |
| jonnydee | What happens when I create a shared repository within a shared repository? | 22:32 |
| jonnydee | Bazaar seems not to complain | 22:32 |
| radix | jonnydee: the innermost one will be used for any operation | 22:33 |
| radix | or "nearest" | 22:33 |
| jonnydee | aahh... ok I see | 22:33 |
| jonnydee | And are there scenarios where creating such nested repositories makes sence? or is this approach not a recommended one | 22:34 |
| jonnydee | btw thanks for you quick answer :) | 22:35 |
| NfNitLoop | jonnydee: The only problem I know of is that the outer repository doesn't really know anything about the inner one. | 22:35 |
| jonnydee | ok, I got it :) | 22:36 |
| NfNitLoop | So if you ever need to check out a previous state of your project... | 22:36 |
| NfNitLoop | you'd have to roll back each separately. | 22:36 |
| jonnydee | I understand now...thanks :) | 22:37 |
| jonnydee | But just another short question: | 22:38 |
| jelmer | re | 22:38 |
| jonnydee | In http://bazaar-vcs.org/SharedRepositoryLayouts there is mentioned a concept "container directory" | 22:38 |
| jonnydee | used in shared repositories without trees | 22:39 |
| jelmer | colbrac, I don't have a line 239 in seahorse.py | 22:39 |
| jonnydee | is it just a normal directory? I mean without a .bzr subdirectory? | 22:39 |
| colbrac | jelmer: Doh.. revisionview.py I mean | 22:39 |
| NfNitLoop | jonnydee: the "container directory" on that page refers to an SVN repository. | 22:40 |
| radix | NfNitLoop: wait, what? what do you mean rolling back each separately? | 22:40 |
| colbrac | where you look up the key.get_display_name() | 22:40 |
| radix | if you're using an inner repository, an outer one isn't touched at all; they're completely separate | 22:40 |
| NfNitLoop | radix: right.... | 22:40 |
| NfNitLoop | radix: I just mean they're not in sync with each other. | 22:40 |
| NfNitLoop | radix: you can't just say "I know this was working X revisions ago, let me get that...." | 22:41 |
| radix | why not? | 22:41 |
| NfNitLoop | because your inner repositories may have changed too. | 22:41 |
| jonnydee | Yes I understand, but there is a section "So the preferred way for Bazar would be:" | 22:41 |
| radix | hold on a second | 22:41 |
| jelmer | colbrac: I guess we could add a "has_uid()" function rather than using get_display_name() | 22:41 |
| radix | NfNitLoop: I think you may be confusing repositories and branches | 22:41 |
| radix | I'm pretty sure jonnydee is talking about shared repositories, not nesting branches themselves | 22:41 |
| NfNitLoop | radix: I think I'm just misusing the terms, but I know the difference. | 22:41 |
| jonnydee | And this section shows a layout with "A container directory" | 22:41 |
| NfNitLoop | radix: he's actually talking about both. | 22:42 |
| NfNitLoop | radix: in separate questions. | 22:42 |
| colbrac | jelmer: Yes please :) | 22:42 |
| jelmer | colbrac, any chance you can file a bug? I don't have time to look at the moment but it'd be nice if it wouldn't be forgotten | 22:42 |
| NfNitLoop | jonnydee: aah. Yes, there "branches" is just a normal directory. | 22:43 |
| beuno | Jc2k, https://code.edge.launchpad.net/~beuno/loggerhead/new_theme_gnome | 22:43 |
| jonnydee | right NfNitLoop - it was a separate question -- i'm sorry for any confusions | 22:43 |
| colbrac | jelmer: Will do | 22:43 |
| NfNitLoop | jonnydee: bzr will keep going up a directory (..) till it finds one containing .bzr and it will use that as the shared dir. | 22:43 |
| NfNitLoop | jonnydee: so you can structure your branches however you like. | 22:43 |
| jonnydee | thanks NfNitLoop -- that's exactly the information I need :) | 22:44 |
| NfNitLoop | personally, I just have project/, which contains trunk/, branch1/, branch2/, etc. | 22:44 |
| NfNitLoop | I don't see a need to separate everything out that is not trunk. | 22:44 |
| jonnydee | I just have one another question regarding repository layout... | 22:44 |
| NfNitLoop | My directory structures are already deep enough, thanks. ;) | 22:44 |
| NfNitLoop | jonnydee: ask away. | 22:45 |
| jonnydee | Can a shared repository also act as a branch? One of the listed repository layouts seems to suggest this... | 22:46 |
| jonnydee | project/ # The overall repository, *and* the project's mainline branch | 22:46 |
| NfNitLoop | ermmm.... | 22:46 |
| Peng_ | jonnydee: Yes, but that's really weird and yucky. | 22:47 |
| NfNitLoop | Yeah. If it can, I wouldn't. | 22:47 |
| jonnydee | (But I do also prefer listing the mainline as trunk anyway) | 22:47 |
| NfNitLoop | Probably don't want to mix your working tree and your branches. would get confusing fast. | 22:47 |
| jonnydee | Yes that's really weired.. | 22:47 |
| beuno | lifeless, are you running LH trunk on squid? | 22:47 |
| beuno | looks like you're not | 22:48 |
| jonnydee | I just was surprised bazaar can handle such a situation. I tried it out and it seems to work... But anyway, it's really confusing... so I will not use this feature | 22:49 |
| jonnydee | Thanks a lot for your help :) | 22:49 |
| colbrac | jelmer: 251992 | 22:49 |
| jelmer | colbrac, thanks | 22:49 |
| jonnydee | Have a nice day / night ;) | 22:51 |
| tsculpt | jonnydee: How did you get a shared repo to act like a branch? | 22:53 |
| jonnydee | I did: | 22:53 |
| jonnydee | bzr init-repo project | 22:54 |
| jonnydee | cd project | 22:54 |
| jonnydee | bzr init | 22:54 |
| NfNitLoop | *shudder* | 22:54 |
| jonnydee | I wanted to reproduce the mentioned scenarion from the tutorial so I tried this and played around a bit and it seems to work... | 22:56 |
| tsculpt | so you init'd it a second time like you would an empty branch | 22:56 |
| Peng_ | Sure, it works, it's just awful. | 22:56 |
| jonnydee | but ... yes *shudder* | 22:56 |
| tsculpt | yuk | 22:56 |
| tsculpt | it still acts like a shared repo too? | 22:57 |
| jonnydee | @tsculpt: yes i did | 22:57 |
| LarstiQ | why not? just colocation | 22:57 |
| jonnydee | yes it seems to act as a shared repo | 22:57 |
| jonnydee | I looked at the size of the .bzr directory after i added some files to a branch within that shared repo | 22:58 |
| tsculpt | so you could merge a whole collection of branches at once? | 22:58 |
| NfNitLoop | tsculpt: no... | 22:58 |
| jonnydee | that's a goog question.... but I don't think this is possible | 22:58 |
| NfNitLoop | the root is still only one branch. | 22:58 |
| NfNitLoop | but it is also a shared repo. | 22:59 |
| tsculpt | ah | 22:59 |
| tsculpt | well, I'm new at this, but like it a heck of a lot better than svn | 23:00 |
| NfNitLoop | tsculpt: Yep. Doesn't it make you wonder why anyone still uses anything else? :p | 23:00 |
| jonnydee | the same accounts to me -- I wish I could convince my company to use Bazaar instead of svn | 23:00 |
| NfNitLoop | jonnydee: well, bzr has a way to go to catch up to all of the tools offered that are compatible with svn. | 23:01 |
| jonnydee | well, I'm still trying... | 23:01 |
| NfNitLoop | Hell, we still use CVS because our ancient software speaks CVS. >.< | 23:01 |
| jonnydee | ok, that's a good point NfNitLoop -- so I should be happy with our current situation | 23:02 |
| NfNitLoop | jonnydee: yeah, at least with SVN you can use bzr-svn for your own work. : ) | 23:02 |
| jonnydee | I tried to use bzr-svn to talk with our svn repo, but it screwed up the repo | 23:02 |
| jelmer | jonnydee, in what way? | 23:03 |
| tsculpt | I really like the idea of using task branches like crazy, seen the merges are so easy | 23:03 |
| jonnydee | however, I think there was a problem with wrong versions of svn, bzr and bzr-svn... | 23:03 |
| NfNitLoop | jonnydee: it messed up the svn repository? I haven't seen that.... | 23:04 |
| jelmer | jonnydee, Inconsiste versions may cause a traceback but shouldn't ever cause corruption in your repo | 23:04 |
| jonnydee | when I pushed my changes to the svn repo bzr exited with an error (sorry, can't remember the message) | 23:04 |
| jonnydee | but after that I think/guess there was a hanging transaction within svn | 23:05 |
| tsculpt | How do you backup your repos? With svn being centralized, I used a post commit hook that did incremental dumps, and I just collected those to be replayed in case the repo was lost. | 23:06 |
| lifeless | beuno: not yet | 23:06 |
| NfNitLoop | tsculpt: just "branch" or "push" your repo to another location. | 23:07 |
| tsculpt | I imagin with a distributed system you could forgo that, and just push to a backup repo | 23:07 |
| tsculpt | yeah | 23:07 |
| jelmer | jonnydee: in the bzr or svn branch? | 23:07 |
| jonnydee | the log history of svn showed only some of my commit messages I submitted previously to my local bzr repo and their order got messed up | 23:07 |
| lifeless | beuno: waiting for a release | 23:07 |
| jelmer | jonnydee, was this with released versions of bzr, bzr-svn and svn? | 23:08 |
| beuno | lifeless, good, we should have one soon after 1.6 goes out the door. Just have 2 small remaining things to land | 23:08 |
| jonnydee | in the svn branch I there were some revisions missing... I couldn't even retriev them using command line | 23:08 |
| jelmer | jonnydee, bzr-svn will only push the mainline revisions in your branch, not the other revisions. Could that be it? | 23:09 |
| NfNitLoop | jelmer: what's the difference between "mainline revisions" and "other revisions" in a single branch? | 23:10 |
| NfNitLoop | it sounds like you're saying that things you merged in don't get pushed? | 23:10 |
| jonnydee | there was only one bzr branch -- with other words I did not branch my local branch | 23:10 |
| jelmer | NfNitLoop, yes, that's correct | 23:10 |
| NfNitLoop | ... !? | 23:10 |
| jelmer | NfNitLoop, It does store references to those revisions though | 23:10 |
| NfNitLoop | I'm curious as to why that is? | 23:11 |
| jelmer | NfNitLoop: where would those revisions have to be pushed? They can't be on /trunk since that would cause the diffs between new revisions to be very confusing | 23:11 |
| jelmer | it would also mess up the revision graph | 23:11 |
| NfNitLoop | being able to create branches from your bzr-svn repo, make changes, merge them back into your "trunk", and then push them to svn seems like a common use case? | 23:12 |
| jonnydee | anyway, I think there were incompatibilities: svn server was 1.4.x, my local svn client was 1.5, my bazaar client was 1.6beta2 (I think) and bzr-svn was the one for bzr 1.5 | 23:12 |
| jelmer | NfNitLoop, that works fine | 23:12 |
| NfNitLoop | jelmer: ah, then I'm misunderstanding the difference between the two types of changes. | 23:12 |
| tsculpt | Have you used svn-import to convert a svn repo to bzr? | 23:13 |
| jonnydee | Solution was to dump svn repo to the revision that existed just before I did the bzr push operation and create a new repository by importing that dump | 23:14 |
| NfNitLoop | tsculpt: yes, though it's been a while, I think I did branch? | 23:14 |
| jelmer | jonnydee: it would be nice if you can file a report about this if you can still reproduce it | 23:16 |
| jelmer | jonnydee, this would be the closest anybody has come to repo corruption using bzr-svn as far as I'm aware | 23:17 |
| jonnydee | when bzr 1.6 and the corresponding bzr-svn versions are out I will first upgrade the svn serve to 1.5, too, and then I will give it another try | 23:17 |
| jelmer | jonnydee, thans | 23:17 |
| jelmer | *thanks | 23:17 |
| lifeless | so jam will you be wowing? | 23:18 |
| tsculpt | So I am moving my workflow to use, bzr and I want to know what you think.. | 23:18 |
| jonnydee | @jelmer: I would like to reproduce it, but I had a lot work to do in order to recover from this event. By rolling back the svn repo I also messed up our CI-Platform... | 23:19 |
| jonnydee | Before I did the "push" I told my boss to try out the bzr-svn push. He asked me if it would be better to try it out on another temporary svn repo | 23:20 |
| tsculpt | I see using three shared repos, one without trees (on a usb flash drive). | 23:20 |
| jonnydee | And I said. Don't worry, you cannot screw up the svn repo by design... | 23:21 |
| tsculpt | With work performed at two locations, sans communication with one another, I just push to the flash drive repo in a centralized sense | 23:22 |
| tsculpt | and pull when arriving at the other location. | 23:22 |
| jelmer | jonnydee: Do you have a bdb or a fsfs repo? | 23:23 |
| jelmer | jonnydee: There are tools for the first to recover from a repo that's abandoned halfway (since that happens if the process that was accessing it dies) | 23:23 |
| tsculpt | So at any one time there are at least two copies of the shared repo distributed | 23:23 |
| jonnydee | fsfs -- And as AFAIK there cannot be hanging transactions... | 23:23 |
| tsculpt | then no dumps or anything like with svn, just three distributed repos. | 23:24 |
| jelmer | jonnydee, what was the error then though? | 23:24 |
| jonnydee | @jelmer: can you point me out to such a tool? is it part of the svnadmin suit? | 23:24 |
| jelmer | bzr-svn access subversion repositories through the standard Subversion API | 23:24 |
| jonnydee | @jelmer: I assumed exactly this | 23:25 |
| jonnydee | So I cannot understand why I had these problems... | 23:25 |
| jonnydee | But be assured, when I encounter this problem again I will do a bug report -- I promise. I should have done this right when I encounter this problem, but I was just shocked and tried to recover from that problem..... | 23:29 |
| NfNitLoop | jonnydee: well, and you were probably still in software-evaluation mode at that point. | 23:31 |
| NfNitLoop | not so much bug-reporting. | 23:31 |
| NfNitLoop | If I submitted bugs for every piece of software I tried out that didn't work as expected... | 23:31 |
| NfNitLoop | well, I wouldn't have time to IRC. :) | 23:31 |
| jonnydee | yes, that's in fact true... | 23:32 |
| jonnydee | But in case of Bazaar I will bug-report everything now, because I love this software. The more I use it, the more I like it!!! (And the more svn sucks... ;) ) | 23:34 |
| colbrac | jelmer: Please check your patches.. the olive - merge one has all the progress bar changes. And perhaps you can also add a set_icon_from_file(bazaar-64.png) while you are at it? (or something like that) | 23:34 |
| jelmer | colbrac, Sorry, I seemed to've uncommitted one revision too few before I sent it in | 23:35 |
| jelmer | colbrac: icon? How's that related to this? | 23:35 |
| colbrac | :) changes to merge dialog | 23:35 |
| colbrac | (hey.. I can try ;) ) | 23:35 |
| jelmer | :-) | 23:36 |
| jelmer | I think that's for a different commit.. | 23:36 |
| jonnydee | ok guys, thank you very very much for your interest and your help!!! I hope I can somehow give you some benefit back in the future... | 23:36 |
| jonnydee | See you :) | 23:36 |
| === mw is now known as mw|out | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
