| === Alien_Freak [n=sam@adsl-69-209-211-93.dsl.chcgil.ameritech.net] has joined #bzr | ||
| ubotu | New bug: #151731 in bzr "bzr merge puts entire ChangeLog from other branch into conflict, rather than just the diff cherry-picked" [Undecided,New] https://launchpad.net/bugs/151731 | 12:10 |
|---|---|---|
| === joejaxx [i=joejaxx@fluxbuntu/founder/joejaxx] has joined #bzr | ||
| james_w | Keybuk: I think that may be intended behaviour, I'm going to ask for clarification. | 12:25 |
| Keybuk | james_w: that implies that backporting a one line fix, with a minor conflict, can create a very very pessimal merge | 12:28 |
| james_w | Keybuk: yes, it does. | 12:28 |
| === danigm [n=danigm@82.159.240.59.static.user.ono.com] has left #bzr ["Saliendo"] | ||
| Keybuk | I find it hard to understand why this behaviour would be "intended" | 12:29 |
| === fog [n=fog@debian/developer/fog] has left #bzr [] | ||
| === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr | ||
| === cprov is now known as cprov-out | ||
| jeremyb | lastlog -clear | 12:52 |
| === igc [n=igc@ppp121-45-195-124.lns1.bne1.internode.on.net] has joined #bzr | ||
| igc | morning all | 01:11 |
| === acuster [n=acuster@29.Red-81-41-242.staticIP.rima-tde.net] has joined #bzr | ||
| acuster | aha, he's asleep. Sensible lad. | 01:16 |
| acuster | ciao | 01:16 |
| === acuster [n=acuster@29.Red-81-41-242.staticIP.rima-tde.net] has left #bzr ["bye"] | ||
| === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr | ||
| lifeless | something whack with my link apparently | 01:23 |
| lifeless | sorry I was offline.. | 01:23 |
| keir | lifeless, hey | 01:24 |
| lifeless | hi keir | 01:24 |
| keir | jam helped me add a bit to http://bazaar-vcs.org/DataStructures | 01:24 |
| keir | also, just to confirm: .iix is inventory index, and the two node refs are (history parent refs) then (delta parents)? and delta parents is empty if it's a fulltext? | 01:26 |
| keir | and same for .tix text indexes? | 01:26 |
| lifeless | yes | 01:27 |
| lifeless | I'd like to drop the history parent refs for .iix | 01:27 |
| jelmer | keir: revisions can contain custom properties as well | 01:27 |
| lifeless | it only really needs delta parents, but I have not had time yet | 01:27 |
| jelmer | keir: Never mind, missed the "at least" | 01:27 |
| keir | lifeless, great | 01:27 |
| lifeless | looks like it won't happen for this format I suspect, but who knows | 01:28 |
| keir | jelmer, yes, i realize that | 01:28 |
| keir | so in the new packs, the inventory is just a knit of a XML file? | 01:28 |
| keir | but stored in a pack file | 01:28 |
| === acuster [n=acuster@29.Red-81-41-242.staticIP.rima-tde.net] has joined #bzr | ||
| lifeless | packs haven't changed the way inventories are managed in the repository other than the same transform done to revisions, signatures and file content | 01:32 |
| keir | ok | 01:33 |
| lifeless | that is the index is changed from a .kndx to many .iix's | 01:33 |
| keir | right | 01:33 |
| keir | and one iix may have many inventories in it | 01:33 |
| acuster | Hey all, what's the difference between bzr svn-import and bzr branch (with bzr-svn installed and from an svn repo)? | 01:33 |
| lifeless | right, one for each inventory knit record in the associated .pack | 01:34 |
| lifeless | acuster: bzr svn-import may help out | 01:34 |
| jelmer | acuster: svn-import clones all branches in a repository, branch just one | 01:34 |
| acuster | oh. Hey jelmer. | 01:35 |
| acuster | I tried a bzr co and got a core dump :-) | 01:35 |
| lifeless | jelmer: packs have partial index reads now | 01:35 |
| lifeless | jelmer: I haven't analysed your callgrind yet though | 01:36 |
| jelmer | lifeless: cool - what does that mean though ? :-) | 01:36 |
| jelmer | acuster: on a public repository? | 01:36 |
| lifeless | jelmer: if you only need one file read, you don't parse all the index data now | 01:37 |
| jelmer | lifeless: faster incremental push/pull? | 01:37 |
| jelmer | ah, k | 01:37 |
| acuster | yeah. svn.geotools.org/geotools/trunk | 01:37 |
| jelmer | http:// .. ? | 01:37 |
| acuster | the same one that was giving me a weird state after a branch (had a Removed: section) | 01:37 |
| acuster | yeah | 01:38 |
| lifeless | abentley: around? feeling better? | 01:38 |
| acuster | I don't think it does svn:// but am asking | 01:38 |
| abentley | Yeah. | 01:38 |
| === eolo999 [n=eolo999@host-62-10-124-70.cust-adsl.tiscali.it] has joined #bzr | ||
| acuster | its an old version of subversion 1.1.4 | 01:40 |
| === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| eolo999 | hi, do you know how to branch with bzr+ssh on a non-default sshd port? | 01:40 |
| acuster | jelmer, actually, it looks like I tried to co into a blank directory (was not initialized as bzr). That gave: | 01:41 |
| eolo999 | I changed my default sshd port due to bot attacks and now i can't branch using bzr+ssh protocol | 01:41 |
| acuster | python: /build/buildd/subversion-1.4.3dfsg1/subversion/libsvn_subr/path.c:377: svn_path_basename: Assertion `is_canonical(path, len)' failed. | 01:42 |
| acuster | and dumped core (not sure of what) | 01:42 |
| jelmer | acuster, what version of bzr-svn are you running? | 01:42 |
| jelmer | acuster: what was the exact command you were running? | 01:42 |
| acuster | 0.4.2-1 | 01:42 |
| acuster | mkdir somedir | 01:43 |
| acuster | cd somedir | 01:43 |
| acuster | bzr co http://svn.geotools.org/geotools/trunk/ | 01:43 |
| acuster | and 0.90-1bazaar1 | 01:43 |
| jelmer | acuster: please try a more recent version | 01:44 |
| jelmer | acuster: 0.4.2-1 had some issues with http:// repositories | 01:44 |
| acuster | your latest conflicts with the latest I can get | 01:44 |
| acuster | that was the best I could do on feisty but perhaps there are packages elsewhere | 01:45 |
| eolo999 | bzr+ssh always try to connect on port 22 or i can change it? | 01:45 |
| acuster | aha | 01:45 |
| jelmer | acuster: the bazaar-vcs.org repository should have more recent packages | 01:45 |
| Odd_Bloke | eolo999: Have you tried 'bzr+ssh://<host>:<port>/...'? | 01:45 |
| jelmer | eolo999: bzr+ssh://host:port/... doesn't work? | 01:45 |
| eolo999 | tried... but i always mistype, go and check... | 01:46 |
| === eolo999 is checking | ||
| acuster | jelmer, later than your .debs? | 01:46 |
| eolo999 | i'm really sorry i wrote address.comi... as i told you: i ALWAYS mystype | 01:48 |
| jelmer | acuster: it has a more up-to-date version of the bzr package | 01:48 |
| jelmer | see http://bazaar-vcs.org/DistroDownloads | 01:48 |
| acuster | thank you | 01:49 |
| lifeless | abentley: so this merge base thing. | 01:49 |
| Odd_Bloke | eolo999: Heh, "mystype". ^_^ | 01:49 |
| abentley | Mmm? | 01:49 |
| lifeless | I think we're picking worse merge bases that we did in 0.17ish times | 01:50 |
| lifeless | IIRC you identified a problem with the current logic | 01:50 |
| lifeless | but my memory is hazy | 01:50 |
| lifeless | I mailed you a particular case that stood out for me, where it clearly took a history shortcut | 01:51 |
| abentley | My memory is hazy too. | 01:51 |
| lifeless | heh | 01:51 |
| lifeless | if you could look in your inbox, oh a week or so back | 01:51 |
| abentley | Okay. If you could run graph-ancestry on these things it would be helpful. | 01:53 |
| lifeless | sure thing | 01:53 |
| abentley | That's usually where I start. | 01:53 |
| lifeless | I don't know what your debug process is for this I guess | 01:53 |
| === lifeless digs around in sent mail | ||
| lifeless | oct 5th | 01:54 |
| lifeless | I'll just paste the revids here for my easy access | 01:54 |
| lifeless | robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv | 01:55 |
| lifeless | pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl | 01:55 |
| abentley | Heh, on my mail client, that's oct 4th. | 01:55 |
| lifeless | :) in the old world :) | 01:55 |
| eolo999 | thanks guys...bye | 01:56 |
| lifeless | bye | 01:56 |
| === eolo999 go to bed | ||
| abentley | lifeless: Has your revision been merged into mainline? | 01:57 |
| lifeless | no | 01:57 |
| abentley | Is it the packs branch? | 01:57 |
| lifeless | yup | 01:57 |
| lifeless | http://people.ubuntu.com/~robertc/baz2.0/repository | 01:57 |
| lifeless | I'll pull it to the knits version for you, one sec | 01:58 |
| abentley | Oh, I just stated a pull of the knits version. | 01:58 |
| lifeless | its just annotating the recent work, will be a few minutes | 01:58 |
| lifeless | hmm, it would be nice to show that in some senses | 01:59 |
| abentley | Like a progress indicator? | 01:59 |
| lifeless | yeah | 01:59 |
| lifeless | [== ] Pull phase 0/2 | 02:00 |
| lifeless | not enough info to understand why it is slow | 02:00 |
| keir | i remember way back in the day jam was working on a progress bar refactor | 02:01 |
| === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr | ||
| === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr | ||
| abentley | Well, when I really thought about it, it generalized to a "status" API. | 02:03 |
| abentley | Where status data about multiple operations could be transmitted, instead of this linear 0-1 scale. | 02:04 |
| === i386 [n=jdumay@202.47.1.18] has joined #bzr | ||
| lifeless | so jam-laptop what do you think you'll hack on now, between diapers that is | 02:06 |
| abentley | lifeless: I think the problem with the graph code was that if it hits a null revision it can stop before it discovers some comon ancestors. | 02:07 |
| lifeless | wow | 02:07 |
| lifeless | that png breaks display | 02:08 |
| === p4tux [n=p4tux@189.169.95.23] has joined #bzr | ||
| abentley | lifeless: You can set --max-distance to reduce the graph complexity. | 02:08 |
| lifeless | yah doing so now :) | 02:08 |
| abentley | I thought it was already defaulted, but maybe not. | 02:09 |
| === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr | ||
| poolie | good morning abentley, lifeless | 02:10 |
| abentley | Morning. | 02:10 |
| lifeless | abentley: if it is defaulted, its too big for me :) | 02:11 |
| lifeless | anyhow | 02:11 |
| lifeless | I did track the ancestry using log | 02:11 |
| lifeless | and it was definately a shortcut, as I mention in my mail | 02:11 |
| lifeless | the push is maybe 10% done? | 02:12 |
| lifeless | if you have a packs branch you can probably pull it directly more easily ;) | 02:12 |
| abentley | Well, what I want to know is do we have a bunch of LCAs. | 02:12 |
| abentley | My packs branch is quite out of date, I think | 02:12 |
| lifeless | okies | 02:13 |
| lifeless | >>> import bzrlib.repository | 02:13 |
| lifeless | >>> r = bzrlib.repository.Repository.open('..') | 02:13 |
| lifeless | >>> tips = ['robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv', 'pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl'] | 02:13 |
| lifeless | >>> g = r.get_graph() | 02:14 |
| lifeless | I'm all set to answer any questions :) | 02:14 |
| lifeless | >>> g.heads(tips) | 02:14 |
| lifeless | set(['pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl', 'robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv'] ) | 02:14 |
| abentley | sry. | 02:16 |
| === cbarrett [n=cbarrett@adium/cbarrett] has left #bzr [] | ||
| abentley | g.find_lca('pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl', 'robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv' ) | 02:18 |
| acuster | bzr co (using bzr-svn) should just get the last revision or is also building the same history as bzr branch? | 02:18 |
| lifeless | >>> g.find_lca(tips[0] , tips[1] ) | 02:18 |
| lifeless | set(['robertc@robertcollins.net-20071003061506-2hbze42e1sokni8j', 'robertc@robertcollins.net-20070827041949-br263tkuxayldxoc'] ) | 02:18 |
| abentley | acuster: By default, it will be fetching the branch history. You want that, unless you have very fast (LAN-speed) access to the server. | 02:19 |
| === pete__c [n=pete@032-437-364.area7.spcsdns.net] has joined #bzr | ||
| abentley | lifeless: Do you think that's an accurate result? | 02:19 |
| lifeless | does 'bzr find-merge-base' show the actual merge base used ? | 02:20 |
| abentley | lifeless: Yes, I updated it when I changed the graph code. | 02:20 |
| acuster | abentley, is that smaller than the stuff fetched for a 'bzr branch' or the same? | 02:20 |
| abentley | acuster: the same. | 02:21 |
| lifeless | robertc@robertcollins.net-20071004220007-6tb7pyeknkhpnfyq | 02:21 |
| jelmer | acuster: just the last revision is possible using 'bzr checkout --lightweight' | 02:21 |
| abentley | lifeless: I think maybe you're misunderstanding the question? | 02:21 |
| acuster | but I can't branch from the checkout right? checkouts are just dumb trees? | 02:21 |
| abentley | acuster: You can actually branch from a checkout. | 02:22 |
| lifeless | abentley: should the merge base it chose be one of the lca's ? | 02:22 |
| abentley | Even if it's just a dumb tree. | 02:22 |
| acuster | lol. so what is the difference? | 02:22 |
| lifeless | back shortly, need greasy food | 02:22 |
| acuster | jelmer, bzr 0.91-2 and 0.4.3 (in plugins/) doesn't crash | 02:22 |
| lifeless | abentley: ok, the conversion to knit data has completed | 02:22 |
| abentley | lifeless: no. If those really are the LCAs, the algorithm will find *their* lca. | 02:23 |
| jelmer | acuster: ok, cool | 02:23 |
| acuster | thanks for your help | 02:23 |
| abentley | acuster: A branch is an independent line of development. A checkout is a copy of the source tree, and when you commit in it, the results go into another branch. | 02:24 |
| abentley | lifeless: pulling | 02:24 |
| acuster | but you can branch from a checkout and checkout from a branch? Cool. I did not expect that kind of flexibility | 02:25 |
| lifeless | abentley: its likely that there are two valid lca's there - this branch merges from many | 02:25 |
| abentley | What does g.find_lca('robertc@robertcollins.net-20071003061506-2hbze42e1sokni8j', 'robertc@robertcollins.net-20070827041949-br263tkuxayldxoc') give you? | 02:28 |
| abentley | I ran it myself, and it gives 'pqm@pqm.ubuntu.com-20070823005013-ada9x55rc31yiwou', which is the value from your email. | 02:42 |
| abentley | So unless we're hitting a bug in the find_lca stage, the algorithm is behaving as intended. | 02:43 |
| lifeless | back | 02:45 |
| lifeless | ok | 02:45 |
| lifeless | I think the problem then is this recursive definition | 02:46 |
| lifeless | either of the first lca's is a reasonable base | 02:46 |
| lifeless | their common point is however much further back | 02:46 |
| acuster | okay, let's let the bzr branch run. Thanks all for your help. goodnight | 02:46 |
| abentley | lifeless: The problem is that neither one of them is a reasonable base. | 02:47 |
| lifeless | our old code would have picked one though ? | 02:47 |
| abentley | Yes. | 02:47 |
| lifeless | and as a user, our old code felt much nicer | 02:47 |
| abentley | Silently discarding differences in the other. | 02:47 |
| lifeless | huh? | 02:48 |
| abentley | Each side makes different merge resolutions. If you choose a too-recent merge base, one side's merge resolutions are silently discarded. | 02:50 |
| lifeless | if the base is merged into both sides, that's not the impact | 02:51 |
| abentley | Yes it is. | 02:51 |
| abentley | It's a damned-if-you-do, damned-if-you-don't situation. | 02:51 |
| lifeless | is there a mail/wiki/doc that lays this out? | 02:52 |
| abentley | Yeah. 1 sec. | 02:52 |
| abentley | http://article.gmane.org/gmane.comp.version-control.monotone.devel/3256 http://article.gmane.org/gmane.comp.version-control.monotone.devel/3264 | 02:54 |
| === jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr | ||
| lifeless | abentley: I see | 03:31 |
| lifeless | abentley: hmm I think | 03:31 |
| lifeless | abentley: so concretely, I've been dealing with the same conflicts when merging bzr.dev -> branch A -> B -> C -> packs | 03:33 |
| lifeless | and by the third and forth *repeated resolution* I'm entirely over them | 03:33 |
| abentley | So you've got four branches in flight? | 03:34 |
| lifeless | yah | 03:34 |
| lifeless | not right now, but earlier on when I had many patches outstanding | 03:34 |
| lifeless | earlier this week I had three | 03:34 |
| lifeless | bzr.dev, readv, index, repository | 03:34 |
| abentley | Well, as long as you're always merging in one direction, that shouldn't give criss-cross. | 03:34 |
| lifeless | well | 03:35 |
| lifeless | repository gets merges direct from bzr.dev | 03:35 |
| lifeless | I also get conflicts in the other direction | 03:35 |
| lifeless | when I merge bzr.dev to repository, after something from e.g. readv was merged to bzr.dev | 03:36 |
| lifeless | the reason repository gets merges from bzr.dev is that I only create these other branches when I realise I need to change some infrastructure | 03:36 |
| lifeless | so I then branch bzr.dev to e.g. readv | 03:36 |
| abentley | So I internalized Nathaniel's observations a long time ago. My solution was always "so don't do three-way". | 03:39 |
| abentley | I really do feel like there's no good option, so I picked the one that didn't lead to silently discarding changes. | 03:39 |
| === jamesh__ is now known as jamesh | ||
| lifeless | so the conceptual problem I have here | 03:41 |
| lifeless | is that a criss cross graph that doesn't have criss-cross changes should be safe | 03:42 |
| lifeless | we're getting conflicts because, to use NEWS as an example, | 03:43 |
| lifeless | one side actually has added a single new entry | 03:43 |
| === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr | ||
| === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| poolie | woot | 04:27 |
| poolie | one | 04:27 |
| poolie | less failure | 04:27 |
| === bigdo1 is now known as bigdog_ | ||
| lifeless | :) | 04:41 |
| === BasicMac [n=BasicOSX@warden.real-time.com] has joined #bzr | ||
| === BasicMac is now known as BasicOX | ||
| poolie | ok, i think the basis update is right, except it causes a somewhat obscure failure in test_rio_version | 04:58 |
| lifeless | cool | 05:10 |
| poolie | the problem is that with this change, the root directory is not given the right revision on a commit | 05:10 |
| lifeless | uhm | 05:18 |
| lifeless | there are tests for setting that I'm quite sure | 05:18 |
| lifeless | rephrasing, I think it should be settable via the update... method, so I'd look at the delta creation I guess | 05:19 |
| === abentle1 [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr | ||
| poolie | since the delta is the only thing i changed i guess that's where the problem is | 05:35 |
| poolie | however, there are no really direct tests for it, so i'm adding one | 05:35 |
| lifeless | hmm | 05:35 |
| lifeless | the delta returned by record_entry_contents ? | 05:35 |
| poolie | i'm just thinking out loud here, not necessarily trying to distract you, btw | 05:36 |
| lifeless | there are some direct tests for the deltas' returned by record_entry_contents, though there are several layers there involved in making the tests easy to write | 05:37 |
| lifeless | thats fine, its friday avo, I'm trivially distracted | 05:39 |
| lifeless | btw, Portal is *cool* | 05:39 |
| lifeless | finished it this morning before work :) | 05:39 |
| poolie | yep, i tried it briefly this morning :) | 05:39 |
| poolie | i'm trying to maintain self control | 05:39 |
| poolie | :) | 05:39 |
| lifeless | did you lookup your steam name? | 05:39 |
| poolie | yby30 | 05:39 |
| poolie | ok, so the RootCommitBuilder isn't giving back a delta for the root on the second commit | 05:50 |
| lifeless | thats right | 05:51 |
| lifeless | unless the root has changed | 05:51 |
| poolie | should it get a new revision on each commit, or not ? | 05:52 |
| poolie | some code seems to think that it should | 05:52 |
| === igc food | ||
| lifeless | it should get a new rev on knit1 repos, but not on knit3 | 06:01 |
| === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| === asak_ [n=alexis@201-1-4-222.dsl.telesp.net.br] has joined #bzr | ||
| poolie | so CommitBuilder.record_entry_contents should be saying the root has changed | 06:34 |
| poolie | but it does not | 06:34 |
| poolie | in fact it seems to leave the same revision id in there | 06:34 |
| poolie | so, it would seem that someone else is updating the root revision id at a later time | 06:35 |
| poolie | and, indeed there's a _check_root method that fudges it | 06:35 |
| === asak_ is now known as asak | ||
| lifeless | right | 06:38 |
| lifeless | thats how I've currently minimised the differences | 06:38 |
| === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr | ||
| === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr | ||
| ubotu | New bug: #151844 in bzr "bzr info (Windows)" [Undecided,New] https://launchpad.net/bugs/151844 | 07:05 |
| igc | lifeless, pollie: anything you want reviewed today by me? | 07:13 |
| igc | poolie: ^^ | 07:13 |
| igc | robert's bisection one looks the most important ... | 07:14 |
| igc | but I gather poolie is already working on that | 07:14 |
| poolie | i already posted some changes | 07:15 |
| igc | saw those | 07:15 |
| poolie | lifeless, ok, so the bug seems to be repository.py +296 | 07:17 |
| poolie | assuming that there's always no delta on the root | 07:17 |
| poolie | which is odd | 07:17 |
| lifeless | well | 07:23 |
| lifeless | I think its 'no delta should be shown as always delta' | 07:23 |
| lifeless | (for non RootCommitBuilder) | 07:23 |
| poolie | mm? | 07:33 |
| lifeless | wooties | 07:34 |
| lifeless | I have fine grained concurrency | 07:34 |
| poolie | ok, i think i've fixed it | 07:36 |
| poolie | the commit code could do with a good scrub | 07:36 |
| lifeless | heh, its been getting one | 07:36 |
| poolie | can you tell me what this line is doing, about 269 of repo.py: | 07:38 |
| poolie | if ie.revision is not None: | 07:39 |
| poolie | if self._versioned_root or path != '': | 07:39 |
| poolie | # not considered for commit | 07:39 |
| poolie | oh nm, i see | 07:39 |
| lifeless | this is something I hope to fix shortly, by not passing ie's into record_entry at all | 07:39 |
| lifeless | but what it is doign is carryign over unmodified entries | 07:39 |
| lifeless | (which the commit.py code signals by keeping the ie.revision attribute from the basis) | 07:40 |
| lifeless | and for non versioned roots this is fallacious | 07:40 |
| lifeless | ok | 07:40 |
| lifeless | igc: poolie: fine-grained-locking packs pushed | 07:41 |
| lifeless | bbiab | 07:41 |
| === i386 thinks Atlassian's fisheye should support bzr | ||
| lifeless | igc: yes | 08:08 |
| lifeless | meh | 08:08 |
| lifeless | i386: yes | 08:08 |
| i386 | we have git support internally | 08:09 |
| i386 | (sucks) | 08:09 |
| poolie | oh, you work there? | 08:09 |
| poolie | lifeless, can you please fix the permissions on /srv/www.bazaar-ng.org/rsync/bzr/bzr.dev/.bzr/checkout/dirstate | 08:15 |
| poolie | and the containing directories | 08:15 |
| lifeless | sure, whats wrong with them ? | 08:18 |
| poolie | they're owned by you and mode 0644 | 08:18 |
| poolie | this seems kinda selfish :) | 08:18 |
| lifeless | chmod g+x enough ? | 08:19 |
| poolie | g+wX would be better | 08:20 |
| poolie | because i want to update the wt | 08:20 |
| lifeless | .bzr$ chmod g+wX -R . | 08:20 |
| poolie | and check the group too i guess | 08:20 |
| lifeless | group is bazng | 08:20 |
| lifeless | theres files there jam owns too | 08:20 |
| lifeless | merge-hashes for instance | 08:20 |
| poolie | and also the wt please | 08:21 |
| poolie | hrm | 08:21 |
| lifeless | done, huge list of errors | 08:21 |
| poolie | but fortunately jam's files seems group-writable | 08:24 |
| poolie | you seem to have made some regular files g+x | 08:25 |
| lifeless | bzr revert ;) | 08:25 |
| poolie | won't fix the controlfiles | 08:25 |
| lifeless | oh, but we don't care about them do we? | 08:26 |
| poolie | i guess it's harmless | 08:27 |
| poolie | just wierd | 08:27 |
| poolie | weird | 08:27 |
| lifeless | wierd is weird | 08:27 |
| lifeless | :) | 08:27 |
| poolie | find .bzr -type f -perm +0111 -user $USER -exec chmod -x {} \; | 08:28 |
| === thumper-office is now known as thumper | ||
| igc | i386: I'm a big fan of JIRA and Confluence. bzr support in JIRA and FishEye would be sweet indeed. | 08:43 |
| lifeless | ok, one patch sent | 08:44 |
| lifeless | working on index patch cleanup now | 08:44 |
| === metze_asleep is now known as metze | ||
| i386 | igc: I think there is an issue on jira.atlassian.com for that | 08:53 |
| i386 | go vote on it :) | 08:53 |
| === mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr | ||
| poolie | lifeless, do you have a rule-of-thumb number for how long a basis_inv.iter_entries takes? | 08:55 |
| lifeless | uhm | 08:56 |
| lifeless | seconds? IIRC | 08:56 |
| lifeless | I saved 10 seconds at one point by removing one such loop, though it did stuff in the middle | 08:56 |
| lifeless | I haven't measured for entry in ..:pass | 08:57 |
| poolie | ok, update_etc patch sent | 09:14 |
| lifeless | wicked cool | 09:19 |
| lifeless | just finished the index changes from review, mailing now | 09:19 |
| lifeless | have a good weekend | 09:23 |
| lifeless | grab me on steam for games :) | 09:23 |
| === bialix [n=chatzill@77.109.23.189] has joined #bzr | ||
| === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr | ||
| === pbor [n=urk@host25-25-dynamic.60-82-r.retail.telecomitalia.it] has joined #bzr | ||
| === mvo [n=egon@p54A66DFB.dip.t-dialin.net] has joined #bzr | ||
| === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr | ||
| poolie | night all | 09:54 |
| igc | night poolie | 10:04 |
| igc | in fact, night all - have a good weekend | 10:04 |
| poolie | good night igc | 10:05 |
| === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr | ||
| === i386 [n=james@ppp239-169.static.internode.on.net] has joined #bzr | ||
| === g0ph3r [n=g0ph3r@p57A0B85A.dip0.t-ipconnect.de] has joined #bzr | ||
| === Starting logfile irclogs/bzr.log | ||
| === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #bzr | ||
| === Topic for #bzr: The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.91 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d | ||
| === Topic (#bzr): set by poolie at Wed Sep 26 07:07:44 2007 | ||
| === jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr | ||
| === jelmer_ is now known as jelmer | ||
| lifeless | mwhudson: hey | 12:06 |
| lifeless | mwhudson: please try packs again, indices are now partial-read enabled | 12:06 |
| mwhudson | lifeless: ok | 12:07 |
| mwhudson | probably not going to get to that today | 12:07 |
| sabdfl | lifeless: how goes the effort to land packs? | 12:12 |
| === danigm [n=danigm@82.159.240.59.static.user.ono.com] has joined #bzr | ||
| === Roua1 [n=Raidenn@dsl-240-35-129.telkomadsl.co.za] has joined #bzr | ||
| === Roua1 [n=Raidenn@dsl-240-35-129.telkomadsl.co.za] has left #bzr [] | ||
| === bialix [n=chatzill@77.109.23.189] has joined #bzr | ||
| bialix | hi | 01:29 |
| bialix | someone familiar with git here? | 01:29 |
| === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #bzr | ||
| === lightyear [n=lightyea@90.163.23.135] has joined #bzr | ||
| lightyear | hi there. | 01:38 |
| lightyear | I have a question about if it is possible with bazar or I should stop searching for the feature | 01:39 |
| lightyear | I have remote-server (webspace) without any ssh or shell acces and want to commit the latest changes to the working dir over there. | 01:39 |
| lightyear | as I can see push is only updating the .bzr and not the working dir | 01:39 |
| CardinalFang | lightyear, Do you have any way to send files, in general? FTP? HTTP put? | 01:40 |
| lightyear | do I have any possiblity to update the working copy remotely | 01:40 |
| lightyear | yep. Currently I do all with ftp | 01:40 |
| lightyear | and the syncing with push works in generally | 01:40 |
| lightyear | but the working copy is not updated. | 01:40 |
| lightyear | is there a way to do this, CardinalFang ? | 01:41 |
| dato | without shell access, I've never heard of a way | 01:41 |
| CardinalFang | lightyear, Well, I suppose you could send a snapshot of your checked-out tree also. Not with BZR, but with something else. | 01:42 |
| lightyear | the idea was, that I've only to commit the changes over ftp, because the connection is damn slow. | 01:42 |
| lightyear | so I've to copy that manually (doing release or the whole working-dir) outside of bazar. | 01:43 |
| CardinalFang | Yeah, I get it. On the remote server, though, unless you have a way to execute arbitrary commands, then there's no way to send only metainfo and have it explode into a snapshot. | 01:44 |
| lightyear | so bazar is not even theoritically able to do this? | 01:44 |
| CardinalFang | Nothing could, no. | 01:45 |
| lifeless | if you can do rsync | 01:45 |
| lightyear | can't | 01:45 |
| lifeless | then there is a plugin that will rwsync the specific files across | 01:46 |
| lightyear | so. wait there would be a way without command-executing on the serveR? | 01:46 |
| lightyear | but that can't be done over a ftp-connection because it is using the algo of rsync? | 01:47 |
| CardinalFang | Yeah, I think rsync requires "rsync"-the-program to run on the remote end. | 01:47 |
| lifeless | the problem with ftp is that its very hard to get full file system behaviour | 01:47 |
| lifeless | night all | 01:47 |
| CardinalFang | g'night. | 01:47 |
| === NamNguyen [n=NamNguye@cm38.delta196.maxonline.com.sg] has joined #bzr | ||
| lightyear | night, lifeless | 01:48 |
| lightyear | thanks for the help | 01:48 |
| lightyear | afaik rsync can work over ftp.... | 01:49 |
| lightyear | no. I need the deamon :( | 01:49 |
| CardinalFang | So, lightyear, if you can run programs on the far end, then your problem is solved. Else, you have to schlep all the bits. The far end is a dumb data-store. You get out only what you put in. | 01:50 |
| lightyear | okay. thank you CardinalFang | 01:51 |
| lightyear | so bazar is not able to read the archive of the remote and do a checkout there. that is what I wanted to know. | 01:51 |
| === hsn_ [n=chatzill@234.114.broadband5.iol.cz] has joined #bzr | ||
| CardinalFang | It could, but bazaar isn't there. It's here. | 01:52 |
| hsn_ | how python determines Codec for encoding charset on Windows? | 01:53 |
| === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr | ||
| hsn_ | it would be nice to have it displayed in bzr version | 01:53 |
| lightyear | CardinalFang, would it be possible, if I write a plugin for it? | 01:54 |
| === lightyear is able to write python code and is very interested in that kind of a feature | ||
| === danigm [n=danigm@82.159.240.59.static.user.ono.com] has left #bzr ["Saliendo"] | ||
| bialix | lightyear: it's possible to write plugin | 01:57 |
| lightyear | is it possible with the plugin api to write something like this is the question.... | 01:58 |
| bialix | hsn_: looking at terminal settings | 01:58 |
| === fog [n=fog@debian/developer/fog] has joined #bzr | ||
| CardinalFang | lightyear, I'm afraid you've misunderstood. This isn't a bazaar problem. Your endpoint is crippled. You could write a plugin that wraps one of dozens of tools that upload trees of files, or you could just run one of those programs directly. | 01:59 |
| hsn_ | bialix: because when i run bzr under eclipse it seems to use incorrect ascii encoding. from command line it works fine | 01:59 |
| bialix | hsn_: try this: python -c "import locale; print locale.getpreferredencoding()" | 02:01 |
| bialix | I don't know much about eclipse, probably it run bzr with dummy stdout, that use ascii encoding | 02:01 |
| bialix | if you run bzr from another program with redirecting all stdin/stdout/stderr to pipe or file, then bzr internally will use encoding from locale | 02:02 |
| bialix | so my best guess: something wrong happens when eclipse grab output of bzr | 02:03 |
| bialix | hsn_: you can use very simple plugin to look at encodings that see bzr | 02:04 |
| bialix | or could look in .bzr.log :-) | 02:06 |
| hsn_ | bzr is using 'ascii' encoding under eclipse. Its in error message from bzr 'ascii' codec can not encode... | 02:06 |
| bialix | in what command? | 02:07 |
| hsn_ | bzr version --xml | 02:07 |
| bialix | C:\work\Bazaar\mydev\bzr.dev>bzr version --xml | 02:07 |
| bialix | bzr: ERROR: no such option: --xml | 02:07 |
| hsn_ | you need bzrxml plugin | 02:08 |
| bialix | so, problem in this plugin | 02:08 |
| bialix | try to run plain 'bzr --no-plugins version' | 02:08 |
| hsn_ | nope, it will do without --xml too, because bzr with ascii codec complains about non-ascii characters in pathname | 02:09 |
| bialix | it's very common error here: try to print non-ascii strings to stdout | 02:09 |
| bialix | you run with --no-plugins flag? | 02:09 |
| hsn_ | no | 02:10 |
| bialix | can you try with --no-plugins? | 02:10 |
| hsn_ | yes if i change bzr.bat | 02:11 |
| bialix | why for??? | 02:11 |
| hsn_ | add --no-plugins | 02:11 |
| bialix | you cannot run bzr from eclipse as from command line? | 02:12 |
| hsn_ | bzr.bat is executed by eclipse-bzr plugin, i dont have source code for plugin | 02:14 |
| bialix | does eclipse have some sort of command to run any arbitrary program? | 02:14 |
| bialix | bug 131100 | 02:15 |
| ubotu | Launchpad bug 131100 in bzr "`bzr --version` should care about encoding of stdout" [Medium,Fix released] https://launchpad.net/bugs/131100 | 02:15 |
| bialix | I fixed this bug for 0.91 | 02:16 |
| bialix | and it really fixed | 02:16 |
| bialix | you can fix bzrxml plugin yourself though | 02:16 |
| hsn_ | why do you think that bug is in bzrxml? | 02:17 |
| bialix | because it's common error of many python programmers: pretend that "print" always print to real terminal | 02:18 |
| bialix | and never thought about non-ascii users | 02:18 |
| bialix | in bzr ML there is recent patch from Lukas that fixes similar problem | 02:19 |
| hsn_ | testing it without bzrxml plugin | 02:19 |
| hsn_ | bzr --no-plugins version seems to work from eclipse fine, i will do more tests | 02:22 |
| bialix | as you wish | 02:22 |
| hsn_ | you understand how Windows are using its 2 encoding? They use one for gui programs and second for command line programs. What kind of encoding is used for Filenames? | 02:28 |
| bialix | for filenames windows internally used unicode | 02:29 |
| bialix | but you can get it in ANSI encoding (you called it gui) | 02:29 |
| bialix | you can control encoding of terminal with 'chcp' command | 02:30 |
| bialix | it's very handy | 02:31 |
| hsn_ | locale.getpreferedencoding() in command-line windows returns cp1250 but output seems to be in 852 encoding | 02:31 |
| bialix | just select Lucida Console font for terminal | 02:31 |
| bialix | try in terminal: chcp 1250 | 02:31 |
| hsn_ | yes chcp 1250 in console changes bzr output to 1250 too | 02:32 |
| bialix | so now you too know kung-fu :-) | 02:33 |
| hsn_ | ok. now how to fix bzrxml insert calling to some locale function? | 02:34 |
| bialix | you read bzr ML? | 02:34 |
| hsn_ | sometimes yes | 02:35 |
| bialix | one sec | 02:35 |
| bialix | http://bundlebuggy.aaronbentley.com/request/%3C5288a560710120333t50ad35eagccd51987e20adea5@mail.gmail.com%3E | 02:35 |
| bialix | you need to add line: encoding_type = 'replace' in the body of cmd_version class in bzrxml plugin | 02:36 |
| bialix | and change all print 'foo' | 02:37 |
| bialix | to: print >>self.outf, 'foo' | 02:37 |
| bialix | that's basically all | 02:37 |
| === keir [n=keir@206-248-157-128.dsl.teksavvy.com] has joined #bzr | ||
| bialix | hsn_: may I ask you a question? | 02:41 |
| hsn_ | yes | 02:41 |
| bialix | it seems you're novice in bzr | 02:41 |
| hsn_ | i am using it since 0.14 or 0.15 | 02:42 |
| bialix | oh, all 2007 :-) | 02:42 |
| hsn_ | i used tla before | 02:42 |
| bialix | you don't read ML because it's not interesting or because it too devel-centric? | 02:43 |
| hsn_ | no, because my time is limited and there are too much messages/day | 02:43 |
| bialix | ok, thanks | 02:44 |
| === bigdo1 is now known as bigdog_ | ||
| hsn_ | i am using bzr because its easier to use than git or hg | 02:46 |
| bialix | you familiar with git? | 02:47 |
| === fog [n=fog@debian/developer/fog] has joined #bzr | ||
| hsn_ | i used it for a while, but it was too hard for ppl working with me to learn | 02:51 |
| bialix | I have a question about rebase | 02:52 |
| bialix | how rebase deal with conflicts? | 02:52 |
| dato | stops rebasing, and gets you back to the shell for you to resolve them | 02:52 |
| dato | and then you do `bzr rebase-continue` | 02:52 |
| bialix | it's rebase revision by revision? | 02:53 |
| bialix | (probably git rebase-continue) | 02:54 |
| dato | oh | 02:54 |
| dato | sorry | 02:54 |
| bialix | :-) | 02:54 |
| bialix | it's ok | 02:54 |
| dato | missed the context and thought you meant rebase in bzr :) | 02:54 |
| bialix | I can't use svn fro the same reason | 02:54 |
| dato | so nothing I said applies to git | 02:54 |
| bialix | does we have rebase in bzr? | 02:55 |
| dato | plugin | 02:55 |
| dato | by jelmer | 02:55 |
| bialix | ah | 02:55 |
| bialix | never tried it | 02:56 |
| bialix | just interesting how git-rebase deal with conflicts | 02:57 |
| bialix | git people push too much noise about rebase | 02:57 |
| hsn_ | i never used rebase in git | 03:01 |
| bialix | hsn_: you said hg is also hard to use | 03:03 |
| hsn_ | hg is easier to use than git | 03:03 |
| bialix | but? | 03:03 |
| hsn_ | there doesnt seems to be much interest in fixing hg bugs | 03:05 |
| dato | you mean upstream is unresponsive? or what? | 03:05 |
| hsn_ | i want to say that if i compare speed of hg releases and speed of bugfixing, its very unlikely to get some bugs fixed soon | 03:09 |
| === keir [n=keir@206-248-159-112.dsl.teksavvy.com] has joined #bzr | ||
| === abentley [n=abentley@bas2-toronto02-1279462552.dsl.bell.ca] has joined #bzr | ||
| bialix | luks: ping | 03:16 |
| === jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr | ||
| === jelmer_ is now known as jelmer | ||
| === herzel104 [i=herzel@gateway/tor/x-78e09278caccec4d] has joined #bzr | ||
| === jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr | ||
| === jelmer_ is now known as jelmer | ||
| === nir [n=nir@moinmoin/fan/nir] has joined #bzr | ||
| === corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr | ||
| === lightyear [n=lightyea@90.163.23.135] has left #bzr ["einer] | ||
| === keir_ [n=keir@76-10-155-123.dsl.teksavvy.com] has joined #bzr | ||
| === bratsche [n=cody@adsl-68-94-23-66.dsl.rcsntx.swbell.net] has joined #bzr | ||
| === niemeyer [n=niemeyer@200-138-54-64.ctame705.dsl.brasiltelecom.net.br] has joined #bzr | ||
| === jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr | ||
| === jelmer_ is now known as jelmer | ||
| === p4tux [n=p4tux@189.169.95.23] has joined #bzr | ||
| === kaaloo [n=luis@ATuileries-153-1-54-188.w83-202.abo.wanadoo.fr] has joined #bzr | ||
| === RichardL is now known as rml | ||
| === orospakr [n=orospakr@132.213.238.4] has joined #bzr | ||
| === jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr | ||
| === jelmer_ is now known as jelmer | ||
| === jelmer is now known as bloa | ||
| === bloa is now known as jelmer | ||
| === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr | ||
| === keir_ is now known as keir | ||
| === corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr | ||
| ubotu | New bug: #152008 in bzr "Ability to unmerge or revert a merge sensibly" [Undecided,New] https://launchpad.net/bugs/152008 | 05:40 |
| === rml [n=Skippy@78.32.35.169] has joined #bzr | ||
| === BasicOSX [n=BasicOSX@gatekeeper.real-time.com] has joined #bzr | ||
| === fog [n=fog@debian/developer/fog] has left #bzr [] | ||
| === BasicOSX [n=BasicOSX@gatekeeper.real-time.com] has joined #bzr | ||
| === herzel104 [i=herzel@gateway/tor/x-3b4978b55113563b] has joined #bzr | ||
| === Vernius_ [n=tomger@p508ADCD6.dip.t-dialin.net] has joined #bzr | ||
| === fredp_ [n=fred@213.219.162.65.adsl.dyn.edpnet.net] has joined #bzr | ||
| === bratsche [n=cody@adsl-68-94-23-66.dsl.rcsntx.swbell.net] has joined #bzr | ||
| === hsn_ [n=chatzill@234.114.broadband5.iol.cz] has joined #bzr | ||
| === grimboy [n=grimboy@85-211-251-94.dsl.pipex.com] has joined #bzr | ||
| === kaaloo [n=luis@rue92-3-82-232-48-241.fbx.proxad.net] has joined #bzr | ||
| === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has left #bzr [] | ||
| === bialix [i=chatzill@77.109.17.16] has joined #bzr | ||
| bialix | luks: ping | 09:22 |
| luks | hi bialix | 09:25 |
| bialix | hi luks | 09:25 |
| bialix | have a question about qdiff | 09:25 |
| bialix | can you give a hint where text of diff decoded to/from utf-8? | 09:26 |
| bialix | I need to to do something with bug 148159 | 09:26 |
| ubotu | Launchpad bug 148159 in qbzr "qdiff and qannotate treats file content as utf-8" [Undecided,In progress] https://launchpad.net/bugs/148159 | 09:26 |
| luks | hmm | 09:26 |
| bialix | I want to introduce new branch option 'default_encoding' and use it as hint for decoding files content | 09:27 |
| bialix | otherwise qdiff will use utf-8 | 09:27 |
| luks | it should be after running PatienceSequenceMatcher on it, but before passing it to Qt | 09:27 |
| luks | currently it's a bit hardcoded in diffview.py | 09:28 |
| bialix | treediff = TreeDiff(self.tree1, self.tree2, self.specific_files, complete) | 09:28 |
| bialix | in TreeDiff class? | 09:28 |
| luks | I'll need to take a look at the code | 09:29 |
| luks | one moment | 09:29 |
| bialix | there is FileDiff.make_diff method | 09:31 |
| bialix | my best guess it should be done here | 09:31 |
| luks | I'd like to do as little unicode decoding as possible | 09:31 |
| luks | decoding all lines of all files is a waste of CPU | 09:32 |
| bialix | so? | 09:32 |
| luks | one more moment, still thinking :) | 09:34 |
| bialix | Patience sequence matcher invoked in FileDiff.make_diff | 09:34 |
| === asak [n=alexis@201-13-31-123.dsl.telesp.net.br] has joined #bzr | ||
| luks | okay, decoding all lines in FileDiff.make_diff is probably the best option | 09:36 |
| luks | there is a bunch of unused code (html_diff_lines) and the current side-by-side diff is calculated in diffview.py | 09:37 |
| bialix | I'm not dare enough to delete this code | 09:37 |
| luks | I'll have to refactor these things, and then can be the decoding optimized | 09:37 |
| luks | but for now decoding all of them should be fine | 09:37 |
| bialix | before sequence matcher or after? | 09:38 |
| luks | after | 09:38 |
| bialix | what about this code: | 09:38 |
| bialix | if old_lines and not new_lines: | 09:38 |
| bialix | self.groups = [[('delete', 0, len(old_lines), 0, 0)] ] | 09:38 |
| === mvo [n=egon@p54A66DFB.dip.t-dialin.net] has joined #bzr | ||
| bialix | elif not old_lines and new_lines: | 09:38 |
| bialix | self.groups = [[('insert', 0, 0, 0, len(new_lines))] ] | 09:38 |
| luks | add it after the whole block | 09:40 |
| luks | these ifs are just to avoid sequence matching | 09:40 |
| bialix | ah, try it now | 09:41 |
| bialix | this place try to decode line to unicde fro utf-8 | 09:43 |
| bialix | File "C:\work\Bazaar\plugins-repo\qbzr\diffview.py", line 157, in markup_intraline_changes | 09:43 |
| bialix | probably this place you call hardcoded | 09:43 |
| bialix | and many others too | 09:44 |
| luks | you can remove them | 09:45 |
| luks | everything that calls .decode("utf-8", "replace") in diff.py or diffview.py | 09:45 |
| bialix | so, I do decoding in one place and remove all others from all places, right? | 09:46 |
| luks | yes | 09:46 |
| bialix | you do decode to unicode a bit too often | 09:47 |
| bialix | I found 3 places so far for only one file | 09:47 |
| bialix | qdiff for one file | 09:47 |
| bialix | heh, it's finally working | 09:49 |
| bialix | so, you have some objections for new branch config option? | 09:49 |
| luks | yes, I have a habit of writing extramly ugly code if it's for myself :) | 09:49 |
| luks | no, not at all | 09:49 |
| bialix | I'm inclined to use branch-level option to allow different projects have different encodings | 09:50 |
| bialix | because qbzr is utf-8 :-) | 09:50 |
| luks | it's a shame that these configs are not propagated on push/pull | 09:51 |
| bialix | well, another option is to have such option in revisions property | 09:52 |
| bialix | like --fixes or --author | 09:52 |
| bialix | it's require some plugin hacking | 09:52 |
| bialix | or just qcommit can do this :-) | 09:52 |
| luks | I think I'd really prefer something like .bzrprops | 09:53 |
| luks | but I don't mind using a branch config for now | 09:53 |
| luks | as long as the default is utf-8 :) | 09:54 |
| bialix | .bzrprops should be in past revisions, but my old revisions don't have it | 09:54 |
| bialix | it's the problem for me | 09:55 |
| bialix | it will be show-stopper to browse history | 09:55 |
| luks | oh, right | 09:55 |
| bialix | of course, default always be utf-8 | 09:55 |
| bialix | it's inevitable | 09:56 |
| bialix | luks: do you have in mind some roadmap for qbzr? | 09:56 |
| luks | no, the development was driven only by what I currently needed | 09:57 |
| === pf_moore [n=chatzill@arkenstone.demon.co.uk] has joined #bzr | ||
| bialix | well, so I'll try to scratch my itches and help you if possible | 09:58 |
| luks | I really didn't intend to create some generally usable tool | 09:59 |
| bialix | why not? | 09:59 |
| luks | I just wanted to use bzr, and but I was too used to tortoisesvn | 09:59 |
| luks | so I needed something similar | 10:00 |
| bialix | before bzr I used TortoiseCVS | 10:00 |
| luks | and I still consider it my own personal tool :) | 10:00 |
| luks | I tried to use bzr-gtk before, but it was just too weird | 10:01 |
| luks | but I liked the idea of using a command line shell instead of windows explorer | 10:01 |
| luks | (with GUI for commit, etc.) | 10:01 |
| bialix | I'm happy with FAR and using bzr from command line a joy for me | 10:02 |
| bialix | but I'm thinking about convenient log/diff viewer, and your QBzr fit my expectation on 100% | 10:02 |
| bialix | but now I feel that qstatus will be very good thing | 10:03 |
| bialix | and I agree with you about gtk | 10:04 |
| bialix | on windows it's very unfriendly | 10:04 |
| luks | the problems I had with it are not directly gtk-related | 10:05 |
| bialix | but overall design? | 10:05 |
| luks | GUI design | 10:05 |
| luks | not even GNOME uses dialogs like that | 10:06 |
| luks | but I didn't feel like hacking a gtk app on windows | 10:06 |
| bialix | hmm, have no experiance with gnome | 10:06 |
| luks | and now I ended up using Qt on GNOME :) | 10:06 |
| luks | because it simply looks more native than bzr-gtk, even though gtk is the first class citizen in GNOME | 10:07 |
| bialix | I think it's a very funnily | 10:07 |
| luks | another thing that annoyed me about bzr-gtk is the order of Ok and Cancel buttons | 10:08 |
| luks | don't know why, but if I'm on GNOME I expect the buttons to follow the GNOME standard, and on Windows the Windows standards | 10:08 |
| bialix | you're using standard windows scheme in QBzr | 10:08 |
| luks | and somehow have no problem switching between them | 10:09 |
| luks | bialix: no, it uses different scheme on each platform | 10:09 |
| bialix | are you sure with my latest changes? | 10:09 |
| luks | yes | 10:09 |
| bialix | but... how??? | 10:09 |
| luks | QDialogButtonBox handles that | 10:10 |
| bialix | wow | 10:10 |
| bialix | it's magic | 10:10 |
| bialix | I never realize this | 10:10 |
| luks | so on GNOME I have [Cancel] [Ok] and on Windows [Ok] [Cancel] | 10:10 |
| bialix | cool | 10:10 |
| === bialix starts thinking that Qt is really right thing | ||
| bialix | luks: I'm planning to put QBzr in standard standalone windows installer with some others plugins | 10:13 |
| luks | hmm | 10:13 |
| luks | wouldn't it be too big? | 10:13 |
| bialix | with gtk it will be bigger as twice of qbzr | 10:13 |
| bialix | currently your installer is 3MB | 10:14 |
| bialix | bzr.exe installer is about 4.5 MB | 10:14 |
| bialix | so I'll have in the end about 7 MB installer | 10:15 |
| bialix | I'm also concerned about size | 10:15 |
| bialix | may be there will be 2 standalone installers: bare bzr.exe and big pack with some popular plugins | 10:16 |
| bialix | and if you're planning to switch to bzr version scheme one day, I'm happy to include Queue.py std module to bzr.exe | 10:18 |
| luks | Queue.py is no longer required | 10:18 |
| luks | but no, I don't plan to have releases synchronized with bzr | 10:19 |
| bialix | but you planning to use multithreading... | 10:19 |
| luks | maybe... | 10:19 |
| luks | I'd rather keep backward compatibility than force users to specific version of bzr | 10:20 |
| bialix | bzrlib API is very fast changing sometimes. how you achieve backward compatibility? | 10:21 |
| luks | well, most of the API is not changing | 10:21 |
| bialix | it's good | 10:23 |
| CardinalFang | Ick. Cloning from a remote repo. I don't have enough space in /tmp to contain a whole repo. | 10:24 |
| === CardinalFang assumes it's /tmp that is the problem -- "No space left on device". | ||
| bialix | luks: good night, thanks for help with qdiff, I'll prepare the patch | 10:25 |
| CardinalFang | remote.RemoteRepository._get_tarball downloads a tarball into a "tempfile"-created temp file. Could it instead (uncompress+) untar the stream as it goes, instead of making a file and then operating on the file? | 10:27 |
| luks | CardinalFang: currently no, but the next version should support streaming natively | 10:28 |
| CardinalFang | NameError: name "next version" is undefined | 10:29 |
| CardinalFang | Is that v2? Or 0.9z? | 10:30 |
| luks | 0.92 | 10:30 |
| CardinalFang | Ah, cool. Thanks. | 10:30 |
| luks | at least there is a patch for that, I assume it's going to be included | 10:31 |
| CardinalFang | I see in tempfile.py that it reads from env variables. Is there a way to poke the environment for only bzr, e.g., with ~/.bazaar/bazaar.conf . | 10:34 |
| CardinalFang | ? | 10:34 |
| luks | no idea | 10:35 |
| CardinalFang | Hmm, doesn't look like it. | 10:39 |
| CardinalFang | Aw crap, it's not local. The server makes a tarball too. That's where I'm running out of space. Crap. Crap crap crap. | 10:51 |
| === grimboy [n=grimboy@85-211-255-243.dsl.pipex.com] has joined #bzr | ||
| === weigon [n=jan@pD9E2BC90.dip.t-dialin.net] has joined #bzr | ||
| lifeless | CardinalFang: if you apply the hpss patch from spiv, its on BB, to the client and server, then the tarball method won't be used | 11:29 |
| CardinalFang | lifeless, Thanks. | 11:30 |
| weigon | I don't get my head around why I should to a checkout instead of a branch | 11:37 |
| weigon | I have read http://bazaar-vcs.org/CheckoutTutorial but I'm not really sold | 11:38 |
| Peng | weigon: You should use a branch. The only reason to use a checkout is if you absolutely can't retrain your brain to use bzr commands instead of svn commands. :) | 11:39 |
| weigon | ah, so I'm fine :) | 11:39 |
| Peng | weigon: Also, lightweight checkouts are useful for when you don't want a copy of the entire history. | 11:39 |
| === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr | ||
| hsn_ | Peng: bzr update in checkout does equivalent of svn up ? | 11:52 |
| Peng | hsn_: Yes. | 11:52 |
| === Peng waits to be proved wrong. :P | ||
| LeoNerd | It can even be abbreviated 'bzr up' | 11:54 |
| hsn_ | testing it | 11:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!